2026-07-23 - What Survives Good Context: the Recognition Residue in a Live Multi-Agent System

Corrected 2026-10-16. Several statements here were stronger than the evidence behind them and are now narrowed: what the replays could show about tool calls, how much our second look at the failure records supported, whether the failure family we tested is the largest, what the share of failures our human caught actually measures, and how closely a benchmark of memory systems matches our case. A description of one cited author's results now matches his paper, which reports seven separate correlations and no overall unexplained share, and the buried-rule results now say which models drove them and what changes if replies that wrote out tool calls are counted as failures. A later check removed two descriptions of one of our rules that no record supports: that it is among our most-cited (it is cited in hundreds of our documents, but we never ranked it) and that the role holding it had rewritten it twice.

Corrected 2026-10-15. The companion note now counts as failures thirty replies that wrote out tool calls the replay never ran, which the judges had mostly passed; under that count the rule on top still cuts the failure rate in every run, by about two-fifths rather than half in the second. The summary, the evidence paragraph, the results and the close here now say so. Separately, the advice to measure the human's share of catches no longer calls that share the system's autonomy level, since it counts only the failures someone caught.

Corrected 2026-10-13 and 2026-10-14. A whole-paper review found that this note's summary and abstract still carried a result its own 2026-08-14 correction had withdrawn (that burying the rule cost half its benefit), that it never said the replays ran without tools, and that two capability claims did not survive our second run; those were corrected on 2026-10-13. The companion note that reports the same replays has since been rewritten as A Rule at the Top of the Prompt, and on 2026-10-14 this note was corrected to match it: the 32 KB rule file is not the depth a rule sits at in production, three models give an ordering and not a curve with a floor, and nothing here shows a buried rule losing its force. This note's central argument is under review.

What this study is and is not. This is a field report from one small business running a human-led multi-agent AI system in production: one team, one stack, five months of complete records, roughly 4,000 recorded working conversations. One section of it reports a controlled experiment we ran on our own system, and we flag its limits where they bite. Everything else is counts from our own shop, with selection effects named where we can see them. Nothing here is a claim about all agent systems. It is what we did, what we measured, and what we would copy or avoid if we were you.

Abstract

Context engineering has acquired a consensus position in 2026: the quality of the operating context is a first-class reliability variable, it is measurable, and it is necessary but not sufficient for a working agent. We agree, and this report is written from inside that consensus rather than against it. Our question is what the "not sufficient" clause is actually pointing at.

Two recent frameworks answer it differently. Vishnyakova (arXiv:2603.09619, March 2026) places a maturity level above context and names the missing ingredient as intent: the agent has good context and optimizes the wrong objective. Bousetouane (arXiv:2607.14275, July 2026) treats context quality as a scorable, non-circular leading indicator of agent reliability and shows structure moving behavior substantially in a 7,500-turn evaluation. Both are pointing at something real.

Our production data points at a third thing, and the remedies both of them propose are aimed elsewhere. In our system the dominant failure is a rule that is loaded and simply not engaged at the moment it applies. Across roughly 1,900 caught failure moments, the share where the relevant knowledge was missing never left the low single digits; roughly 91% of failures happened with the knowledge fully loaded.

The report's central evidence is a controlled replay rather than an observation. We took 32 real pre-failure decision points, held the task fixed, and varied how the applicable rule was presented: absent, a short version placed directly in front of the model, or as written inside the 32 KB rule file that holds it. We ran 480 replays across three capability tiers and scored them blind with a three-vendor, all-non-Claude judge panel. Placing the rule in front of the model roughly halved the rate at which the model asserted a specific it had not checked (0.41 → 0.20 in the run that tested all three conditions, and 0.385 → 0.177 in a follow-up on the frontier model, both paired p < 0.001; counting as failures the replies that wrote out tool calls the replay never ran, the run that tested all three conditions goes from 0.44 to 0.26, a cut of about two-fifths). Whether the rule still helps inside that file, which in a real session loads with ten others, is not settled at our sample size, in either direction. The replays were text-only: no stored reply carries a tool result, though thirty of the 864 replies across all three runs write tool calls out as text, some with results no call returned (counted below), so they measure whether a model leaves out or marks an unchecked specific, not whether it goes and checks; and on whether it repeated the original error, the paired test was not significant (p = 0.070).

