The Unified Context Layer

A floor of specialist agents has a failure mode no single agent has: parallel hallucination. One agent guessing wrong is a bug. Ten agents each acting on their own slightly-wrong picture of the system — which services exist, who owns them, what the conventions are — is an incoherent machine that looks busy while drifting apart. The fix is not better agents. It's one shared picture: the unified context layer.

One source of truth, read and written

The context layer is the floor's collective memory — a live catalog every agent reads before acting and writes back to after:

• Services and ownership — what exists, who owns it, what tier it is, how it scores
• Standards — the conventions, security posture, and golden paths agents must build within
• Docs, generated inline — every phase writes documentation as it works, so the record is a by-product of the work rather than a chore after it
• Codified best practices — patterns that worked become named, reusable, self-evolving libraries: each run that touches one can improve it

The read path is what stops hallucination: the planning agent doesn't guess the service topology — it queries it. The write path is what makes the layer live: monitoring outcomes, review feedback, and shipped changes flow back in, so the next run starts from a truer picture than this one did.

In the wild

This is the "context lake" pitch behind agentic SDLC platforms like Port — service catalog, scorecards, and workflow context in one queryable layer, so every agent in the pipeline pulls the same tier, team, and standards for a service instead of inferring them. In-house, the same role is played by a well-maintained Backstage catalog plus repo-level agent rules — anywhere the answer to "what is true about our system?" lives in one place agents can read.

The version of this problem you already have

That is the layer described as a platform feature. There is a smaller, sharper version of it that every team hits on day one, and working through it shows what the layer is actually for.

Point an agent at a large existing codebase and ask for one change. Anupam Mishra describes the result to a room that recognises it instantly: "AI goes in infinite loop changing almost everything, and you feel all you had to do was one change and you went to like 20 files."

The instinctive diagnosis is that the codebase does not fit in the window. It is the wrong diagnosis, and the talk is unusually direct about it — asked whether context windows should keep growing, the speakers say more is not better, and that they trim and clear context deliberately rather than filling it. An agent editing twenty files is not short of room. It is confused about where the change lives, which is a different failure with a different fix.

Build the index before the change

So the first thing AI-DLC does against an existing repository is not retrieval and not planning. It is reverse engineering: read the codebase once, and write down what it means.

Reverse engineering — stage one

Built before the first edit · read on every edit after

1. 01Application structure

   How the codebase is arranged, and which region of it owns what.

   Saves it from

   Walking the tree and guessing from directory names.

2. 02Data flow

   How a request moves through the system, in order.

   Saves it from

   Reconstructing the path by reading each hop's source.

3. 03Existing APIs

   What the system already exposes — so a new method is added beside its siblings rather than invented.

   Saves it from

   Grepping for route decorators and hoping the pattern is uniform.

4. 04Business context

   What the system is for, and who is involved in it working.

   Saves it from

   Inferring intent from identifier names.

5. 05Tech stack

   What it is actually built on. In the demonstration: that FastAPI implements its web server on Starlette — which is why the change lands as inheritance rather than as a parallel implementation.

   Saves it from

   Writing idiomatic code for the wrong framework.

6. 06Component library

   Which components exist, what functions they implement, and how they call each other.

   Saves it from

   The call graph the agent would otherwise rebuild per question.

The tradeThousands of lines of source are read once and reduced to six pages the agent can hold at all times. The index is not the answer to any question — it is how the agent decides which source to open, which is the decision it was previously making with grep.

Mishra's framing of what has happened: "you have now looked at hundreds, thousands of lines of code, and from there you have reduced it into a semantic rich context." The agent's subsequent question — which files does this change touch? — is now answered by reading six pages instead of by grepping for a word and hoping the word is a good proxy.

That is semantic memory over a codebase: facts about the system, derived once, retrieved on demand. Its cost profile is the point. The expensive read happens a single time; every change after it is cheap. A team doing this per-question instead — re-deriving the map inside each run, out of the window, and throwing it away — is paying the setup cost forever and keeping none of it.

The worked example, end to end

