Orchestrators need projections, not one giant memory

The mistake is loading everything because everything might matter.

That feels safe right up until the review agent reads the implementation plan and starts validating intent instead of behavior. Suddenly the system is grading the task against the spec the author wrote, rather than against the diff the agent shipped. More context is not always better context. Sometimes the wrong context is worse than no context.

The earlier posts in this series broke memory into layers by what it stores — canon, recall, relationships, traces. This one is the orthogonal axis: who reads what. The same underlying store can, and should, show different faces to different agents depending on the phase of work they're doing.

Loading everything is a context smell

The review-agent example is the cleanest version of this. You have a coding agent that ships a PR. You have a review agent whose job is to check the diff against the actual behavior of the code. You hand the review agent everything: the spec, the implementation plan, the tool traces, the discussion thread, the diff.

The review agent now has a problem. It has the author's stated intent right there in the context window. The cheapest way to "review" is to check whether the diff matches the intent. That's not a review; that's intent-validation cosplaying as verification. The review agent should have been given the diff, the tests, and the spec — not the plan, not the prior agent's "I think this approach will work" notes. The omission is the feature.

This is what I keep calling context as the constraint. The harness is a router first, a container second. Storage was never the hard part — picking which slice of the storage to load into which agent at which moment is the hard part.

Explore wants memory

The explore phase is where a coding task starts: messy inputs in, executable spec out. This phase wants memory the most, and it wants the broadest projection.

What it needs:

• prior architecture decisions for this repo (so we don't redesign every quarter)
• known stakeholder preferences (so the spec respects them without re-asking)
• past failed implementation routes (so we don't propose the dead end again)
• canonical project docs (so the spec is grounded in current truth)
• recent related PRs (so we know what changed)

Without this projection, every spec starts from zero. The agent re-derives constraints somebody already paid to learn. The output looks reasonable in isolation and immediately collides with last quarter's decisions in review.

Belayer's explore phase is built around this projection specifically — it's the phase where loading more is usually better. The failure mode is amnesia.

Climb wants depth

The climb phase is implementation. Spec in, diff out. This phase wants deep memory, but narrow.

What it needs:

• the spec itself
• the architecture context for the specific area being changed
• nearby code (the files the diff will touch, plus a one-hop radius)
• test patterns the repo uses
• current branch state and recent commits

What it doesn't need: half the org's design docs, every prior failed approach to unrelated problems, the stakeholder preference matrix. The breadth from explore becomes noise here. The model needs to go deep on the local problem; pulling in everything turns into a context-window tax and a distraction surface.

Climb is also where the black-box recorder trace store earns its keep. The agent should be able to ask "did anyone hit this test before, and what did they do?" without loading every trace from every prior run.

The failure mode here is shallow implementation — too little local context, the agent ships a patch that compiles, doesn't fit the surrounding patterns, and gets bounced in review. Or the opposite: too much breadth, the agent loses track of the small thing it was supposed to do.

Summit wants freshness

The summit phase is review and release. Diff in, verdict out. This is the phase where less memory is usually better.

What summit needs:

• the diff
• the tests (and their results)
• the CI signal
• recent risk history for the touched files
• deployment state

What summit should not have, by default: the implementation plan the climb agent wrote, the explore phase's "I think we should..." notes, the author's stated intent. Those bias the review toward validating the author's story rather than checking the actual change.

This is the projection that's hardest to design because the temptation to "give the reviewer all the context" is strong and feels responsible. But if the reviewer has the plan, the reviewer reviews against the plan, not against reality. If the reviewer has the diff and the test evidence, the reviewer reviews against what shipped.

Summit still needs memory, though. Zero memory is the other failure mode. Summit needs evidence memory: history of this file failing in production, recent regressions, deployment risk for this directory, prior security findings. Just not author-intent memory.

The failure mode here is confirmation bias dressed up as review.

Assistant/orchestrator memory is different from coding-agent memory

The orchestrator itself is another consumer of memory, and it wants yet another projection:

• task status and ownership (who's on what)
• priorities and SLAs (what's blocking what)
• trust and risk calls (which agent gets autonomy on which class of work)
• routing decisions (which subagent gets this task, why)

Almost none of this is what the coding agent or review agent wants to load. The orchestrator needs the meta-layer. The agents underneath it need the task layer. Same memory store. Different projections.

This connects back to relationship memory — the orchestrator needs just enough relationship state to route well, and not enough to contaminate the verification path.

Self-managed memory tools are tempting here. Let the model call search_memory, save_memory, update_profile, and request_more_context in a heartbeat loop, and suddenly the projection can adapt mid-task instead of being frozen before the answer starts. That's useful. It is also how an agent quietly writes its own reality if the tool permissions are lazy.

The policy I want is boring:

The agent may request more context. It does not get unilateral authority to update canon. That one sentence saves a lot of systems from becoming a self-licking ice cream cone.

Caveats

A few honest qualifiers:

• Not against shared storage. The underlying store can absolutely be one system. The projections are the contract; the storage is implementation.
• Not a claim that composability has already won. Integrated systems like Claude Code, Letta, or Slate may ship better experiences today because they own the whole pipeline. This stack is leaning composable because the projections feel cleaner when they're explicit — not because the integrated approach is wrong.
• Summit needs the right memory, not none. Evidence, history, risk. The point is the omission of author intent, not the omission of context.
• Projections aren't easy. Storage is solved enough; projection is where I keep paying the bills.

Outcomes

• More context is not always better context. The harness's first job is picking what not to load.
• Explore wants breadth, climb wants depth, summit wants freshness. The projection is the contract.
• Orchestration memory is a projection problem before it is a database problem. The store can be unified; the views have to be intentional.
• The next post is about the write path — the inverse problem of picking which agent gets to update canon based on what it learned.