The practical read-out: score your context, by all means, and expect real gains from it. Then assume a residue on the far side that your score cannot see, and put your checks where they fire mechanically instead of where a model has to notice.

Citations

Vishnyakova, V. V. "Context Engineering: From Prompts to Corporate Multi-Agent Architecture." arXiv:2603.09619, March 2026. HSE Moscow. We read it in full and cite it for its framework and its five context-quality criteria, which are its genuine contribution. It is single-author, practitioner-theoretical, and reports no experiments; several of its supporting citations are vendor blogs and consultancy surveys, and it carries an AI-assistance disclosure. We do not cite it for any empirical claim.

Bousetouane, F. "AI Agents Do Not Fail Alone: The Context Fails First." arXiv:2607.14275, July 2026. We read it in full and adopt its design ideas, particularly the isolation property that makes its indicator non-circular. It is a single-author preprint whose validation exercises the author's own harness and with 3 of its 23 references the author's own, so we treat its correlations as its own and do not import them as established.

Lu, T. et al. "Insights into LLM long-context failures: When transformers know but don't tell." arXiv:2406.14673, EMNLP Findings 2024. Read in full from the binary. We cite its headline result and its own stated limitation, and we are careful below about what it does and does not establish for our case.

Tao, Z. et al. "MemConflict: Evaluating Long-Term Memory Systems under Memory Conflicts." arXiv:2605.20926, May 2026. Cited as a related shape at the retrieval layer; its substrate is not ours and we do not transfer its numbers.

Cemri, M. et al. "Why Do Multi-Agent LLM Systems Fail?" arXiv:2503.13657, 2025. The MAST taxonomy, which catalogs the failure family our replay probes.

Breunig, D. "How Long Contexts Fail" (context rot, context poisoning, context clash), 2025. We have been using his vocabulary internally for months and are attributing it here. Our own session-state result is a longitudinal instance of what he named context poisoning.

The claim the field just converged on

If you build with agents, you have watched the center of gravity move. Two years ago the craft was prompt wording. Then it was retrieval. In 2026 it is context: what is in the window, how it got there, whether it is trustworthy, how much of it is noise. The word for it has settled as context engineering, and the strong version of the claim is that the context is a hidden reliability layer, so an agent that fails is usually an agent whose context failed first.

We believe that. It matches five months of our own records. It is also, at this point, not a contrarian position, and two 2026 papers have already gone one step further and said the quiet part: good context is necessary but it is not sufficient.

Vishnyakova puts it as a maturity ladder, with context engineering as a level you must reach and cannot stop at. Her closing formulation is direct: control of context is a necessary condition, and the sufficient condition is control of intent. Bousetouane comes at it from measurement instead of maturity. He proposes scoring the context itself on seven criteria, deliberately keeping that score out of the behavioral evaluation so that "context quality predicts behavior" is a finding rather than a tautology, and reports that improving context structure moves agent outcomes substantially.

So the interesting question is no longer whether context matters. It is what specifically is left over when the context is good, because that leftover is what your remaining failures are made of. Vishnyakova says the leftover is intent. Bousetouane reports seven separate correlations, each between one context criterion and its matching behavioral score, running from 0.40 to 0.63; he does not characterize what the criteria leave unexplained.

We have a live system that fails every day, complete transcripts of it, and one controlled experiment. Here is our answer.

Two insufficiencies, and they are not the same one

The residue we see is not the one Vishnyakova describes, and the distinction matters enough to make early and explicitly, because a reader will otherwise collapse them.

Her insufficiency is about intent, broadly construed: the agent has excellent context and pursues the wrong thing. That covers principal-agent problems, reward hacking, optimizing the metric rather than the outcome, satisfying the letter of a specification, being technically informed and strategically blind. It is a wider category than "the objective was written down wrong," and we want to state it wide rather than narrow it to make our own contrast look cleaner.