The session runs it against a real issue: FastAPI has no support for the HTTP QUERY method, and someone has asked for it. The repository is public, the issue is public, and the tool is an off-the-shelf agentic coding tool configured with the AI-DLC rules.

1. It notices the workspace is not empty, and switches into the brownfield path on its own.
2. It reverse-engineers, producing the six artefacts above — including that FastAPI implements its web server on Starlette.
3. It clarifies the requirement rather than assuming it. HTTP QUERY is a specification; which one? The agent asks, and is handed the URL of the standard. Nothing is inferred about what "support the method" means.
4. It plans the workflow — deciding which later stages this change needs, and skipping functional design, user stories, and non-functional requirements with a stated reason for each.
5. It plans the code, naming every file it intends to change, and stops for a yes.
6. It writes the change — as an inheritance from Starlette, following the framework already in the tree, rather than as a parallel implementation beside it.
7. It tests, and reports ready.

The result was a pull request in hours. But the interesting part is step 6, and it is a direct consequence of step 2: the agent used Starlette because the index told it that Starlette was there. Take the index away and that is exactly the kind of decision an agent makes wrong — plausibly, idiomatically, and in a way a reviewer skimming a green diff will not question.

Semantics per token

Underneath all of this is a measure Raja SP names, which is the most useful idea in the talk for anyone building a context layer: semantics per token.

The same instruction, twice

"Refactor using builder pattern." — four words. Refactor is dense; builder pattern is dense. Almost every token is carrying meaning.

"Build me a utility to create a complex object by calling many setters, each returning that object, and finally build me a complex object." — many more tokens, describing the same thing, and the semantic content per token has collapsed.

Both fit in any modern window. They do not perform the same, and the difference is not length — it is density. Which reframes the brownfield problem one more time: a large codebase is hard for an agent not because it is large, but because boilerplate has a terrible semantics-per-token ratio. Most of what an agent reads in a repository is ceremony. The index works because it is the same system at a far higher density: no ceremony, only meaning.

It also gives you a design rule with a sharp edge. Every artefact you put in a context layer should be judged on meaning per token, not on completeness. A catalog entry that restates a service's config file is tokens spent to say nothing.

The tax nobody budgets for

There is a specific and unglamorous way teams lose this budget, and it is worth naming because it is invisible until measured.

Every tool an agent can call ships its description into the request, on every turn. Raja SP describes Amazon's internal situation — "a flurry of MCP tools," a single server sometimes exposing a hundred of them — and puts the cost at 60 to 70% of the context consumed by tool descriptions before the agent has read anything about the actual problem. His interim remedy is manual: turn off the MCP servers this task does not need.

Point at it rather than describe it

One practical corollary runs through the whole talk. Where something already exists in the system, the highest-density thing you can hand an agent is a pointer to it, not a description of it.

Asked to build a new service, "here is an existing service, use it as the reference" reliably carries the authentication approach, the logging, and the error handling across — because attention is a pattern mechanism and the pattern is right there. The alternative — enumerating the same conventions in prose — is more tokens, less precision, and a fresh chance to omit one. The same move appears in the FastAPI run twice: pointing at the standard rather than paraphrasing it, and pointing at Starlette rather than describing a web server.

Where this stops being a context problem

For balance, the talk supplies one failure that a context layer genuinely cannot fix, and it is worth keeping on the sheet precisely because this site spends most of its time arguing the other way.

They tried domain-driven design in Go. It did not work — the model produced code a Go developer would call wrong. The reason is not the prompt, the index, or the window: DDD is thoroughly represented in Java and thinly represented in Go, so the pattern the model would need to imitate largely does not exist in the material it learned from. No amount of retrieval conjures a convention a language community never adopted.

What the index cannot reach

Everything on this sheet is about making the agents agree — one picture of the system, written back to when it changes, read by every station on the floor. That is a real fix for parallel hallucination, and it is not a fix for anything underneath it.

Because the shared picture describes the code. It is not the code. An index can say which team owns the billing service and which standard it was built against, and still hand an agent a service nobody — human or model — can safely change. At that point the catalog is accurate and the work still fails, which means the layer that ran out of road is one link further down.