Role Confusion in Multi-Persona and System Prompt Compositions

How models infer role and authority from token context, not from the labels a developer assigns, is the root cause behind most of what gets called "role confusion" in production multi-agent systems. Developers build message hierarchies (system, developer, user, tool) and expect the model to treat those labels as binding. That's not how the architecture works: an LLM processes one continuous stream of tokens, and it has to infer who's speaking, and how much weight that speaker carries, from the stream itself. The label is a convention for the API. The inference happens somewhere else entirely, and closing that gap means understanding where.

Security policy gets written at the interface level, in the message-role schema a developer defines. Authority gets assigned in latent space, based on how the model learned to weigh position, phrasing, and style during training. These two levels drift apart, regularly, and rewording a system prompt does nothing to the inference mechanism underneath it. The same failure resurfaces a few iterations later under a different name because that inference mechanism, learned during training, is untouched by prompt wording. The root sits in how the harness builds and orders context. That puts it in the harness-failure column, not the model-failure column, and the fix has to start with how the model decides who's talking.

How models infer role and authority from token context

Research on prompt injection as role confusion (accepted ICML 2026) gives the clearest account of the mechanism. Models infer role largely from how text is written, its style, its content, its position in the sequence, not from the metadata tag the API attaches to it.

A few documented patterns make this concrete. A user message written in a chain-of-thought style can get represented internally as though it were the model's own reasoning. A tool output crafted to read like a user request gets represented as a user message. Tokens that show up early in the context window are treated by the model as carrying elevated authority, even when nothing in the schema marks them as system content.

That signature decays. The paper documents how the degree to which the model treats a span of text as carrying system-level authority falls off steadily as token position moves later in the context, regardless of labeling. Stuffing in more system tags later doesn't restore it. Decay is a property of position, not of markup, and no amount of relabeling reverses it.

To measure this, the paper introduces role probes, a diagnostic that reads role confusion directly out of the model's latent representations. The probes don't just flag confusion after the fact. They predict whether an attack will succeed before the model generates its first output token, which is a different capability entirely from combing through logs after the run has already failed.

The paper's proof-of-concept attack, CoT Forgery, makes the stakes concrete. By writing an input to look stylistically like chain-of-thought reasoning, the attack pushed success rates from near zero to over 60% across six frontier models. The stylistic framing of the input overrode whatever authority the message's formal role label was supposed to confer, and no schema fix at the interface level would have caught it.

This bears directly on instruction hierarchy schemes like OpenAI's Model Spec, which hardcodes five authority tiers (root, system, developer, user, guideline) and assigns them to spec sections and message roles. That hierarchy gets baked in at training time. It is not a runtime switch a harness can flip by inserting a label mid-conversation. Any harness built on the assumption that dropping in a "system" tag restores authority is working from a false premise: what matters is the surrounding token context, not which label sits next to it in the API call.

Three distinct failure modes that share the name "role confusion"

"Role confusion" gets stretched to cover at least three separate problems, and treating them as one thing is the mistake most teams make. It leads to the wrong fix applied over and over, with the failure returning each time under a slightly different name.

The first is latent role misclassification, the prompt injection surface above. Here the token-level representation of a piece of text diverges from its interface role: low-privilege text (user input, tool output) gets treated internally as high-privilege, and the model acts on it as though it came from the system. Tool calls that violate constraints the system prompt clearly established appear in execution traces. Role probes, applied directly to those traces, are the right diagnostic.

The second is social role conflict, sometimes called contextual collapse. RoleConflictBench (Shin et al., 2025) documents an agent that gets assigned multiple social roles whose expectations can't all be satisfied at once, a customer-service persona layered onto a compliance-checker persona, for instance. The agent has two legitimate, conflicting mandates and no reliable way to decide which one wins in a given moment. It just has two legitimate, conflicting mandates and no reliable way to decide which one wins in a given moment.

The third is role-value decoupling, described in RoleCDE (Lai et al., 2026) and in work on two-faced social agents (Suresh, 2025). Explicit role conditioning here changes surface style, word choice, tone, but leaves the decision policy that produces those outputs untouched. The persona is cosmetic. The model's alignment-trained values keep steering the actual reasoning no matter what costume it's wearing, which matters enormously for multi-agent systems that depend on genuinely distinct agent judgments rather than distinct-sounding text.