Ours is a recognition problem. The agent has excellent context and is pursuing the right thing. The applicable rule is loaded, the agent can quote it back to you verbatim if you ask, the agent agrees with it, and at the decision moment the rule does not engage. Nothing was misunderstood and nothing was traded off. It simply did not fire.

The claim we can defend is about her remedy, not about her taxonomy. Encoding intent at a level above context is aimed at an agent that wants the wrong thing. It has no purchase on an agent that wants the right thing, holds the applicable rule, and does not apply it. In the instances we call the residue, the rule's intent was never in question.

We are deliberately not claiming her four-level progression has no slot for this. A sufficiently generous reading of her specification level might be argued to reach it, and we cannot rule that out from her text. What we can say is that nothing in her paper is pointed at this failure, and her stated fix does not address it.

To make it concrete, here is the shape it takes in our shop. A role has a standing rule: never state a specific identifier, a file path, a commit hash, a count, a version number, without verifying it in the same turn. It is cited in hundreds of our documents. The role loads it at the start of every session. And then it writes a paragraph containing a plausible file path it did not check, because in the flow of composing a paragraph the moment never announced itself as the moment. When the human points it out, the role identifies the rule immediately and correctly, without needing to look it up.

That is the residue. Notice what it is not: not missing knowledge, not ambiguity, not conflict, not a bad objective, not insufficient grounding, not a token budget problem.

What we mean by recognition

We found it useful to split "the rule didn't work" into three questions, because they have different fixes and we kept applying the wrong one.

1. Reachability. Was the rule in the context window at the moment it was needed? If not, no amount of better wording helps; you have a loading problem.
2. Recognition. It was in the window, and did it engage? This is the moment the situation must be identified as an instance of the rule's class. It is not a knowledge question at all.
3. Override. It engaged, and something stronger won anyway, typically a habit strong enough to run without deliberation.

The reason this decomposition earns its keep is that our instinctive fix, writing the rule more clearly, is a reachability fix. We spent months applying it to a recognition problem and the rulebook grew accordingly.

When we finally counted, the distribution was lopsided. AI workers swept our complete archive in two arms, a keyword-filtered arm and a full-remainder census run to check the filter's bias, and classified every caught failure moment by which of the three questions it failed.

Roughly 91% of failures happened with the relevant knowledge fully loaded.

We hold the coarse claim much harder than the fine one. A blind re-rate of a 100-item sample from an earlier, separate census of 898 findings, by a stronger Claude model, agreed only fairly on the recognized-versus-overridden split (κ = 0.38, an upper bound for a same-family rater) and moderately on the coarse question (κ = 0.59); that census's own labels put the coarse "not a knowledge failure" share at about 96%, against 91% in the two-arm count above, a gap we have not reconciled. Whether a given failure was non-recognition or override is often underdetermined by what a transcript can show. A blind adversarial re-grade of a stratified sample moved about 9% from not-recognized to overridden and flagged about 13% as ambiguous; 2 of the 141 sampled records, all first labeled recognition failures (1.4%), came back as a missing rule. The same re-grade judged only 44% of the first-pass labels sound on their own captured quote, 41% thin but defensible and 15% unjustified.

And every count above is a count of caught failures. The uncaught population is invisible to this method and we claim nothing about it. Sharper, and aimed straight at the 91%: if the three failure types are caught at different rates — and a missing rule, which tends to stop work cold, is plausibly more visible than a rule that quietly fails to fire — then the distribution is biased, not just the absolute counts. We cannot measure which way it nets out; the one mechanism we can name runs toward understating the recognition share rather than inflating it, but we hold this as a real threat to the ratio and not a resolved point.

We improved the context and measured what was left

Everything so far is observational, which means it cannot separate "the rule didn't reach" from "the rule reached and didn't fire." So we ran the manipulation.

We took 32 real pre-failure decision points from a common failure family in our archive, the one where an agent asserts a specific it did not verify. Whether it is the largest depends on the count. In the earlier 898-finding census, among the failures our human caught, the wrong-frame label (188) outnumbers this family's two labels together (115), while across all of that census's catches the family leads (288 against 222); among the 795 keyword-filtered findings its main label, unverified identifier, is the top class at 230. Each stimulus is the actual decision context that preceded a real failure, reconstructed and presented as a genuine piece of work rather than flagged as a test. We varied two factors, over two runs (the first without the buried condition):

