Reclaiming the Context Window: The End of Context Clearing by Proxy

If your AI harness has to spawn a brand-new sub-agent just to read a database schema, your memory architecture is broken.

The sub-agent boom of the last eighteen months has been sold as a story about specialization. A “research” agent. A “code review” agent. A “test runner” agent. Each one neatly scoped, each one calling the next. The diagrams look like microservices. The pitch decks promise composability.

The reality is less flattering. The dominant reason teams reach for sub-agents today is not that they need a different model, a different prompt, or a different toolset. It is that the parent session is choking on its own history, and the cheapest way to get a clean slate is to launch a fresh process that has never seen any of it.

We have a name for this pattern: context clearing by proxy.

The trick everyone is running

Watch a long coding session in any popular harness and the move is the same.

The parent agent has accumulated forty turns of tool output: stale file reads, abandoned plans, retry loops from a flaky integration test, three different attempts at the same regex. The window is two-thirds full and getting heavier with every step. The model starts to drift — pulling in irrelevant files, repeating work it already finished, forgetting decisions it made fifteen turns ago.

So the harness spawns a sub-agent. “Go read the user service and report back.” The sub-agent runs in a fresh context, performs the lookup, returns a tidy summary, and exits. The parent absorbs the summary and continues, lighter by a few thousand tokens.

It works. That is the problem.

It works just well enough that nobody asks the obvious question: why did we need a separate process to do that? The parent had every tool the sub-agent had. The parent had every permission. The only thing the parent did not have was the discipline — or the architecture — to keep its own context clean.

Sub-agents are not a memory system

Sub-agents are a fine primitive. They are useful when you actually want a different model, a different system prompt, a different permission boundary, or genuine parallelism. They are a terrible substitute for context management.

When you delegate “go read X and tell me what you found” to a sub-agent purely to keep the parent’s window from collapsing, you are paying for three things you did not need:

1. A second model invocation to summarize information the parent could have read directly.
2. A lossy compression step, because the sub-agent’s summary is necessarily an opinion, not the source.
3. The illusion that your harness is doing memory management, when it is actually just doing context laundering.

The third cost is the worst one. It hides the real problem. Teams stop asking “how do we keep this session coherent at turn 80?” because the architectural answer has become “spawn another sub-agent.” You end up with a coordinator that does nothing but dispatch — a foreman who has no idea what is being built because the only memories that survive are the ones the workers chose to write down.

What “active context management” looks like instead

A harness that manages context actively does not need to wipe the board to write a regex. It treats the conversation as a structured, mutable artifact, not an append-only log that you eventually have to amputate.

Concretely, that means:

• Tool outputs are not history. A file read at turn 12 should not still be sitting in the window at turn 47 in the exact shape it arrived. It should be summarized, indexed, or evicted based on whether the model still needs it — without losing the fact that it happened.
• Decisions outrank evidence. “We decided to use a single transaction here because the rollback semantics matter” is the kind of thing that has to survive. The forty lines of file content that led to the decision usually do not.
• The window is curated, not consumed. Every turn, the harness re-shapes what the model sees so that the next response has the architectural awareness of the whole session and the working-memory footprint of a fresh one.

The goal is not to keep the context small for its own sake. The goal is to keep the signal-to-noise ratio high — across forty turns, eighty turns, two hundred turns. When that ratio stays high, sub-agents become a tool you reach for when you genuinely need a different worker, not when you need to escape your own history.

The “context clearing by proxy” tell

If you want to know whether your harness has this problem, look at why your sub-agents get spawned.

If the answer is “to run a different model on a different task with different permissions,” you are using them correctly.

If the answer is “because the parent’s context was getting too long,” you are not delegating. You are evacuating.

Evacuation is fine as a stopgap. It is a disaster as an architecture. Every sub-agent you spawn for context reasons is a vote of no confidence in your own memory system — and over a long enough session, those votes add up to a harness that cannot reason about its own work because no single process has seen the whole thing.

What we are building

This is the gap AJNT was built to close. ActiveContext sits between your agent and the model and actively manages the session — compressing what can be compressed, evicting what is no longer load-bearing, and preserving the architectural memory that keeps a long run coherent. Your agent stays focused. Sub-agents go back to being a real tool, not a coping mechanism.

You should not have to wipe the board to write a regex.

You should not have to spawn a stranger to remember what you already knew.

Reclaim the window.