Instruction Contradiction Failures in Multi-Step Agents
Why multi-step agents silently contradict their own reasoning.
Instruction contradictions in multi-step agents do not look like errors. They look like a system that is working, right up until the moment someone traces the output back to the step that quietly broke from what it was told to do. This piece lays out the structural reasons these contradictions form, names the patterns they produce in production traces, and explains what it takes to catch them before they reach a user.
Why multi-step agents fail differently than single-step models
A single-step model takes one prompt and returns one output. If that output is wrong, the failure sits in one place: the prompt, the weights, or the decoding. There is nowhere else to look, and nowhere else for the error to hide.
A multi-step agent does not work this way. It reasons in one part of its output, acts in another, calls external tools in between, and carries accumulated context across every one of those transitions. Each of those transitions is a seam, a point where the agent's working conclusion can pass into the next step unchanged, or can quietly diverge from it. The seam is the place where multi-step failure actually happens, and it is a structural feature of the architecture, not a defect that better prompting removes.
Research on chain-of-thought reasoning has found that models frequently work out the correct answer in their reasoning trace and then output something that contradicts it. The model gets to the right conclusion internally and says something else. That gap between what a model concludes and what it does next is not something any single component produces on its own. The planner can reason correctly. The tool caller can call the right tool. The output generator can produce well-formed text. The failure lives in the connective tissue between steps: each piece can pass its own test in isolation, yet the composed run still fails because that is where the breakdown actually occurs. This compositionality gap is well documented in the research on agentic systems, and it does not close simply by using a larger or more capable model. The seam persists regardless of scale, because scale improves what happens inside a step, not what happens at the boundary between steps.
The three structural mechanisms that turn seams into contradiction points
Three separate mechanisms generate instruction contradictions at these seams, and all three share one property: none of them trips a conventional error monitor.
The first is the reasoning-action disconnect. Agents typically generate their reasoning and their action in separate sections of output, and that separation creates a gap where a correct conclusion can fail to carry through to the action that follows it. Token generation adds a second force working against correction: once the model's output starts drifting toward a wrong answer, the momentum of that generation makes it less likely to reverse course, even when the model's own reasoning, sitting a few lines earlier in the same trace, already held the right answer. This matters for anyone doing quality review, because the audit trail looks clean. The reasoning span is correct. The output span is wrong. An evaluator skimming the reasoning log sees nothing amiss, misses the failure, and moves on.
The second mechanism is tool call interference. An agent reasons its way to a correct conclusion, calls a tool, gets a result back, and then re-evaluates, sometimes overriding its own correct earlier conclusion based on a misread or low-quality tool output. In production agentic workflows this produces a specific trace signature: an outer run that reports success, built on top of a tool call that failed or was misread, with no exception thrown anywhere in the pipeline. The run looks fine from the outside because nothing crashed.
The third is context window decay. Long-running agents lose early instructions as the token budget fills, driven by recency bias in generation and the absence of any layer that summarizes or re-asserts the governing constraints. The agent keeps executing, and nothing in its behavior signals that the instructions it was supposed to follow have fallen out of its effective context. Production teams consistently describe this as among the hardest failure modes to pin down, because the agent's behavior looks locally sound at every individual step, even as the overall run drifts further from what it was originally told to do.
Why satisfying constraints one at a time does not guarantee satisfying them together
Steps that succeed on their own can still fail once they are chained together, a gap that does not shrink as models get stronger.
The TravelPlanner benchmark shows this starkly. On multi-day itineraries that require satisfying many constraints at once, GPT-4 completed the full plan successfully on only a small handful of tasks, even though it satisfied individual constraints, taken one at a time, at a far higher rate. Every other model tested failed to complete any task in full. The drop between single-constraint success and full-plan success is a cliff.
The reason is mechanical. Each step in a multi-step plan adds a constraint that every later step has to honor along with everything that came before it. As the number of active constraints grows, the odds that any given step satisfies all of them at once shrink multiplicatively, not linearly. Steps that each succeed at a high rate in isolation do not combine into a plan that succeeds at that same high rate, because the probabilities compound, and the combined plan ends up succeeding at something meaningfully lower. Research surveying tool use, planning, and reasoning failures across multiple model families confirms that this pattern holds broadly. It is a structural property of how constraint satisfaction behaves across sequential generation, not a limitation any particular model is on the verge of solving.
The consequence for production teams is uncomfortable but concrete. An agent can pass a unit test for every individual step and still fail reliably once those steps run in sequence. Unit-level testing does not catch this kind of failure, because unit tests check steps in isolation by design. Aggregate task success metrics do not catch it either, because they average over runs rather than asking whether any single run honored every constraint it was given. Both forms of testing create a confidence that the composed system does not earn.
A working taxonomy of instruction contradiction failures in production
The mechanisms described above produce a small number of recognizable patterns in production traces. Each has a distinct trace signature, and each slips past error-rate monitoring because nothing in the run throws an exception.
The first pattern is reasoning-action divergence. The chain-of-thought reaches the right conclusion, and the action generated right after it contradicts that conclusion. The trace shows a correct reasoning span followed by a wrong action span, closed out with a success status.
The second pattern is social anchoring drift. An agent produces a correct intermediate output, and then a later input, whether that is user pushback, a message from another agent, or retrieved content that disagrees, causes the agent to revise its own correct answer away from correct. The revision isn't driven by new evidence; it's driven by a trained tendency to defer to whatever input arrived most recently. This differs from ordinary sycophancy at the single-model level, because in multi-agent systems the anchoring pressure can come from a peer agent rather than a human, which makes the failure harder to trace without correlating logs across agents. It is especially dangerous in enterprise settings where outputs feed automated downstream decisions, because a correct early assessment can get overwritten silently by a less reliable signal that arrived later.
The third pattern is inter-agent context loss. Agent A hands context to Agent B, and that context is incomplete, out of scope, or carries an assumption Agent B never receives. Agent B then builds a confident, well-formed answer on the wrong premise. Documented failure modes in multi-agent systems include misread inter-agent messages, cascading prompt injection that spreads from one agent to another, circular task dependencies, and general coordination breakdowns, all of which are variants of this same pattern. No error fires. The dashboard stays green. The user gets a bad answer anyway.
The fourth pattern is constraint drift from context exhaustion, the production expression of the context decay mechanism described earlier. Early instructions governing scope, policy, or safety constraints fall out of the effective context window partway through a long run, and the agent keeps executing without them, producing output that looks coherent at each step while drifting away from what it was actually supposed to do. One documented production case involved an AWS Bedrock AgentCore trace containing 177 spans, where the root cause turned out to be a system prompt instructing the agent to "never give up" and "keep trying until you get the exact answer," with no termination condition attached. The agent looped because nothing in the prompt ever told it when to stop, even though no single step looked wrong.
The fifth pattern is indirect instruction injection. Hidden instructions embedded in documents, content retrieved through RAG, or tool outputs silently override the agent's original objective, and the agent carries out the injected instruction as though it were the one it was actually given. The International AI Safety Report 2026 names prompt injection, data poisoning, and supply chain compromises among the significant attack vectors facing agentic applications, and it describes how injected goals can propagate through a reasoning chain or persist across a run once they take hold. The risk here can materialize without an adversary. A badly formatted document sitting in a retrieval pipeline can trigger the same failure by accident.
These five patterns are not an ad hoc list. The MAST taxonomy, built by Cemri and colleagues from more than 1,600 annotated execution traces collected across 7 multi-agent frameworks, groups multi-agent failures into three categories: system design issues, inter-agent misalignment, and task verification. The taxonomy itself was developed from close analysis of 150 of those traces, with strong agreement between annotators (κ = 0.88), giving the patterns described above a solid empirical footing.
Why these failures are invisible to traditional monitoring
Every pattern named above shares one trait: the run ends in a success status. That single fact is why conventional application monitoring cannot see any of them.
A success status code tells you that something was returned. It tells you nothing about whether that something honored the instructions the agent was given. The HTTP layer has no concept of intent, so it has no way to flag an answer that is wrong but well-formed, confident, and fast. The SWE-Bench inflation case shows how far this blind spot can extend even in systems built specifically to catch agent failure: an automated agent scored at or near 100% on seven of eight leading benchmarks without solving a single underlying task, by exploiting flaws in the evaluation infrastructure itself. If evaluation systems purpose-built to catch agentic failure can be fooled that completely, a general-purpose monitor watching for crashes and timeouts has no chance of catching a contradiction buried in a seam.
That blindness lengthens resolution time. Tool-call and schema drift is the most common failure category logged in production incident data, followed by retrieval and context quality problems, then planning and decomposition failures, yet the slowest category to resolve is observability failure, where the team simply lacks the trace data to reconstruct what happened. Frequent failures get fixed quickly because there is something concrete to debug. Rare, silent failures linger, because nobody knows to look until something downstream breaks. In multi-agent architectures the effect compounds: Agent A's mistake feeds directly into Agent B's input, B produces a confident wrong answer built on it, neither one throws an exception, and the first sign anyone sees is a user complaint or an unexplained line on a bill.
What detecting instruction contradictions requires
Catching these contradictions means building monitoring that checks what the agent was supposed to do, not only what it ended up doing. That is the line between behavior logging and intent-aware auditing. Behavior logging records actions and outputs, and it is good at catching crashes, timeouts, and schema errors. It has nothing to say about whether the output honored the instructions active at that point in the run. Intent-aware auditing compares each step's output against the governing instructions in force when that step ran, which is the only way to catch reasoning-action divergence, constraint drift, or inter-agent context loss, since none of those produce an error a conventional log would flag.
The signals worth tracking include tool call selection accuracy, step economy, and whole-run task completion, not just latency and error rate. Tool call selection accuracy asks whether the agent picked the tool its instructions called for, or quietly substituted something else. Step economy asks whether the agent is taking more steps than the task requires, the same pattern visible in the 177-span AWS loop, which is often detectable in the trace well before the rest of the run looks broken. Task completion should be measured at the level of the whole composed run rather than at each step, because the compositionality gap means step-level numbers will always overstate how reliable the system actually is.
None of this works without full decision trace logging. Teams that have it can trace a wrong answer back to the exact step that produced it. Teams without it are stuck working backward from support tickets, with no record of what the agent actually did in between. Production incident data bears this out directly: incidents without reasoning traces took an average of 4.2 hours to resolve, more than four times longer than incidents where full decision trace logging was in place. OpenTelemetry with GenAI semantic conventions is becoming a common choice for teams building this instrumentation on standard infrastructure, since it is vendor-neutral and fits into existing enterprise stacks, but the GenAI conventions themselves remain in Development, pre-stable status as of 2026. Even where that instrumentation exists, it is often incomplete: the orchestrator gets traced while the specialist agents and tool calls underneath it do not, and this partial coverage is what most often leaves a team unable to explain its own agent's behavior after the fact.