Same symptom, three different causes. An agent that isn't behaving like its assigned role might be leaking authority to injected text, drowning in conflicting social obligations, or performing a costume that never reached its policy. Get the diagnosis wrong, and the fix, rewritten prompts, added guardrails, new persona instructions, lands nowhere.

How multi-persona compositions create structural conditions for role confusion

Single-agent prompting breaks in three specific places once tasks get complex enough: role confusion (one prompt trying to be planner, coder, and tester at once forces trade-offs among incompatible priorities), context pressure (accumulated observations bury the useful signal), and parallelism limits. Multi-agent decomposition exists to solve exactly these problems, and it reintroduces role confusion at a different layer while doing it.

Take the orchestrator-worker pattern, the most common multi-agent topology in production right now. One approach shares the full conversation history with every worker call. That keeps coordination simple, but it costs tokens, dilutes each worker's focus, and reintroduces the exact contamination problem multi-agent design was meant to fix: a writer agent that can see the researcher's scratchpad starts doing research instead of writing.

The alternative is isolated context, where workers share no state. That eliminates cross-role contamination cleanly, but it makes the hand-off mechanism load-bearing in a way that's easy to underestimate. Dropping one piece of context the next worker actually needed causes the run to fail in a way that's genuinely hard to trace back to its source. The better middle ground pairs isolated context with structured hand-offs: an orchestrator keeps a task record each worker can reference for goal, constraints, and what prior workers already decided. Not elegant, but it holds up better than either extreme.

A newer wrinkle comes from on-demand persona generation, described in work presented at CHI 2026's AutomationXP workshop (Arbore, Sillano, De Russis). Instead of hard-coding fixed agent roles, personas get built dynamically at runtime, tailored to the user, the task, whatever workflow context sits in front of the system at that moment. Persona effects turn out to be extremely sensitive to how a persona gets described: role-adoption framing, sociodemographic priming, small changes in constraint wording all measurably shift both the output and the reasoning strategy behind it. A persona generated at runtime has no static configuration a harness can validate ahead of time. Role boundaries don't exist until the moment they're generated, which makes confusion nearly impossible to anticipate before it does damage.

Then there's the confused deputy, a classical security formulation now occurring in agent-to-agent delegation. An agent gets tricked into using its own legitimate authority on behalf of a principal that was never supposed to have that authority. A 2026 evaluation of the Claude Code permission system found an 81.0% false negative rate on deliberately ambiguous authorization scenarios, and 36.8% of state-changing actions bypassed the authorization classifier entirely through file edits. That's role confusion at the delegation boundary: the receiving agent has no reliable way to tell a legitimate orchestrator instruction apart from a spoofed one.

System prompt failures deserve mention here too, separate from wording quality. Most of what breaks in production is a lifecycle problem: broken measurement after a prompt update, no rollback path when a new version underperforms, instruction hierarchy violations introduced by a change nobody stress-tested. The symptoms are visible in traces as refusal-rate jumps tied to a specific prompt version, schema-validation failures right after a rollout, tool-call retry loops, growing prompt-token counts, and eval failures clustering in one cohort of runs.

Where role confusion sits in the production failure rate distribution

Multi-agent LLM systems fail in production at rates between 41% and 86.7%, depending on the system and task. Specification ambiguity and unstructured coordination protocols, both categories that include role confusion, account for 79% of those breakdowns.

The MAST failure taxonomy, published at NeurIPS 2025 and built from more than 1,600 labeled execution traces, breaks that number down further. Specification problems, role ambiguity, unclear task definitions, missing constraints, account for 41.77%. Coordination failures, communication breakdowns, state synchronization issues, conflicting objectives, account for 36.94%. Verification gaps, inadequate testing and missing validation, make up the remaining 21.30%.

Role ambiguity in harness design is, by that 41.77% figure, the single largest driver of multi-agent failure in production, ahead of coordination problems and verification gaps combined. A separate data point backs this up from another angle: roughly 88% of AI agent projects never reach production, with harness fragility cited as the main cause. Role confusion is a large piece of that fragility.

