Conversation
Everything a prompt brought into being was called something generic: "Project 3", "Session 1", four random words. The agent knows what it is building, so it gets tools to say so. - rename_project and name_session, seeded with a standing brief telling the agent to use them, plus a nudge to name the pipelines it creates. - rename_project replaces only a name nobody chose. Machine-made names carry a provisional mark; the first deliberate rename, by anyone, drops it. - Underneath, a deterministic floor: project, session and pipeline are named from the opening prompt at creation, and a session started inside a project is named from its first message. An agent that never calls the tools still leaves something readable behind. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"build a pipeline that scrapes wikipedia and converts articles into a pokemon" became "Build a pipeline": the trailing-phrase trim cut at the first joiner it found from the right, wherever that was. It now only drops a phrase that starts in the tail of the name, leaving "Build a pipeline that scrapes wikipedia". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A rejected submission explains itself — a 422 names the field it would not accept and the value it was given — and all of it was dropped for the fixed sentence "Failed to create pipeline run". An agent that reads only that cannot tell a spec it could correct from a bug it should give up on, and retries the identical request instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
🎩 PreviewA preview build has been created at: |
This was referenced Sep 23, 2026
Collaborator
Author
…me shows `set_pipeline_name` renamed the spec in memory and nothing else, so the agent reported success while the file stayed "Draft" and both resource lists kept the name recorded when the pipeline was added. Nothing asked for a rename in the first place on the path that matters, either: the brief only covered pipelines an agent creates, and a project opened from a prompt already holds one named after the request. The spec name is canonical and everything follows it. The rename goes through the file first, and the name the file actually took is what the spec is called — a name already taken comes back adjusted, and the agent is told so rather than left believing it got the name it asked for. The two resource lists ask what a pipeline is called now instead of trusting the copy on the row, which also fixes the same staleness after a rename from the menu bar, and the open tab retitles rather than announcing the name it had when it opened. Browser storage fires no event a rename in this tab would reach, and the query behind those lists is keyed on the pointer, which a rename does not change — so the rename now invalidates it. Without that the new name only appeared a minute later, or on reload, which read as the rename silently failing. A pipeline created from the opening prompt is marked as carrying a name nobody chose, `get_pipeline_state` reports that as `nameIsProvisional`, and Prime gets a `name_pipeline` tool it calls in its first turn beside name_session and rename_project — the opening message is enough to title a pipeline, so there is nothing to wait for. It refuses a pipeline someone named deliberately, and drives the open tab's bridge rather than the resource row, because only the bridge moves the spec, the file and the row together. The editor keeps a fallback rule for a pipeline still unnamed once its changes are in. A name-only pointer is trusted only in the browser that wrote it: someone else's "Churn model" is not the one this browser holds. `useUnavailablePipelines` moves to `services/projects` as `useLocalPipelineStatus`, since both pages need it and it answers two questions rather than one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
camielvs
force-pushed
the
09-23-fix_make_an_agent_s_pipeline_rename_stick
branch
from
September 23, 2026 21:43
656fc7f to
97afd7e
Compare
camielvs
force-pushed
the
09-23-fix_say_why_the_backend_refused_a_run
branch
from
September 23, 2026 21:55
65c7fbe to
5964134
Compare
Collaborator
Author
camielvs
deleted the
09-23-fix_make_an_agent_s_pipeline_rename_stick
branch
September 23, 2026 21:56
This was referenced Sep 23, 2026
Draft
This was referenced Sep 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Problem
An agent asked to name a pipeline calls
set_pipeline_name. That renamed thespec held in memory and nothing else, so it reported success while the file
stayed
Draftand both resource lists kept showing the name recorded when thepipeline was added.
Behind that sat a second problem: nothing asked for the rename in the first
place on the path that matters. The naming brief only covered pipelines an
agent creates — but a project opened from a prompt already holds one, named
after the request, so the agent "found the open canvas" and no rule applied.
And the brief is seeded into the session's memory, which is Prime's, while the
only agent holding
set_pipeline_nameis the remote editor, whose prompt saidnothing about naming at all.
Then a third: even once a rename did fire, the lists kept the old name for a
minute. Browser storage fires no event a rename in this tab would reach, and the
query behind those lists is keyed on the pointer, which a rename does not change.
The new name appeared on reload, which read as the rename silently failing.
What changed
The spec name is canonical and everything follows it. The rename goes
through the file first, and the name the file actually took is what the spec is
called. An agent picks a name without knowing what else this browser holds, so a
collision adjusts rather than overwriting — the rule
create_pipelinealreadyfollows — and the tool says so instead of letting the agent believe it got the
name it asked for:
Agent renames go through a new
renamePipelineFileForrather than the hook themenu bar uses: that one also navigates, which is meaningless for a pipeline open
in a workarea tab rather than at a url of its own. The rename invalidates the
local-pipeline queries and retitles the open tab, which otherwise keeps
announcing the name it resolved when it opened.
Naming happens on the first turn, not at the end of the build. A pipeline
created from the opening prompt is marked as carrying a name nobody chose;
get_pipeline_statereports that asnameIsProvisional. Prime gets aname_pipelinetool it calls alongsidename_sessionandrename_project—the opening message is enough to title a pipeline, so there is nothing to wait
for. It refuses a pipeline someone named deliberately, and drives the open tab's
bridge rather than the resource row, because only the bridge moves the spec, the
file and the row together. The editor keeps a fallback rule for a pipeline still
unnamed once its changes are in.
The mark lives on the spec rather than on the project resource because the agent
that acts on it reads the canvas and never sees the row.
Both resource lists ask what a pipeline is called now instead of trusting the
copy on the row, which also fixes the same staleness after a rename from the menu
bar. A name-only pointer is trusted only in the browser that wrote it — someone
else's "Churn model" is not the one this browser holds, and naming a row after it
would be naming the wrong pipeline. Unknown authorship is trusted, which is every
single-user backend.
useUnavailablePipelinesbecomesuseLocalPipelineStatusinservices/projects: both pages need it now, and it answers two questions(unreachable, and current name) rather than one.
Fixing the project page also meant separating two things that had shared one
prop: a row's display label and "this row opens a conversation elsewhere". A
renamed pipeline is still a row on this page, and overloading the label would
have made it open as a session and lose its Remove button.
Testing
renamePipelineFileFor.test.ts(6),useLocalPipelineStatus.test.ts(6),provisionalPipelineName.test.ts(4);createNamingHandlers.test.tsandserializeSpecForAi.test.tsextended.pnpm run validateclean;npx vitest run321 files / 3256 tests green.the collision message surfaced correctly, but the new name only reached the
lists on reload — which is what the query invalidation here fixes. The
first-turn
name_pipelinepath has not been exercised against a live agentyet.
🤖 Generated with Claude Code