Context inheritance: who wrote the context decides whether it helps
Give a coding agent your repository's context — the decisions, the constraints, the conventions — and sometimes it transforms the agent's behavior, and sometimes it does nothing at all. That inconsistency bothered us enough to run a pre-registered experiment on SWE-bench Verified. The answer turns out to be one variable: the capability of whoever wrote the context relative to the agent that reads it. A small model doubles its ability to find the right file when a stronger model wrote its context — and gains exactly nothing from context it wrote itself. We call the pattern context inheritance: repository context is senior knowledge, and its value flows downhill.
The puzzle: same context, opposite outcomes
Metatron's whole premise is that a repository should carry its own agent-facing context — decisions and constraints as versioned markdown the agent consults before it writes code. We had already shown agents actually read it when the contract is written as a procedure. The open question was harder: once they read it, does it help? And the honest early answer was "sometimes, a lot; sometimes, not at all" — which is not an answer you can ship advice on.
So we froze a protocol — hypotheses, conditions, metrics, and an analysis plan — timestamped it in git before collecting any confirmatory data, and ran it. Two executors: a small local model (Gemma 3, 8B) and a frontier model (Claude Opus 4.8). Real historical bugs from large open-source Python projects, graded by the projects' own hidden test suites. Every episode a fresh model session in a freshly cloned checkout — no memory carried across runs. The variable we cared about wasn't whether context was present, but who authored it.
The capability gradient
Hold the reader fixed at the small 8B model and vary only who wrote its context. Measure whether it edits the same file the project's real fix touched — "localization," a clean proxy for working in the right place.
- No context: 21.1% localization — the baseline.
- Context the 8B model wrote itself (its own promoted lessons from earlier tasks): 21.1%. That is +0.0 points, p = 1.0 — identical to no context, to the decimal.
- Context written blind by a frontier model (given only an old checkout and topic names, never the bug): 47.2%. +26.1 points, p < 0.0001.
A stronger author more than doubles the weak model's
ability to find the right file. The model's own lessons move it not one
inch. And this isn't because the 8B model can't use context — it
uses frontier-written context decisively. It just can't write
context worth reading. Inspect what it recorded and you see why: it writes
down tooling tactics ("run pytest with -x"), while the frontier
model, under the identical prompt, writes down the actual repository
constraints — where fixes belong and which pitfalls to avoid.
The shape matters. It's not a smooth dose curve where more capable authorship buys proportionally more benefit; a gold-standard "oracle" author (shown the real fix) landed at 42.8% — statistically tied with the blind frontier author. It's a threshold: context helps if and only if its author outranks its reader. Below that line, nothing; above it, roughly double.
What gets inherited flips at the top
Now make the reader the frontier model and let it run the full lifecycle — work a task, distill what the failure taught, carry that lesson to a different task sharing the same constraint. On roughly one-hour-class bugs it resolved 72.9% vs 58.3% without the lifecycle (+14.6 points, p = 0.041) while spending 32% fewer tokens per resolved task (81.8K → 55.7K).
But here's the inversion. Lessons distilled from the answer key — the project's actual fix — transferred nothing at the frontier (statistically indistinguishable from no context), even though answer-derived context was the strongest author for the weak model. Read it plainly: a weak model needs to be told where things are; a strong model already localizes and needs to be told where it will go wrong. Answer-derived lessons encode solutions; failure-derived lessons encode traps and process. What is worth inheriting depends on who's inheriting it.
Delivery: selection beats volume
Content is only half of it; how you put it in front of the agent is the other half. Holding the content fixed and varying delivery for the small model across 800+ episodes per arm: a sharded store the agent reads selectively (an index, then only the relevant decision files) beat a single monolithic file on localization and paid roughly three times fewer context tokens (305 vs 902 per episode). The monolith actually landed below the no-context baseline while costing the most — dumping everything into the window crowds out the task. Making the agent choose what to read both helps and costs less. It's the same lesson as the gradient, one level down: a reader inherits more when it inherits selectively.
The honest ceiling
One result we could have buried and didn't. Point the frontier model at a broad, random sample of well-specified bugs — not the constraint-sharing cases the layer is built for — and it resolves 90.9% with no context at all. On that distribution, no delivery mechanism beats the baseline, and the selective store costs more tokens, not fewer, because a capable model turns "read what you need" into thorough exploration.
That is not a knock on repository context; it's the boundary of when it pays. A frontier model fixing a crisp, isolated bug it already localizes has no headroom for context to add. The value shows up exactly where the ceiling isn't: weaker and cheaper models across the board, and strong models on the work that is ambiguous, convention-laden, or re-hits a constraint the team already settled — the parts of real repositories that SWE-bench's isolated fixes don't capture. Inheritance needs an author above the reader and a reader below its ceiling.
What this means if you run agents
The findings collapse into three practical rules.
1. Author your context with the strongest writer you have.
A human expert, a frontier model, or distillation from authoritative fixes —
never your cheap working agents authoring their own. A weak self-taught loop
equals no context, exactly.
2. The benefit accrues to the cheap agents. One frontier
authoring pass, paid once, propagates senior-level navigational knowledge to
every local agent that later reads the repository, at zero marginal inference
cost. Expensive knowledge, written once, read cheaply forever.
3. Keep it selective. Shard the context and let agents read
the slice they need. Volume is not the goal; the right slice at the right
moment is.
This is exactly the shape Metatron is built around: decisions authored and curated by the people (or models) who know the codebase, stored as sharded markdown in git, served to whatever agent shows up next. The research names the reason it works. Context is senior knowledge — and a repository that carries it lets every junior agent inherit it.
The full write-up — architecture, the pre-registered protocol, every number, and the deviations — is in the research repository, released for replication. A note on scope we hold to throughout: this validates the pattern and its delivery, not any automatic extraction step. The context in the study was written by hand and by blind models on purpose, so the effect we measured is the author's capability and nothing else.