Context Is A Projection

Harness Series Article 6: On Context Management

In the world of coding agents, reliving yesterday means mapping what mattered yesterday onto today.

A transcript records what happened. Context decides what matters now.

Every coding agent eventually runs into the same problem: sessions get longer and longer.

The model has read files, run commands, searched logs, edited code, received validation output, and answered old questions.

How do you manage all this context?

The Naive Append Loop

The most intuitive approach is simple: append the transcript. But this is actually context flooding.

At first, the model seems smarter because it can see more.

But problems quickly arise:

• Old tool output competes with current evidence
• Huge shell logs drown out the next instruction
• Retry messages, partial reads, old plans, stale summaries—all crammed into one ever-growing blob

The Multi-Turn Loop

A slightly more mature approach than the naive append loop is a 5-phase loop, covered at the end of this article.

The Core Split

A mature Harness separates three things:

• Durable log should be complete and concise. It serves resume, audit, evals, and debugging.
• Model-visible context should be selective—it’s the view the model needs to see for its next action.
• App state should be structured. It must not rely on whether old transcript text is still in the prompt.

This leads us to define projection:

Projection means to turn the full history into the small, relevant view the model needs for the next step.

Which aligns with the title:

Context Is A Projection

Projection Happens Before The Model Call

Context management should happen before the model call.

Harness projection pipeline:

• Start with the full session log (source of truth)
• Then evaluate context pressure: how much context space is needed for the next turn, tool use, and evidence
• Keep the most recent turns verbatim (usually where the current task lives)
• Large outputs become previews; the full content stays outside the prompt
• Completed old segments get an explicit summary
• Inject current app state: changed files, validation, goal, tasks, and fresh evidence

Four Projection Moves

Each move addresses a different context management problem.

Large-Result Preview

Some tool results are too large to fit into context verbatim on every turn.

Examples:

• Test logs, grep output
• Generated files, web fetches
• Dependency trees

A weak Harness truncates randomly. A stronger Harness places the full result elsewhere and puts a stable preview in the model-visible context.

The model gets enough evidence to continue working.

The Harness retains enough metadata to resume, inspect, or reload the full result.

Idle-Gap Microcompact

Some context becomes less important because time has passed.

For example, the user comes back after lunch, or the session sat idle overnight.

The latest goal is still important. The most recent edits are still important.

Repeated reads and command output from long ago may not be important.

A microcompact is a small action:

Old-Span Collapse

Sometimes a whole segment of messages has finished its purpose. The Harness can collapse that segment into a summary. But the summary should be explicit:

The model knows a collapse happened. The user can inspect what was kept.

Resume can rebuild the conversation around the compact boundary without treating the summary as a random new user message.

Auto-Compact Near The Limit

When context pressure is high, the Harness should compact before the model call fails.

A good implementation doesn’t just say “if too long, summarize”.

It needs:

• Warning thresholds: tell the user what percentage of context remains
• Hard blocking thresholds: block the model call before the limit is exceeded; require compact before continuing
• Recursion guards: prevent compact from triggering another compact
• Restored attachments or state blocks: after compact, re-add attachments, file state, validation, goal, and tasks

Auto-compact protects the next turn while retaining the evidence needed to continue working.

The Multi-Turn Loop

Context management is especially important in a multi-turn loop.

A multi-turn loop roughly follows 5 phases:

In the loop, The next turn starts from the committed runtime state.

Phase 2 (context projection) is responsible for generating the model-visible view.

Phase 5 commits changes so the next turn starts from a real runtime state.

Starting from the model call, the world state of the coding agent changes, divided into yesterday and today.

The model doesn’t need the entire past. It needs the correct past, current state, and enough evidence to support the next step.

Harness Context management is about managing and deciding the selected view that the model sees on each call.