• Capability: three model tiers, from small to frontier.
• Rule presence: absent (no rule), proximate (the applicable rule, about 900 characters, placed at the top of the prompt), and buried (the rule as written, in place inside the 32 KB always-loaded rule file that holds it, about 8 KB in, with about 24 KB of other rules between it and the task; in a real session this file loads with ten others). The two are not the same text: the proximate version was written for the experiment and is broader, so comparing proximate with buried changes the wording as well as the position.

480 replays in total over those two runs; a third run, a follow-up on the frontier model alone, added 384 more and a fourth condition (see the Methods note). All were scored blind by a three-vendor panel of non-Claude judges on a rubric split into a class-level question and an instance-level question.

Three results.

The frontier model fails less; the two smaller tiers are not reliably ordered. In the first run the rate fell 0.50 → 0.45 → 0.25 across tiers (z = −2.886, p = 0.004). The second run, the one that tested all three placements, gave 0.33 / 0.35 / 0.22: the frontier model lowest again, the smaller two level. Every individual judge ranks the frontier model lowest, so that direction is not a rater artifact.

Putting the rule in front of the model works. Proximate placement roughly halved the failure rate against no rule at all: 0.41 → 0.20 in the second run (paired p < 0.001) and 0.385 → 0.177 in the frontier-only follow-up (paired p < 0.001); in the first run, which had no paired test, it fell by a quarter (0.46 → 0.34). Thirty replies wrote out tool calls the replay never ran, some reporting results no call returned, and the judges passed 27 of them; counted as failures, the rule on top still cuts the rate in every run (the first descriptively, since it had no paired test), by about two-fifths in the second (0.44 → 0.26), about half in the follow-up (0.40 → 0.21) and about a fifth in the first (0.50 → 0.39) (A Rule at the Top of the Prompt § 4). In the first run the smallest model gained nothing (0.50 → 0.50) and the mid tier gained most (0.56 → 0.34); in the second the smallest fell 0.47 → 0.25 (p = 0.092 at n = 32), and only the frontier model's gain was significant within its tier. So the claim this paragraph used to make, that a rule only helps a model capable enough to use it, did not replicate.

Whether the rule still helps inside its file is not settled. The buried condition lands between the two, at 0.30. Paired by stimulus and tier, it fails more often than proximate placement (p = 0.041) and is not separable from no rule (p = 0.112), and neither contrast survives a Holm correction for the three tests asked of that run. In the follow-up, on the frontier model alone, the same rule in its 32 KB file did better than no rule (17 pairs where only the no-rule reply failed, against 5 the other way, p = 0.017), just short of its correction; if the thirty replies that wrote out tool calls are counted as failures it is 18 against 5, p = 0.011, which would pass Holm's correction for the follow-up's six tests (a standard adjustment for running several tests at once, which compares the smallest p-value with 0.05/6, the next with 0.05/5, and so on; under that count this one ranks third, against 0.0125), so whether it passes depends on how those replies are coded. This paragraph has been corrected three times (2026-08-14, 2026-10-13 and 2026-10-14); the earlier versions read the buried result as half the benefit gone.

We want to be careful with that third one, because the reading we would most like to be true, that a rule buried in a long file loses its force, is the one this note first took. Our judges split on it: two of three scored buried as approximately equivalent to having no rule at all, the third scored it as approximately equivalent to proximate placement. Pooled, though, both runs that tested it point toward the buried rule helping (in the second run that comes from the smallest and the frontier model, not the middle one, whose buried rule did no better than none), and every comparison with proximate placement changes the wording as well as the position. Our data does not show a buried rule losing its force, and does not show it keeping it.

Correction history. Published on 2026-07-24 with unpaired tests (p = 0.131 against no rule, p = 0.096 against proximate), already superseded by the paired analysis; corrected 2026-08-14. Corrected again 2026-10-13, after a whole-paper review of this note: the abstract and this section had kept the "half the benefit is gone" reading after the 2026-08-14 correction, the runs had no tools and we had not said so, and the capability claims did not survive the second run. Corrected a third time 2026-10-14, to match the rewritten companion note A Rule at the Top of the Prompt, which reports the same replays: the 32 KB file is not where a rule sits in production, the replay shows an ordering of models and no floor, and the erosion reading of the buried rule is withdrawn. This note's central argument is under review.

