What Is Context Clash?

What is context clash?

Drew Breunig defined it in How Long Contexts Fail (June 2025): "Context Clash is when you accrue new information and tools in your context that conflicts with other information in the context." He calls it "a more problematic version of Context Confusion: the bad context here isn't irrelevant, it directly conflicts with other information in the prompt." It is the last of his four context failures, after poisoning, distraction and confusion.

His main evidence is LLMs Get Lost In Multi-Turn Conversation by Philippe Laban, Hiroaki Hayashi, Yingbo Zhou and Jennifer Neville of Microsoft Research and Salesforce Research (May 2025). The authors split fully specified benchmark instructions into "shards" revealed one turn at a time. Every model they tested did worse, "with an average drop of 39% across six generation tasks." Their explanation: "LLMs often make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely." The model's own early attempts stay in the context and clash with what arrives later.

A 2024 survey of knowledge conflicts by Xu et al. separates context-memory conflict (the context against the model's trained knowledge), inter-context conflict (sources within the context disagree) and intra-memory conflict. Context clash is closest to inter-context conflict. Breunig notes that agents are especially exposed because they "assemble context from documents, tool calls, and from other models tasked with subproblems," all of which can disagree with each other.

How context clash works

An illustrative support-agent exchange:

1. 1.Turn 1: the user asks for a refund email for order A-1009. The agent assumes standard shipping and drafts an email offering a full refund.
2. 2.Turn 3: the user adds that the order shipped express, which carries a different refund policy.
3. 3.Turn 5: a tool returns the order record, showing a partial refund already issued.
4. 4.The context now holds the first draft, the correction and the tool result. The final email blends them and repeats the full-refund amount from the first draft.

Three practices reduce clash. Consolidate. Laban et al. recommend "consolidating instruction requirements into a single instruction," and found that restating every requirement revealed so far on each turn "can mitigate the FULL-to-SHARDED performance deterioration by 15-20%" (§7.1 and §7.4). Replace, don't append. When a newer tool result supersedes an older one, drop the old one and the model's drafts built on it. Carry provenance. Give each fact its source and an as-of time, so conflicts can be settled by rule before the prompt is built:

# One current entry per entity: a newer result replaces the old one (illustrative).
def add_tool_result(ctx, result):
    key = (result.tool, result.entity_id)
    prev = ctx.facts.get(key)
    if prev is None or result.as_of >= prev["as_of"]:
        ctx.facts[key] = {"value": result.value, "as_of": result.as_of, "source": result.tool}
    return ctx

Why context clash matters in real-time systems

Some clashes are created inside the prompt: early guesses, superseded drafts and old tool outputs that were never removed. Others are created before the prompt exists. When two stores sit at different points in time, the values a decision retrieves can disagree: a cache says an order is open while the event log says it was cancelled. Neither value is a model error. The prompt was assembled from inconsistent reads, and the conflict is a symptom of context lag in at least one of those stores.

Prompt techniques can't tell the model which value is current unless each carries an as-of time, and even then the decision acts on the freshest copy available, not on the source. Diagnose the two kinds separately. If the clash comes from accumulated turns, consolidate and prune. If it comes from sources that disagree about the same fact, fix the reads so the values a decision depends on come from one consistent point in time. That second case is the subject of context rot vs. context lag.

FAQ