The Work Item Was the Same. The Chat Name Was Not the Identity.
Tomohiro Iida · Published August 21, 2026 · Updated August 25, 2026
When ChatGPT, Claude Code, and Codex work on the same development item, time shifts from implementation to finding which conversation is the continuation. Netsujo first solved this by requiring identical chat names at every handoff. That rule has been retired. The stable identity now lives in a work-item ID, and the chat name is a human-facing label that may differ per tool.
Key takeaways
- A chat name is an arbitrary human-facing label. It may differ across tools.
- Do not use a chat name as an identifier, as an authorization subject, or as a mutation gate.
- The authoritative identity is WORK_ITEM_ID plus the live repository, pull request, branch, and exact head SHA.
- Stop conditions belong on the uncertainty of the target state, not on a display-name mismatch.
- Rename capability is no longer a blocker for high-risk operations.
Incident card
| Field | Value |
|---|---|
| INCIDENT | The same development item carried different chat names in ChatGPT, Claude Code, and Codex. |
| SYMPTOM | A person reread every conversation to determine which one was current, which was stopped, and which pull request it matched. |
| FALSE_ASSUMPTION | The problem is that the sidebar cannot group the work, so making the names identical will stabilise the handoff. |
| ROOT_CAUSE | Work identity was carried by a display label that is not stable across tools. |
| IMMEDIATE_FIX | Exact name equality was made mandatory on 21 August 2026, and retired on 25 August 2026. |
| SYSTEM_FIX | The stable identifier moved to WORK_ITEM_ID and the chat name became non-authoritative. |
| REMAINING_RISK | WORK_ITEM_ID is still transcribed by people and agents; skipping the live-state check reproduces the same mix-up. |
The naming rule that was introduced first
A different chat name does not change code. The observed cost was extra reading before a person could tell which conversation was current. As tools and continuation chats multiplied, the sidebar stopped working as an index.
- Requirements and acceptance criteria are prepared in ChatGPT.
- Implementation is handed to Claude Code.
- Independent review is handed to Codex.
- A CI failure is investigated in another conversation.
- A long conversation is stopped and continued in a new one.
- Work pauses for owner authorization and resumes after main has moved.
On 21 August 2026 Netsujo published a contract requiring the destination chat name to equal the source chat name, blocking code changes, pushes, merges, and deployments while the names differed, and treating an unverified rename capability as a blocker for high-risk operations. Grouping did improve: conversations for one item sat next to each other, and narrowing candidates took fewer steps.
Four side effects the equality rule produced
| Side effect | What happened |
|---|---|
| Rename capability differences | Tools differ in whether a conversation can be renamed at all, so the contract could not be satisfied on one side. |
| Duplicate names | Continuing a long conversation produced two chats with the same name, which the sidebar could not tell apart. |
| False blockers | Work stopped because a label differed, even when the code state was safe. |
| Transcription burden | The same string was copied by hand at every handoff, by people and by agents. |
The false blocker mattered most. A name mismatch is unrelated to the state of the code, yet it sat on the condition that stopped mutation. That produced stops with no underlying reason to stop. When a stop condition is not tied to reality, operators route around it, and a stop condition that is routinely bypassed does not hold when it is actually needed.
A chat name cannot be an identifier
The chat name was carrying two different jobs: a human index for narrowing candidates in a list, and a machine-checkable identifier for deciding that two things are the same work. The first job suits a name. The second does not.
- A display name can be changed by the tool, sometimes without leaving a history.
- Several conversations can hold the same string.
- Whether renaming is possible at all varies by tool.
- Equality checks absorb width, whitespace, and punctuation variation.
An identifier has to be unique, unchanging, and machine-comparable. A display label satisfies none of those.
The authoritative identity
| Field | Role |
|---|---|
| WORK_ITEM_ID | Stable identifier for the work item. Once assigned, it does not change. |
| PREDECESSOR_WORK_ITEM / SUCCESSOR_WORK_ITEM | Order of work across conversations and tools. |
| REPOSITORY / PR / BRANCH | Where the target lives. |
| CURRENT_HEAD_SHA / BASE_SHA | Identity between reviewed code and the operation target. |
| EXECUTOR / ROLE | Who is acting, and in which role. |
| CURRENT_STATUS / BLOCKERS | Whether work may proceed now. |
| AUTHORIZED_ACTIONS / PROHIBITED_ACTIONS | The authority boundary. |
| NEXT_ACTION / COMPLETION_CRITERIA | The next step and the exit condition. |
| TERMINAL_RECEIPT | The record written when the work item closes. |
The chat name is not in this table. It is written alongside the header as a convenience label so a person can find the conversation.
Put the gate on state uncertainty, not on the label
The retired rule blocked mutation when the destination name differed from the source name. The current rule blocks mutation when the target of the operation is not pinned down. Three conditions replace the one that was removed.
| Condition | Status | Mutation |
|---|---|---|
| WORK_ITEM_ID is missing | BLOCKED_IDENTITY | NOT_PERFORMED |
| CURRENT_HEAD_SHA differs from the live head of BRANCH | BLOCKED_STALE_STATE | NOT_PERFORMED |
| The action is not in AUTHORIZED_ACTIONS | BLOCKED_AUTHORITY | NOT_PERFORMED |
Each of the three corresponds one-to-one with a real reason to stop. A differing name does not stop work. A stale SHA does. Rename capability does not appear in the decision at all.
The decision change, kept on the record
| Date | Contract | Observed benefit | Observed cost |
|---|---|---|---|
| 21 August 2026 | Chat names must match exactly; mutation stops on mismatch. | Conversations for one item grouped together in the sidebar. | Rename capability differences, duplicate names, false blockers, transcription burden. |
| 25 August 2026 | The chat name becomes non-authoritative; WORK_ITEM_ID becomes the stable identifier. | Stop conditions now correspond to the real state of the target. | Transcription errors in WORK_ITEM_ID remain. |
The retired rule is kept visible for two reasons. A reader considering the same design can see in advance what name equality costs, and Netsujo has a record that keeps it from adopting the same proposal again.
Common failure modes
- Using the display name as an authorization input
- Anyone can change a display name. Authority decisions belong to ROLE and AUTHORIZED_ACTIONS.
- Using the pull request number as the identifier
- The reference goes stale when work moves to a successor pull request. A pull request locates the target; it does not identify the work item.
- Assuming a shared WORK_ITEM_ID means a shared state
- It only means the same work. Branch, head SHA, and status still require a live check.
- Deleting the stopped conversation
- The predecessor holds assumptions and decisions. Close it with PREDECESSOR_WORK_ITEM and TERMINAL_RECEIPT instead of erasing it.
- Handing over a summary instead of state
- A sentence such as "CI is green" does not identify the workflow, run, subject SHA, required-check status, skipped checks, or whether the pull request head moved afterward.
Scale the contract with risk
| Operating level | Minimum fields |
|---|---|
| Low-risk solo work | WORK_ITEM_ID, repository, pull request |
| Standard multi-agent work | The above plus predecessor and successor, exact SHA, status, prohibited actions, completion criteria |
| Authentication, billing, database, customer data, or production work | The above plus exact-SHA authorization, independent final QC, evidence ledger, pre-mutation gate, production verification, terminal receipt |
A heavy ledger costs more than it returns on low-risk work. A change that cannot be classified is treated as UNKNOWN and handled at the higher level.
Evidence
| Statement | Classification | Basis |
|---|---|---|
| Chat names for one item differed across tools, and a person reread conversations to reconnect successors, stopped work, and pull requests. | OBSERVED | Netsujo development operating log |
| A contract requiring exact name equality was published on 21 August 2026. | OBSERVED | The first revision of this article and docs/briefs/2026-08-21-ai-agent-chat-name-handoff-article.md |
| Tools differ in whether a conversation can be renamed. | OBSERVED | Operational use of ChatGPT, Claude Code, and Codex |
| Placing name equality on the stop condition halted changes that were safe at the code level. | OBSERVED | The period during which the equality rule was in force |
| CI already decides target identity by exact SHA. | IMPLEMENTED | .github/workflows/pr-exact-head-ci.yml and .github/workflows/candidate-exact-sha-gate.yml |
| The authority boundary is documented as an operating contract, carried by AUTHORIZED_ACTIONS and PROHIBITED_ACTIONS in the handoff header. | IMPLEMENTED | docs/briefs/2026-08-21-ai-agent-incident-series-implementation-handoff.md. Documented only; not machine-enforced. |
| Machine enforcement of every field in the handoff header. | PROPOSED | The current implementation validates only that a work item id is present; the authority fields are not enforced. |
| A display label cannot guarantee work identity because it is not stable across tools. | INFERRED | Design conclusion drawn from the observations above |
| How much handoff time the WORK_ITEM_ID contract saves. | PROPOSED | Not measured. To be evaluated from operating logs. |
Limitations
- This comes from a small team running AI development at high frequency. Required control strength changes with organisation size, regulation, and failure tolerance.
- How WORK_ITEM_ID values are assigned depends on whether an issue tracker already exists. This article covers only the principle of separating the identifier.
- Git worktree mechanics, CI rerun triage, and production verification are covered by other articles in the series.
Remaining risks
- WORK_ITEM_ID is transcribed by people and agents, so transcription errors remain.
- Live state in a handoff is the value at writing time and goes stale unless it is re-read at start.
- Another agent can update the same pull request after the handoff.
- A self-reported CURRENT_HEAD_SHA is not proof; it has to be compared against the repository with a real command.
Frequently asked questions
Is it acceptable for the chat name to differ per tool?
Yes. The chat name is a human-facing label. Work identity is carried by WORK_ITEM_ID. Aligning names is optional and is never a precondition for starting work.
Did Netsujo previously require exact name equality?
It was introduced on 21 August 2026 and retired on 25 August 2026. Grouping improved slightly, but the rule produced rename capability differences, duplicate names, false blockers that stopped safe work, and transcription burden. Stop conditions were re-bound to the state of the operation target.
What if the tool cannot rename a conversation?
It can be used as is. Rename capability is not a blocker under the current contract. Write WORK_ITEM_ID and the current state at the top of the handoff.
How should WORK_ITEM_ID be chosen?
Any string that is unique per work item and does not change is acceptable. Netsujo uses a string containing the date and the work subject. Where an issue tracker already exists, reusing its ticket ID reduces transcription errors.
Can one long conversation remove the need for handoffs?
Long conversations accumulate stale assumptions and state changes. When a continuation is created, state WORK_ITEM_ID and the current state, and record the previous work item as PREDECESSOR_WORK_ITEM.
Continue the series
Previous: #02 A repeated human warning is a system defect
Next: #04 Stopping the chat does not stop the work
Back to all 12 episodes of the AI Agent Development Incident Log
Netsujo can separate work identity, Git state, CI evidence, authority, and production verification so cross-agent handoffs stop depending on rereading conversations.
Design a verifiable multi-agent handoff contract