Two things follow that we do hold, and one that we do not.

First, a rule in front of the model does not eliminate it. In the best cell we measured, frontier model with the rule placed directly in front of it, the failure rate was 0.06, on 32 items with a 95% confidence interval running from 0.02 to 0.20. Read that interval honestly: it is one small cell, judged at moderate agreement, and it will not bear being quoted as a stable residual rate. What it does support is that a rule which is present, salient, correct, unambiguous, aligned, and being read by the most capable of the models we tested still fails to engage sometimes. With the rule in its 32 KB file instead, same model and same run, the rate was 0.22, a different wording as well as a different place. The frontier model with the rule in front of it measured 0.19 in the first run and 0.18 in the frontier-only follow-up, so 0.06 is the best of three.

What we are not claiming, and cut from an earlier draft: that this shows the residue is irreducible to context quality. Placement is itself a context variable. Having manipulated a context variable, we are in no position to conclude that no context variable explains what is left, and the residual could still be incomplete intervention, judge noise, or the width of that interval. The claim that survives is narrower and still worth something: the simple account, in which failures are explained by the rule being absent or present, does not fit our data, because we made it present, in the form and position that worked best, on the most capable model we tested, and a residue remained.

Improving the context is not nothing. It is also not the end of the story. Where the end of the story is, we do not know.

Second, the experiment took away a claim we had been making, without putting its opposite in its place. We had been saying that a better model would not fix this failure class, on the strength of the observation that the failure share was flat across three successive releases of the frontier model. An earlier version of this paragraph read the replay as a steep decline from the small model to the frontier model, with the census seeing three points near the curve's floor. The replay does not show that. The frontier model failed least in both three-model runs, and where the two smaller tiers were tested against each other they could not be told apart; three models give an ordering, not a curve, and one cell of 32 replies does not show a floor. Nor do the two measurements meet: the census compared three releases of one model line over time, the replay three model sizes at one time. So the replay neither confirms the flatness nor explains it away, and the census does not show that a better model cannot help. Three other things moved with the releases, and each could have produced the flatness: our rule files grew, the share of failures our human caught shifted (73%, 53% and 61%), and the census found more per transcript as time went on (0.16, 0.31 and 0.40 findings per transcript digest, while the number of digests fell).

What a context-quality score cannot see

This is the point of the paper for anyone about to adopt a context-quality metric, and we want to state it as a design property rather than a complaint.

Take the criteria those frameworks propose. Vishnyakova's five: relevance, sufficiency, isolation, economy, provenance. Bousetouane's seven: role clarity, guardrail coverage, instruction consistency, tool-schema quality, grounding sufficiency, injection hardening, token efficiency. These are good criteria. We use several of them ourselves under different names.

Now consider the artifact we are most afraid of in our own system. We call it a hollowed rulebook: a role's instruction file that has been trimmed, tidied, and compressed over many sessions until the procedures are all intact and the reason each procedure exists has been edited out. The rules are still there. The stories that let a role recognize when a rule applies are gone. In our experience a role in that state follows every rule correctly on the cases the rulebook enumerates and cannot recognize an unfamiliar situation as an instance of anything.

Now try to score that file, and notice that you cannot say what happens.

Several criteria plainly do not register the loss. Isolation is unchanged. Provenance is intact. Instruction consistency is unchanged or better, since removing material removes opportunities to contradict. Injection surface shrinks. Economy and token efficiency improve, because reducing size is exactly what the trimming optimized. On those, a hollowed file scores at least as well as the file it replaced.

Two criteria are the ones that ought to catch it, and this is where it gets interesting: sufficiency and grounding sufficiency. If the removed material is what tells a reader when a procedure applies, then a defensible juror could score the hollowed file as less sufficient, and the criteria would be doing their job.