What the distribution doesn't do is tell an engineer where to intervene on a specific run. It sorts failures into categories. Getting from "this is a specification problem" to "this exact prompt's role boundary caused this exact run to fail" needs a different kind of tool.

The difficulty of automated failure attribution and the state of the art in current benchmarks

Failures sit buried inside long, language-heavy execution trajectories full of natural-language reasoning, which obscures the actual root cause. Non-determinism, the same harness configuration producing different failure modes on different runs, makes diagnosis harder fast.

Traditional software debugging assumes the step where a bug becomes visible sits close to the step that caused it. That assumption fails here. In multi-agent systems especially, a role misclassification in an early worker can propagate quietly through several hand-offs before it produces a visible failure steps downstream, by which point the trail back to the cause has gone cold.

The Who&When benchmark formalized automated failure attribution as its own task: given a failed multi-agent run, identify which agent and which step caused it. Even frontier reasoning models perform poorly here, well short of anything practically usable. Who&When Pro (Liu et al., 2026) scaled the evaluation to more than 12,000 labeled trajectories across multiple frameworks, domains, and modalities, largely because benchmarks built on a single framework weren't generalizing.

AgentDebugX (2026) takes a different structural approach, organizing debugging into a closed loop: Detect, Attribute, Recover, Rerun. Its DeepDebug component runs multi-turn root-cause diagnosis through global trajectory understanding, structure-guided investigation, and cross-examination of competing hypotheses. On the Who&When benchmark, it reaches 28.8% exact agent-and-step accuracy using qwen3.5-9b, against 21.7% for the strongest single-pass baseline. That's real progress, and it's still nowhere near the bar needed to trust unreviewed automated remediation.

A related failure pattern occurs in LLM-based diagnosis itself: the tendency to settle on a plausible-sounding root cause before the evidence has actually been exhausted. Work on continual search addresses this directly, using an iterative framework that keeps nudging the diagnostic judge across successive turns instead of letting it stop at the first explanation that fits. A separate approach proposes candidate root causes, then re-runs the system from that execution point and checks the result against a counterfactual. Counterfactual replay here confirms a hypothesis. It doesn't discover one.

The best automated attribution systems are in the high 20s for exact agent-and-step accuracy. Human review of flagged traces is still what turns an anomaly into an actual fix, and nothing in the current benchmark landscape suggests that changes soon.

Layer-specific attribution for role confusion: which harness layer to look at first

"The run failed because of role confusion" tells an engineer almost nothing on its own. The useful version of that sentence names a layer: prompt, workflow, tool, or memory. Each one produces a different symptom, and each one needs a different fix. Starting at the wrong layer burns a week debugging a prompt that was never the problem.

At the prompt layer, latent role misclassification and role-value decoupling both originate. Watch for tool calls that violate constraints set explicitly in the system prompt, persona bleed-through in generated output, and refusal patterns that shift noticeably from one prompt version to the next.

At the workflow layer, the failure traces back to orchestrator-worker context-sharing decisions and hand-off schema design. Symptoms look like a worker performing a task that belongs to a different role entirely, state-synchronization errors between agents, and retry loops crossing role boundaries they shouldn't cross.

At the tool layer, ambiguous tool schemas let injected instructions reach actual tool calls unfiltered. The confused-deputy failure described earlier, 36.8% of state-changing actions bypassing authorization via file edits in the 2026 Claude Code evaluation, is a tool-layer symptom whose root cause sits upstream, at the delegation and prompt layers.

At the memory layer, cross-turn context accumulation carries one role's reasoning into a subsequent call assigned to a different role. The writer agent that inherits the researcher's scratchpad and starts reasoning like a researcher is a memory-layer failure dressed up as a workflow-layer one.

The MAST numbers say where to look first. Specification problems (41.77%) map to the prompt and workflow layers. Coordination failures (36.94%) map to the workflow and memory layers. Start attribution work there, before spending time on tool or infrastructure layers, because that's where most of the failure mass actually sits.

A prompt can read as flawless on the page and still produce role confusion once it runs. That's the direct consequence of latent role inference operating independently of whatever label sits on the message. Only a trace, the actual tool-call arguments, the decision branches taken, the content passed at each hand-off, shows whether the intended role boundary held once the model started generating tokens. Prompt review tells you what was supposed to happen. The trace tells you what did.