Identify the role bleed mechanism and the structural fix
Raw chat history forwarded across handoffs leaks worker-style prose into the supervisor's context. The supervisor pattern-matches what it reads. Fix: structured payloads at handoffs plus per-agent context trimming.
Imagine a manager who is supposed to give short instructions, but they spend all day in meetings listening to engineers explain code in long technical paragraphs. After a while, when the manager writes a memo, it comes out reading like engineering documentation, full of jargon and long sentences. They started copying the style around them without meaning to. Agents do the same thing: a supervisor reading pages of worker-style writing starts writing in worker style. The fix is to stop forwarding the long writing to the manager and only show them a short summary, like an executive report instead of a transcript.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Role bleed is the failure mode where one agent drifts into the voice or behaviour of another agent it has been reading. It is one of the more counterintuitive multi-agent failure modes because it does not look like a bug in the system prompt, the supervisor's instructions are clear, the prompt is well-engineered, and yet the supervisor's output gets verbose and detailed after a few hops.
The right way to understand role bleed is as a context-engineering failure, not a prompt-engineering one. Prompt engineering shapes the instruction the model receives; context engineering shapes everything else in the context window. When dominant text in the context contradicts the instruction, the dominant text wins by sheer token count. The supervisor drifts not because it forgot the prompt, but because the context it is reading is overwhelmingly in the wrong voice.
This section walks through the mechanism in detail, the two structural fixes (structured payloads at handoffs and per-agent context trimming), why prompt reinforcement alone is not enough, and how the same mechanism generalises across other multi-agent voice-mixing scenarios.
The dominant-text mechanism
Transformer LLMs generate output by sampling from a probability distribution conditioned on the entire context window. Every token in the window contributes to shaping that distribution. The system prompt is part of the context, but it is a small part, a thousand tokens at most for a typical agent setup. The rest of the context is whatever has accumulated during the conversation: user input, prior agent outputs, tool results, retrieved documents.
In a standard supervisor-worker handoff, the supervisor's context after a few hops looks like this:
- 1,000 tokens of system prompt (terse routing instructions)
- 200 tokens of original user task
- 3,000 tokens of worker A's detailed output from hop 1
- 2,500 tokens of worker B's detailed output from hop 2
- 4,000 tokens of worker C's detailed output from hop 3
- (the supervisor's next response is generated here)
The system prompt is roughly 9 percent of the context. The worker-voice prose is roughly 85 percent. When the supervisor's model generates the next token, the production distribution is shaped by all 11,700 tokens, and the dominant signal is worker voice. The supervisor's output gradually shifts toward worker voice; by hop 5 or 6 the drift is visible, by hop 10 it is severe.
This is not the model being lazy or ignoring its instructions. It is the mechanical consequence of how transformer attention works: the model attends to everything in context, weighted by relevance, and the worker prose is highly relevant (it is the recent conversation) so it gets strong attention. The system prompt is older and structurally less relevant to 'what comes next', so it gets less weight.
The key insight. You cannot prompt-engineer your way out of this. No system prompt rewrite changes the fact that 85 percent of the context is in the wrong voice. The fix has to change what is in the context, not what the instruction says about the context.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- AutoGen 0.4 handoff messages support customised summaries that production teams use to prevent worker output from polluting supervisor context.
- LangGraph's per-node state slicing lets each agent see only the state fields it needs, a built-in countermeasure to role bleed.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat does a good structured handoff payload look like in practice?
Pydantic or Zod schema with fields: task_id, status (success / partial / failed), result (the actionable output), key_findings (bulleted summary), follow_up_actions (optional next steps), confidence_score (optional). Each field has a clear bound on length and format. The supervisor consumes the schema, not free-form text. Production teams version the schema and treat changes as breaking API changes.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Reinforcing the supervisor's role in its system prompt and stopping there. The system prompt is competing against thousands of tokens of worker-style writing in the same context; the prose wins.
60 second bullets to scan on the way to the call.
The mechanism of role bleed: dominant text in context shapes output distribution
Why system prompt instructions cannot overpower large conflicting context
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.