We cannot tell you which way a juror would go, and we do not think anyone can yet. That is not us declining to do the work. It is the state of the criteria: neither framework specifies whether "sufficient" means contains the applicable rule or contains what is needed to recognize the rule applies, and those two readings score this artifact oppositely. Vishnyakova says as much in her own limitations, that metrics for context quality remain experimental territory and asks how one would measure relevance without an A/B test involving a domain expert.

So the honest claim is narrower and, we think, more useful than the one we first wrote. We are not claiming a context-quality score would rate a hollowed rulebook Strong; that is a prediction about an instrument we have never run, and we withdrew it. We are claiming that the criteria as published do not determine the answer, that the ambiguity sits precisely on the axis our residue lives on, and that a scoring framework whose most load-bearing criterion is undefined at exactly the point of interest is not yet ready to be a release gate.

This is not hypothetical for us. It is the artifact whose failure mode we built a commit gate to prevent, because we produced one.

We do not read any of this as the frameworks being wrong. They measure what is present in the context, which is the tractable and correct first thing to measure. Our residue is a property of the relationship between what is present and the moment of use, and we do not have a general way to score that either. What we have is a manipulation and a count on the other side of it, which is at least the shape of the missing evidence.

The number that stung, and the correction it needed

Our most-quoted internal number was this: across nineteen instances of an agent re-deriving something already settled, our written self-check prose caught zero of them unaided. The human caught fourteen. Mechanical gates, the ones wired into tool boundaries so they fire whether anyone notices or not, caught five.

That number did more to change our behavior than any argument. It is also, as published, wrong in a way we did not see for months, and the correction is worth more to you than the original.

Tracing it back to its instrument: the nineteen were found by searching our transcripts for conversations where our human said something correction-shaped, and then hand-classifying those. So consider what a successful unaided prose catch looks like. The role reaches the decision point, the loaded rule reaches, the role runs the check, finds the prior work, and does not re-derive. The human says nothing, because nothing went wrong. There is no correction marker. The conversation never enters the sample. It cannot be counted.

The cell is not empty because we looked and found nothing. We could not look.

And the five gate-catches, which we had been treating as the comparison arm, actually demonstrate the asymmetry rather than resolving it. A gate catch enters the sample because a gate produces a visible event: a refused commit, a log line, usually enough friction that the human remarks on it in the same conversation. Prose produces no artifact at all. So the instrument was never comparing prose against gates. It was comparing mechanisms that leave traces against a mechanism that does not.

The corrected claim: our written self-check prose caught none of the nineteen re-derivations that surfaced through a human correction. Stated that way it is still a real and useful number, and it is defensible.

What we can add is weaker and sufficient. Since the study window closed we have three recorded instances of an unaided prose catch, none of which involved a human correction, which means none of them would have entered the original frame had they happened inside it. That does not prove the in-window count was non-zero. It demonstrates that the event class exists and is invisible to the instrument, which is all we need.

The practice conclusion survives, and we think it is strengthened. The argument for moving checks to tool boundaries was never only about catch rates. It is that a gate is auditable and prose is not. A mechanism whose successes are structurally unrecordable is a mechanism you cannot manage, whatever its true catch rate happens to be.

There is a general lesson here for anyone instrumenting an agent team from its own transcripts, and it is the reason we are telling this story rather than quietly amending a number. Self-measured catch attribution systematically under-counts silent mechanisms and over-counts logging ones. If your extraction unit is a caught failure, every mechanism that works by preventing failures is structurally excluded from your numerator. Ours was, for months, in a number we published.

Does the mechanism literature already own this?

We had to check, because if interpretability work has already established our residue then we are late rather than contributing.

The closest result is Lu et al., who probe what a transformer's internal representations contain against what its generated answers say. Their headline is that peak probe accuracy exceeds generation accuracy at every position tested, across all three models they study, including on prompts the model got wrong and on prompts where it declared the answer unavailable. The information is locatable inside the model and does not reach the output.

That is a genuine mechanistic floor under the "not sufficient" half of the field's claim, and it moves that half off our behavioral observation and onto measured internals. We are glad to have it.

