Your AI Agent Is Gaslighting Itself and Your Multi-Agent Fix Might Cost 15× More

The strangest bug in agent engineering isn't a hallucination. It's an agent talking itself into one — and the popular cure is a token bill most teams never see coming. Here's a support transcript that should keep you up at night.A customer writes in: "I was charged twice for my order." Clear as day. Billing issue. Any human would route it in two seconds. The AI agent opens the conversation by asking the customer about... a shipping delay. A shipping delay the customer never mentioned. Not once. The customer, understandably, thinks the bot is broken. The customer is right. When you pull the logs, you find something stranger than a hallucination. The agent didn't invent the shipping delay out of nowhere. It invented it out of itself. The agent that believed its own rough draft This agent had two jobs running in one context window. First, triage: read the incoming message, classify it, route it. Then, resolution: hold the actual conversation and fix the problem. One agent, both jobs, back to back — because that's the simplest thing to build, and it works fine in the demo. On this case, the triage step did what language models do when a case is ambiguous: it reasoned out loud. A full page of it. "The customer mentions a delay, which could indicate a fulfilment issue, but 'charged twice' points to billing, though it's possible the delay and the charge are related..." Eventually it landed, correctly, on billing. Then resolution began — in the same context window, with all of that deliberation still sitting in it. And here's the thing about a language model reading its own context: it has no concept of epistemic status. There's no metadata that says "this paragraph was me brainstorming" versus "this paragraph is established fact." It's all just tokens, and every token is a full citizen. The model re-read its own page of maybes, found "shipping delay" mentioned five times, and treated it as part of the case. The agent gaslit itself. Its rough draft leaked into its final answer. Sit with that failure mode for a second, because it breaks most people's mental model of what goes wrong with LLMs. This isn't bad training data. It isn't a bad prompt. It isn't even a hallucination in the usual sense — every "fact" the model used really was in its context. The problem is that thinking leaves a residue, and in a shared context window, residue is indistinguishable from truth. Enter the seductive fix Every engineer who hits this bug has the same reaction, and it's the correct instinct wearing dangerous clothes: split the agent. Give triage its own context. Give resolution its own context. Draw boxes, add an orchestrator, call the boxes "specialists." It even looks right on the whiteboard — real agent systems have orchestrators and sub-agents, don't they? Half of LinkedIn says so. Before you draw a single box, you should know the number that almost never makes it into the design doc. When Anthropic published the write-up of its own multi-agent research system — one of the few honest public accounts from a team that actually shipped one — it reported that the architecture burned roughly 15 times the tokens of a normal single-model chat interaction on the same class of task. Fifteen. Not fifteen percent. Fifteen times. And here's the twist that makes it worse: that multiplier isn't really about how hard your task is. It's a cover charge. You pay it at the door. The tax you pay before any work happens Think about what a single agent carries: one system prompt, one block of tool schemas, amortized across the whole task. Cheap. Boring. Efficient. Now split it in two and count what you just signed up for: Each sub-agent re-pays its own system prompt and tool schemas on every single call. The orchestrator is a third model, burning tokens just to hold the goal, plan the split, and stitch results back together. Every handoff is tokens out of one context and tokens into another. The shared framing — who the customer is, what "done" means — gets bought three times instead of once. None of that is work on the actual problem. It's overhead, and you owe it the moment you split — before the first useful token is generated. That's why 15× is a floor you walk in on, not a ceiling you might hit. For Anthropic's use case, the trade was worth it, and their post says so plainly: broad, open-ended research fans out across many independent threads, each sub-agent explores one thread in its own clean window, and the parallel breadth beat anything a single context could hold. Expensive and worth it. Both true at once. But notice how specific that shape is. Parallel. Decomposable. High-value enough to eat the bill. If your workflow is a linear sequence of steps that one agent was already handling — and most enterprise workflows are — you're paying triple overhead to isolate steps that run one after another anyway. Same pattern, opposite outcome. So when does the split pay for itself? The three fields that fixed everything Go back to the self-gaslighting agent. The split fixes it — but only if you get one design decision exactly right, and it's the one most teams fumble. The fix is not "two agents." The fix is what's allowed to cross between them. After the split, triage still deliberates. It still writes its page of billing-versus-shipping angst — in its own context, where it can be as messy as it likes. But what crosses the border to resolution is this: { "category": "billing", "route": "resolution", "confidence": 0.9, "note": "duplicate charge suspected; customer frustrated, transferred 3x" } One agent, two jobs: triage's rough-draft reasoning is still in the window when resolution begins, and the model reads its own maybes as fact. Split the contexts and only a small structured conclusion crosses the boundary — the deliberation dies where it should. The price of splitting: Anthropic reported ~15× the tokens for its own multi-agent system. That's it. Three fields and a note. The page of deliberation dies with the triage context — which is exactly where it should die. Resolution opens a billing case as a billing case, because triage's uncertainty is no longer in the room to be misread. The bug doesn't get patched; it becomes structurally impossible.And this is the whole pattern, so let me say it in one line: conclusions cross boundaries; deliberation doesn't. Get that wrong in either direction and the split was for nothing: Hand the sub-agent a copy of the full conversation "so it has context," and you've rebuilt the contamination — every window now starts polluted, and you're paying the multi-agent tax for the privilege. I call this isolation theater: separate agents that all hold the same thing. Let a sub-agent return its transcript instead of a structured result, and the receiving agent inherits the mess with an org chart in between. Two agents sharing one context, badly, at 3× the price. The object-versus-transcript choice isn't a detail of the pattern. It is the pattern. The org chart is lying to you Once teams accept the split, the next mistake is almost universal, and it comes from a very human place: they decompose the way people are organized. A billing agent. A shipping agent. A returns agent. One specialist per department, like the support floor it's replacing. It feels obviously right. Run one real case through it. A customer has a duplicate charge and a delayed replacement and a warranty question, braided together — and real cases braid like this constantly. Your shipping agent now needs to know what the billing agent found (not just what it concluded — the actual transaction details, because the charge and the delay might be connected). Billing needs warranty's working state. Every specialist needs the others' scratchpad. So the shared context starts shuttling between agents on every turn, and you arrive at the punchline: you paid the multi-agent tax to build a machine that spends most of its tokens reassembling the single context it started by tearing apart. The org chart split fails because departments are a fact about your company, not about where contexts diverge. The test that actually works is mechanical: Does step B need what step A produced — or only what A concluded? If B needs A's working context — the reasoning, the retrieved documents, the intermediate state — then A and B were never really separate. Leave them in one agent. If B needs only A's conclusion — a category, a decision, three fields and a note — that boundary is a clean seam. Cut there. Triage → resolution passes: classification concludes before resolution begins, and resolution never needs to reopen it. The department split fails: nothing ever concludes, everything stays entangled. Split where the work concludes, not where the org chart divides. When to put the scalpel down Even with a clean seam, some systems should stay in one context. The honest checklist: Latency is tight. Every delegation is a round trip. The customer on live chat does not care that your orchestration diagram is beautiful. The workflow is shared-state-heavy. If every step reads and writes one big common state, isolation fights the grain of the problem. Forcing it produces very expensive theater. You can't trace across agents yet. A single agent's failure comes with a transcript. A five-agent failure is scattered across contexts that no longer exist — the fault might be in the decomposition, any sub-agent, a delegation prompt, or the aggregation, and reconstructing it means stitching logs that were never designed to be stitched. If you can't follow one request end to end today, a multi-agent system is a debugging nightmare you are choosing on purpose. You can't write the delegation spec. A sub-agent's task description is its entire world. If you can't state a sub-task crisply enough that a stranger could do it without asking questions, the sub-agent will fill the gaps by improvising — confidently, and wrong. The five-minute test Before your next architecture review blesses a multi-agent design, ask for four things in writing: Which boundary follows a real divergence in context requirements — stated without mentioning the org chart? What exactly crosses each boundary — and is it a small structured object, not a transcript? What's the token multiple we're accepting, and what measured quality gain pays for it? Can we trace one request through every agent, today, not after launch? If the answers to 1 and 2 don't exist, you don't have a multi-agent problem yet. You have a smaller bill, a system you can actually debug, and one agent that — with the right boundary discipline — will stop gaslighting itself. That's not settling. That's the architecture. Sources: Anthropic, "How we built our multi-agent research system" (anthropic.com/engineering/multi-agent-research-system) — the ~15× token figure and the breadth-first research results are Anthropic's own reported numbers for its system, cited as an order-of-magnitude warning, not a universal constant. LangChain, "Context Engineering for Agents" (langchain.com/blog/context-engineering-for-agents) — for isolation as one of the four context-engineering operations (write, select, compress, isolate).