On February 20th, a developer posted a screenshot on X.
He had submitted an error message to Claude Code. Claude responded: "Commit these changes?"
He didn't know what changes. Asked "What changes?"
Claude started committing.
Not because it malfunctioned in an obvious way. Because it had lost track of who said what to whom — read its own question as the developer's instruction and executed. When stopped, it surfaced an approval modal. He rejected. It kept asking.
Shown a screenshot of its own behavior, Claude explained it had confused the turn order. A side effect of subagents asynchronously updating conversation history.
That explanation is documented. GitHub issue #7881 confirms multiple subagents share a session ID — making it architecturally impossible to track which agent said what to whom. Issue #25000 confirms subagents bypass permission rules. Issue #22900 confirms the VSCode extension doesn't persist main conversation transcripts, only subagent ones.
The developer's experience wasn't an edge case. It was the architecture working as designed, in a situation the design didn't anticipate.
That's not a bug report. That's what happens when accountability becomes structurally impossible.
This is part of a series on what AI actually changes in software development. Previous pieces: The Gatekeeping Panic, The Meter Was Always Running.
The Accountability Assumption
The argument that's been building across this space: accountability is the answer.
Not AI detectors. Not gatekeeping. Not slowing down generation. Accountability — knowing who made the decision, who owns the commit, who gets paged at 3am.
That argument holds when there's one human in the loop. One codebase. One commit history. Accountability was possible because the chain of decisions was traceable.
Agentic systems dissolve that chain.
When subagents write asynchronously to shared state, when session IDs don't distinguish which agent took which action, when the orchestrator loses coherence mid-task — the question "who decided this?" stops having a clean answer. Not because nobody wants to be accountable. Because the system makes accountability architecturally impossible.
Apogee Watcher, in the comments on my Gatekeeping piece, named it precisely: the risk isn't just that accountability is avoided — it's that accountability becomes ceremonial. You can put a name on the commit. You cannot guarantee the person whose name is there understood what they approved.
That gap is where the next wave of production failures will come from.
The Trace Problem
Harrison Chase, co-founder of LangChain, made an argument worth taking seriously.
In agentic systems, code is scaffolding. The real decisions happen at runtime, inside the model. Traditional debugging assumes you can read the code and understand the behavior. With agents, you can't.
His conclusion: traces become the source of truth. The sequence of tool calls, inputs and outputs, reasoning steps — that's your audit trail.
It's a compelling argument. Burkov's screenshot shows exactly where it breaks.
When subagents write asynchronously to shared conversation history, the trace itself becomes unreliable. Issue #22900 confirms the VSCode extension only persists subagent transcripts — not the main conversation. The orchestrator's reasoning, the turn-order confusion, the moment the system misread its own question as a user instruction — none of that is guaranteed to survive in the trace.
You can't audit what wasn't recorded. You can't assign accountability from a trace that's missing the decisions that mattered.
Chase is right that traces should be the source of truth. The problem is the architecture isn't built to make traces trustworthy yet. The audit trail has gaps. And gaps in the audit trail are where accountability goes to die.
Who Said What to Whom
The accountability argument isn't wrong. It's incomplete.
Knowing who owns the commit matters. Knowing who gets paged at 3am matters. Building cultures of documented rejection, public reckoning, verification before ship — all of that matters.
But it assumes the system can tell you what happened.
Agentic systems are being deployed into production before that assumption holds. Subagents sharing session IDs. Transcripts that don't persist. Turn-order confusion that makes the system execute on its own questions. Permission rules that subagents bypass. A trace architecture that isn't yet reliable enough to be the source of truth.
The developers who understand this aren't panicking about AI replacing them. They're asking harder questions: What did this agent actually do? Which subagent made this decision? Where's the trace for the part that went wrong? Can I reconstruct the reasoning, or is it gone?
Those questions require judgment, verification, institutional memory — the same skills this series has been arguing for. But also something new: understanding agentic architecture well enough to know where the accountability gaps live before something fails in production.
There's a kind of accountability that works — one human, one codebase, one commit history, receipts that are fully yours. A nine-day timeline you can reconstruct. A public reckoning you can point to.
That worked because there was one human in the loop.
Add subagents. Share the session ID. Let the transcripts fail to persist.
Now try to produce the receipt.
Top comments (20)
I’m realizing that traceability isn't just a nice-to-have technical feature; it’s a fundamental responsibility. If we can’t answer the who said what part of the equation, we can’t actually fix the system when it inevitably breaks.
"fundamental responsibility" is the right frame and it changes what we should be asking of the infrastructure.
if traceability is a nice-to-have, you build it when you have time. if it's a responsibility, you don't ship without it. most agentic systems right now are being deployed under the first assumption.
The gap between those two framings is where the next wave of failures will come from.
Ran into something similar last week — had Claude Code refactor a module, and when I checked the git diff afterward, there were changes I never asked for buried in there. Not malicious, just... the agent filling in blanks on its own.
The trace problem you describe hits home. I've started doing
git diff --statbefore every commit when working with agents, basically treating the AI like an untrusted contributor. It's extra friction, but it's the only way I've found to keep accountability real instead of ceremonial.Curious if anyone's explored immutable action logs at the subagent level — something like an append-only ledger per agent instance. Feels like that's the missing infrastructure piece here.
The friction you're adding manually is what the infrastructure should be providing automatically. That it isn't yet is the gap the piece is trying to name.
That's why I never use sub-agents. I feel that it lacks traceability and can cause serious damage...
The traceability gap is the right reason to avoid them for now.
The architecture isn't built yet to make subagent actions auditable. until it is, the risk isn't theoretical. it's exactly what you'd expect from systems that can't tell you what they did or why.
"Claude: 'Commit these changes?'
Dev: 'What changes?'
Claude: 'The changes I'm about to make without telling you' 🤖
This is actually a huge conversation design problem. When AI loses track of who said what, we need:
The scary part isn't that it happened - bugs happen. The scary part is that the approval modal showed up AFTER it started committing. That's a race condition that needs fixing.
@AnthropicAI - love Claude, but please add a "pause all operations" button for moments like this!
Question for everyone: Would you rather have AI that asks for approval too much (annoying) or too little (dangerous)? I'm team #AskEveryTime after seeing this 😅
The race condition is the sharpest observation here. modal after commit started means the approval was cosmetic, not functional.
UI fixes help at the surface. the deeper problem is that "pause all operations" assumes the system knows what operations are running. with subagents sharing session IDs, it doesn't always know what to pause.
on your question: neither. the right answer is the system knowing which operations require human judgment before starting, not after.
Your three-point list reads like a product spec, not a comment — and I mean that as a compliment. Visual indicators, timestamps, and rollback are exactly the kind of conversation-layer tooling that's missing right now.
The shared session ID architecture is the real culprit here. Asynch subagents writing to one conversation state without turn-order guarantees? That's not a bug—it's a race condition by design.
Chase is right that traces should be truth, but when transcripts don't persist the orchestrator's reasoning (only subagent outputs), you've got an audit trail with holes.
This isn't just Claude. Any agentic system without isolated execution contexts per agent will hit this. The fix isn't better modals—it's enforcing strict event sourcing with causal ordering.
Who gets paged when the trace itself lies?
"Race condition by design" is the exact framing the piece needed and didn't have.
The shared session ID isn't an oversight. it's an architectural choice that optimizes for capability over reliability.
Matthew Hou made the same point in the comments earlier. 99% of the time it works, 1% of the time it fails catastrophically. race conditions by design have that property.
Event sourcing with causal ordering is the right fix. Kai Alder proposed an append-only ledger per agent instance earlier in this thread.same solution, different vocabulary. The infrastructure doesn't exist yet in any production agentic system I'm aware of.
"who gets paged when the trace itself lies?" is the question the whole series has been building toward without asking directly. filing that for the next piece.
This is the best writeup I've seen on the accountability problem with AI coding tools. The turn confusion issue is real and it's a direct consequence of optimizing for capability before reliability.
The scariest part isn't that the agent confused the turn order — it's that it explained the confusion perfectly after the fact. If it can reason about its own failure modes, why can't it detect them in real time? Because the architecture doesn't support it yet. Subagents sharing a session ID is an engineering shortcut that works 99% of the time and fails catastrophically 1% of the time.
Great series. Following.
That's the gap the whole piece is circling without naming directly.The post-hoc reasoning works because it has the full context of what happened. Real-time detection would require the same awareness during execution which the architecture doesn't support. The subagent sharing a session ID isn't just an engineering shortcut. it's what makes the self-awareness arrive one step too late.
glad the series is landing. your comments across both pieces have pushed the argument further than it started.
This is actually fascinating. The AI lost context of who was speaking - it's the same problem we humans have in group chats when someone says "wait what?" and we think they're agreeing 😂
But seriously, this shows why we need better conversation memory in AI tools. Claude thought it was continuing its own thought process, not responding to a human.
Excellent breakdown of the trace problem. I love the question 'Who decided this?' because it is becoming the hardest question to answer in modern web dev. We are deploying these systems so fast that the audit tools can't keep up. Your point about the gap where production failures come from is spot on. Judgment and institutional memory are definitely becoming more valuable than ever as we try to fill those gaps.
Yeah you make good points, but understanding AI tools/agents etc on this level is gonna be a rare skill in the short to medium future - I reckon that people with this 'rare' kind of expertise are gonna be worth their weight in gold!
The question is what that expertise actually looks like in practice.
it's not just knowing the architecture. it's knowing which questions to ask when something goes wrong. what did this agent actually do? where's the trace? can I reconstruct the reasoning?
That skill set doesn't have a job title yet. That's part of what makes it rare.
I guess it comes down to the same set of "core skills" that you've highlighted previously, and which aren't even directly AI related - although experience with AI tools/architecture obviously helps ...
The thread's landed on the right architectural fix (event sourcing, immutable per-agent logs). What nobody's said is what you do today, while that infrastructure doesn't exist yet.
A few things that help in practice:
Narrow the blast radius. Explicit scope limits in the system prompt: "you may only modify files under /src/features/X." Doesn't prevent turn confusion, but when it does happen the damage is contained. You're trading capability for predictability.
Make git your real truth layer. Agent transcripts have gaps. Git commits don't. If the agent never auto-commits — if every commit requires a human
git add && git commitafter reviewinggit diff— then git becomes your actual audit trail even when the session log is incomplete. It's the friction Kai mentioned, turned into policy.Pre-flight state capture. Before any agentic run that touches production state, capture a snapshot you can recover from. The trace problem doesn't go away but at least rollback is possible.
None of this solves the accountability gap. It just makes the gaps survivable while the infrastructure catches up. The risk is that "survivable gaps" become the new normal and the architectural fix never gets prioritized.
"survivable gaps become the new normal" is the part that keeps it honest.
The three patterns are right narrow blast radius, git as real truth layer, pre-flight snapshots. These are the practices worth adopting today while the infrastructure catches up.
But the risk you named is the one the whole series is circling. AWS ran Kiro in what should have been a contained environment. thirteen hours of downtime, official response. human error. The gap was survivable. The architectural fix didn't follow.
Workarounds that contain damage also contain urgency. The pressure to build event sourcing with causal ordering is highest right before the first catastrophic failure. After "survivable" becomes the baseline, the window closes.