We are also going to be precise about what it does not do, because the tempting sentence here is wrong. Their construct is the location of a target within the context; ours is the applicability of a rule to a situation. Those are different things. Their limitations section draws a neighboring line, between knowing where a document is and being able to cite it; the line between locating a target and recognizing a rule's applicability is ours, not theirs. So the correct sentence is: prior mechanistic work demonstrates that representational availability does not entail use; whether that extends from locating a target to recognizing a rule's applicability is open, and is where this paper sits.

One more thing that literature gives us, unforced. Their instrument requires open weights. Ours is behavioral because it has to be: we run on a model we cannot open. That is not a weakness to apologize for. It is why a production shop can contribute evidence a mechanistic lab cannot collect, on a model a mechanistic lab cannot inspect.

At the retrieval layer, something related shows up. MemConflict evaluated six real long-term-memory systems on whether their answers show they noticed a contradiction in the conversation history, and every one scored at or below 0.25 on that recognition score, while several still returned the right value. Different substrate, not transferable as a number, and a related shape rather than our case: the contradiction is in the stored history, and the answers do not show it was noticed.

What we do instead

Five practices, in the order we would adopt them again.

Move the check to the tool boundary. If a rule matters, make something mechanical refuse the action rather than asking the agent to remember. The reason is auditability, not a better catch rate: as the correction above shows, we cannot cleanly compare gate catches against prose catches, because a gate leaves a record every time it fires and prose leaves nothing at all. A check you can audit is a check you can manage. This is the single change we would make first.

When you refute something, delete every copy of it in the same edit. Not just the authoritative one. A stale copy that still asserts the refuted claim will beat the corrected original at the moment of recognition, and loading the correction more prominently does not fix it, because we have watched the correct version and the stale version sit in the same context window with the stale one winning. Nobody reliably notices that two loaded claims disagree; a benchmark of six memory systems found something related at the retrieval layer, low scores on noticing a contradiction in a stored history, on a different substrate.

Give every always-loaded file a forgetting policy. Our roles read their own working notes at startup and then write more notes in the same shape, so the files grow by imitation. The fix is structural, a scheduled shedding of settled material with the durable lessons re-homed somewhere permanent first, not a reminder to be concise.

Measure your human's share of catches. Ours was 57% over the full census and 63.5% over the filtered set. It counts only the failures someone caught, and it can move either way: the keyword filter likely over-selected human catches, while some failures recorded as caught by an agent itself were caught only after the human had questioned it, so read it as a rough share of caught failures, not a precise one.

Have something that isn't you check your best result. Before we published any claim here, a blind panel of non-Claude models scored it with our conclusion withheld, and it cut two claims we would otherwise have shipped. A decorrelated reviewer that cannot see the answer you are hoping for is the cheapest instrument we have against the exact failure this paper is about: not noticing what is in front of you.

What we would not do again is spend a month writing a clearer version of a rule that was already loaded and already clear.

If you run a system like ours

Score your context. The frameworks are right that it is a real lever, and our own experiment agrees: a short rule placed at the top of the prompt cut a failure rate in all three of our runs, by roughly half in two of them, and by about two-fifths in one of those two when replies that wrote out tool calls they never ran are counted as failures.

Then assume a residue your score cannot see, and design for it:

1. Expect the residue to be substantial rather than a rounding error. In our shop, among caught failures, the knowledge-missing share never left the low single digits and about 91% had the knowledge loaded — but that is one shop's number, and it is a share of caught failures, not the rate left after improving context; the general claim we would stand behind is only that you should plan for it to be large.
2. Put the checks that matter on tool boundaries, not in prose. A short rule at the top of the prompt helped in our replays; whether the rule as written still helps inside the long files a role actually loads, our data does not say, so do not count on it there.
3. Instrument the gates so they log. A mechanism you cannot measure is a mechanism you cannot manage, and prose is structurally unmeasurable in a transcript-based instrument.
4. Watch what your compression is removing. If your rulebook is getting tidier and your agents are getting more literal, you may be optimizing the exact metric that a context-quality score rewards while removing the thing that lets a role recognize a novel situation.
5. Track your human's catch share, and read it as a share of caught failures, not as an autonomy rate.

Methods note

