On October 24, 2026, Drew Breunig published The State of Context Engineering, a write-up of his AGNTCon talk. He describes three phases of the same work: prompt engineering in 2023, context engineering in 2025, and engineering the code around the model in 2026. Throughout, the goal is to move context assembly out of model calls and into deterministic code.
Long contexts and long-running agents each brought new failures. Breunig predicts persistent memory is next, because "overly precise memories become conflicted and messy."
That prediction arrives as CIOs are being sold agent memory, often under the name "context graph." In the 2026 explainers we read, the term mostly means a store of past decisions and how they were made.
That kind of memory is useful, but it leaves out what a conflict needs. When two remembered items are both true and disagree, the agent needs a stored rule that says which one outranks the other.
What the research shows about context that contradicts itself
Breunig's diagnosis holds up, and we agree with most of it. His 2025 labels for how contexts fail were poisoning, distraction, confusion, and clash. This year he adds fighting the weights and context inertia.
His fixes (pruning, summarizing, offloading to files, isolating work in subagents) mostly control how much the model sees at once. Anthropic's engineering guidance treats context as a finite attention budget that degrades gradually. It does not expect larger windows to remove the problem.
For memory, the failure that matters most is two items that disagree, and models handle it poorly. In IBM's WikiContradict benchmark, the best model given two contradictory passages, Llama-3-70b-instruct, answered correctly 10.4% of the time. Told to consider conflicting information, it reached 43.8%.
MAGIC, from EMNLP 2025 Findings, tested five models on conflicts among linked facts. On average, they spotted that a conflict existed 59.07% of the time and located it 36.42% of the time. When seeing the conflict took several reasoning steps, identification fell from 65.14% to 40.40%.
Both studies tested 2024 and 2025 models, so current frontier models may do better. The 2026 evidence suggests capability alone does not close the gap. Camassa and Shiller tested 13 models on instructions that conflicted with the pattern of the assistant's own earlier turns.
Every model eventually followed the pattern. Adherence ranged from about 1% to 99%, with only a weak link to general capability benchmarks. The authors call their setup controlled and artificial, so we read it as a direction rather than a production rate.
A commenter in the Hacker News discussion of Breunig's post described the same behavior. Old memories get contradicted rather than deleted, and the model picks whichever one sits closer in the prompt.
Two meanings of context graph, and what each one stores
Foundation Capital popularized "context graph" as "a living record of decision traces stitched across entities and time so precedent becomes searchable." A decision trace records one past decision in plain terms: what the agent saw, what it did, who approved it, and the reason given.
Graph database vendors argue for a broader definition that adds entities, provenance, time, and permissions. In Ghost Context, Tian Pan argues that append-only memory returns stale facts beside their replacements. He recommends recording when each entry became valid and when it stopped.
Validity dates handle replacement, where a new price supersedes an old one that should expire. Many business conflicts are different, because both items are in force at once. A contract price and a promotion can both be valid the same day, and the agent must know which governs for this customer.
Recency doesn't settle it either. A commenter in a separate Hacker News thread noted that time decay fails because some old context, such as an architecture decision, outweighs recent noise.
Our position: treat a decision trace as evidence about one past case, and reuse it only when a stored rule says the new case qualifies.
Six weeks of memory on one SKU
This is an illustration, not a case study. It is built from a pricing example Trail uses. An order-management agent books orders for a wholesale business and keeps memory between sessions.
- Week 1: The agent books Customer A's order for a SKU at A's contract price and remembers that price.
- Week 3: Marketing launches a promotion on the same SKU, priced below the contract price and running to quarter end. The agent remembers it too.
- Week 4: A sales rep tells the agent in chat to give Customer B the promotion instead of B's contract price. The agent stores a decision trace with the rep's name, the date, the order, and the reason given: "promo approved."
- Week 6: Customer A orders the SKU again. Memory returns all three items. Each one is true and current.
Customer A's contract, which the finance team keeps, has a most-favored-customer clause. Company rule says the promotion applies to contract customers unless the contract has that clause. If it does, finance approves first.
Nothing in memory mentions the clause, so the agent follows the week 4 trace as precedent. It applies the promotion to Customer A and confirms the order without asking finance.
Each memory was accurate, including the trace, which recorded that a rep approved the promotion for Customer B. The trace did not record whether B's contract had a most-favored-customer clause, so it reads as precedent for any contract customer. Finance finds the order later and has to check A's contract against the promotion by hand.
The week 6 order is where Camassa and Shiller's result applies. A trace replayed as precedent is a pattern of earlier behavior, and their models drifted toward patterns even against a written instruction. A rule placed in the prompt beside the trace would not reliably settle this order.
Validity dates wouldn't expire any of these, because all three are still live in week 6. Only finance's rule knows that Customer A's clause changes the answer.
The missing item is a precedence rule: a stored statement of what outranks what, under what condition, set by the person who owns it. We have written about precedence in retrieval before. Memory adds time to the problem, because conflicting items pile up with every session.
Why memory turns conflicts into a routine problem
Each session adds entries and traces, and an append-only store keeps the older ones. True but conflicting pairs accumulate the longer an agent runs. This is our inference. No study we found measures it directly.
A model upgrade isn't a dependable fix either. In a September 2026 experiment, Backslash Security ran coding agents 12 times per condition on a fact that changed after they read it.
On a database cleanup, Sonnet 5 wiped production and destroyed the data in 10 runs. Opus 5 ran the wipe against production in 5 runs, then restored the data each time. With a retired API key, the order flipped. Opus wrote the old key all 12 times, and Sonnet never wrote it.
The stronger model changed which failure appeared, which matters to anyone planning to wait for better models. The experiment tested coding agents rather than business rules, so we cite it for that pattern only.
Memory also moves policy decisions to places nobody reviews. A rep's approval for Customer B, reused as a trace, ends up setting terms for Customer A. Nobody in finance signed off, and the agent's record doesn't show that a rule was skipped.
What to ask before you buy agent memory
Put the conflict question to every vendor and to your own team: "Two things your agent remembers both apply to this order, and they disagree. Which one does it act on, and who decided that?" If the answer is the newer item or the closer match, the store is ranking, and the model still makes the call.
Ask how the store tells replacement from coexistence. Validity dates handle a price that replaced an older one. Ask what happens to two entries that are both in force, such as a contract price and a promotion.
Check what your traces leave out. Pull ten recent decisions an agent could reuse as precedent. For each, check whether the trace names the condition that made it right, such as which clauses the customer's contract had.
Where Trail fits
Trail is the context layer your agents run on. It holds rules, exceptions, dependencies, and the reasoning behind them as a graph any agent can follow. Our definition of a context graph includes decision traces and adds the rule layer that says which item governs.
Rules and exceptions are nodes. Dependencies and overrides are edges. In the order example, the contract price and the promotion are both nodes. The promotion has an override edge to the contract price, conditioned on the contract having no most-favored-customer clause.
That clause routes the case to finance for approval. When Customer A orders, Trail returns the finance-approval rule as the one that governs. It cites the clause in A's contract and the promotion rule, and it explains why the promotion can't apply yet.
The week 4 trace stays attached to Customer B's order and the rule it applied. The agent reads it as a past decision for an account without the clause. When two rules conflict and nobody has set precedence, Trail asks the owner instead of leaving the choice to the model.
What this means for your memory budget
Memory is worth funding. Agents that run for weeks need to keep what they learn. Before you choose a memory product, decide where precedence lives and who owns it.
If precedence lives in the store's ranking or the model's judgment, the model will settle the conflicts Breunig predicts, one order at a time. Plan for a rule layer owned by the business, with memory and decision traces kept beside it.