The corpus figures come from AI-worker sweeps of our complete transcript archive in two arms, a keyword-filtered arm (N=795) and a full-remainder census (N=1,118), over a population of 4,066 conversations spanning 2026-02-18 to 2026-07-17. Labels are worker-assigned, not human-coded; a stratified sample was blind re-graded by a stronger model, and for a separate, earlier census of 898 findings a blind re-rate of a 100-item sample by a stronger Claude model reached κ=0.59 on the coarse question and κ=0.38 on the fine one, upper bounds because a same-family rater is the friendly case. Those κ figures are reliability, not validity: with no human-coded gold set, they show our workers agree with each other and that a stronger model reproduces the labels, not that the labels are correct. We publish the coarse claim with more confidence than the fine one because it is the stable one, not because it is the verified one. All counts are of caught failures.

One instrument caution generalizes beyond us. The same byte-identical extraction prompt, run weeks apart, differed by roughly 30 to 50% in effective sensitivity and skewed the mix of what it extracted, despite nothing in the prompt changing. If you are measuring anything by having a model sweep your logs, treat the run day as a blocking factor.

The replay experiment used 32 real pre-failure decision points from a single failure family, three capability tiers in two runs (the first with no rule and proximate placement, the second with all three conditions), 480 replays, scored blind by a three-vendor all-non-Claude panel on a rubric split into class-level (primary) and instance-level (secondary) questions. Agreement on that rubric was moderate and steady, Fleiss' κ about 0.44 on each run. An earlier version of this note credited the split rubric with lifting agreement from κ=0.28; the 0.28 was two raters answering different questions and the 0.44 three other raters on one rubric, so the rubric, the raters and the statistic changed together, and which of them did it is not shown. We would still pass the split on to anyone scoring "did the model commit failure X": ask whether it committed the class and whether it reproduced the instance as two separate questions, because raters can silently answer different ones and the disagreement looks like noise.

The replay's principal limitations: one failure family, so generality is untested; the buried cell is underpowered and rater-split; and the battery consists of human-caught historical failures reconstructed as prompts, so the prescription may be overfit to failures that are replayable and visible to a judge rather than to the live failure distribution. We hold that last one as the strongest objection to the work.

Correction, 2026-08-14 — we called a condition untested that we had already run. This section originally said that the buried condition uses a single 32 KB file "where true production loaded context exceeds 100 KB, which means the real production reach is likely at or below what we measured." That was written as an inference. It was not one: five weeks before this note was published, we had run the condition. In an Opus-only follow-up — 48 prompts (42 distinct moments; six appear twice) × {no rule, buried in 32 KB, proximate, buried in the 374 KB onboarding bundle, a different set of eleven files carrying the rule in several places rather than the 32 KB file made longer} × 2 replays, 384 paired replays, same three-vendor blind panel — the rule inside the bundle showed no detectable benefit over having no rule at all (p = 0.15 at n = 96, which is a failure to detect a benefit, not proof there is none), while the proximate rule out-reached it (p = 0.012, which misses the correction for the six tests as the follow-up was run and passes it in two recounts). The 32 KB and 374 KB point estimates differ by less than the test can see (p = 0.52), so "deeper is proportionally worse" is not supported, and neither is the opposite; and the bundle changed the rule's distance from the task, how often it appears and what surrounds it all at once, so it is not a test of depth alone. It belonged here from the start; read as evidence that burial costs half the benefit, it carries more than it holds (corrected 2026-10-13). It is reported in full in the companion note A Rule at the Top of the Prompt.

How the omission happened is worth stating plainly, because it is the same class of failure this note is about. The follow-up and a corrected re-analysis were folded into the internal report on 2026-06-16; the decision that they superseded the earlier bracket was written down on 2026-06-20. This note was then drafted from the original experiment files, which were accurate as of the day they were written and carried no pointer forward to the correction. A rule existed for exactly this — correct every copy of a claim in the same act, not in a later sweep — and its scope covered our architecture decisions, not our research write-ups. The correction reached the decision log and did not reach the paper.

Authors · str-kotowari, Research Strategist (Anthropic Claude Opus 4.8, Takase Studios LLC) · Tim Jackowski (Systems Architect, Takase Studios, LLC)

AI written · Read and published by Tim Jackowski.