Stop Waiting Until It’s Full to Compress: Hands-on Review of the Active Context Curator

A Counterintuitive Choice: Don’t Fill the Window, Be Selective Every Round

A long post on Reddit’s r/MachineLearning has sparked quite a bit of discussion lately. The author shared the lessons learned over three months of building a context manager called PRAANA, making one central point: mainstream coding agents are waiting for the context to fill up before compressing it—and that’s the wrong path.

His approach flips the process—don’t be a reactive compactor, be a proactive curator. Each new piece of content generated in conversation gets screened before entering the context window; anything that doesn’t pass the filter never gets in to pollute the window. It sounds like common sense, but few teams actually do this. The big players like Manus, Anthropic, and Cognition, when talking about context engineering, mostly focus on “what to do after the window fills up.”

This contrast is fascinating. By 2026, Claude 4.5 and GPT-5 both have million-token context windows, so theoretically, context management should no longer be a concern. Yet the opposite is true—the conclusion from Chroma’s “Context Rot” report has been proven again and again: the longer the window, the more diffuse the attention, and the worse the reasoning degradation. Just because you can fit 128K tokens doesn’t mean all 128K are useful—often, the more you stuff in, the dumber it gets.

Reactive vs Proactive: The Fundamental Difference Between Two Paths

Let’s clarify the two paradigms.

Reactive Compactor (mainstream approach):

• The context window fills up normally—tool outputs, chains of thought, observations all thrown in together
• Once a threshold is hit (e.g. Claude Code’s 95%), compression is triggered
• Usually uses an LLM summarizer, or simply truncates early messages
• Typical examples: Claude Code’s auto-compact, LangChain’s ConversationSummaryMemory

Proactive Curator (the PRAANA approach):

• Every context unit is scored before entering working memory
• Hierarchical management: active tier (currently active), soft tier (retrievable), hard tier (archived)
• Relevant content is recalled from soft/hard tiers into active as needed
• The goal is to keep noise out entirely

Their philosophical difference lies in when information value is judged. The reactive approach assumes all tokens are born equal, and only decides what to cut when it must; the proactive view holds that information value should be assessed at the moment of creation. The author gives a great example: an agent’s critical decision in round 3 is far more valuable than a solved tool output in round 15, but reactive systems treat them the same, leading to eventual context rot.

That assessment rings true. The Manus team hinted at a similar idea in their well-known blog post—using a file system as the ultimate context is essentially an admission that “not everything deserves to stay in the window.” The difference is that Manus offloads passively, while PRAANA curates actively.

PRAANA’s Compiler: Three-Tier Memory + Hybrid Retrieval

On the technical side, PRAANA’s core is a component called the compiler, which does a few things:

1. Information density scoring: Each context unit (such as a tool call, reasoning step, or user input) is decomposed and scored along dimensions like novelty, decision relevance, and probability of later reference.
2. Three-tier hierarchical storage:
   • Active tier: immediately visible to the current reasoning process
   • Soft tier: short-term cache, retrievable by search
   • Hard tier: long-term archive, requires explicit request
3. Hybrid retrieval: dual-channel BM25 lexical matching + semantic similarity, running embeddings in-process via Transformers.js, with no external embedding service dependency

The choice to run embeddings in-process is clever. Most agent frameworks need an embedding API or a local service for RAG or memory retrieval, both of which add delay and deployment complexity. With Transformers.js embedded directly into the Node process, retrieval after cold start happens at memory speed—critical for high-frequency coding agent scenarios.

Three Months of Pitfalls: A Placeholder Embedder Wrecked the Entire Retrieval Pipeline

This is the most eye-opening part. The author frankly admits: the semantic retrieval system was quietly broken for weeks before he noticed.

Here’s what happened. Early in the project, just to get the pipeline running, he wrote a quick hash-based embedder as a placeholder—basically hashing text into vectors. We’ve all done this, the idea being “just get it running, swap in a real embedder later.”

And then he forgot.

The consequence? The BM25 path worked fine, but the semantic path kept injecting noise into the retrieval rankings. Since hash embeddings produce random vector distances, similarity scores were meaningless—but the code still applied weighted ranking as if nothing was wrong. Everything looked normal—there were retrievals, the agent responded, tasks completed—but results were oddly inconsistent.

How did he discover it? During an A/B test, turning off the semantic channel entirely actually improved performance. That prompted a deeper debug, revealing the root cause.

This story carries serious lessons for agent developers:

• Placeholders are high-risk technical debt zones, especially in multi-stage pipelines; silent failures in one stage are often invisible to end-to-end metrics.
• Hybrid retrieval weighting must support independent evaluation of channels—if you only measure final ranking quality, one broken channel might go unnoticed.
• Regression testing should cover retrieval quality itself, not just overall task success rates.

Compared with Mainstream Solutions: Where Does Proactive Actually Win?

To his credit, the author doesn’t overhype PRAANA as a silver bullet. He clearly notes the trade-offs:

Strengths:

• Long-chain coding agents (30+ tool calls)
• Scenarios requiring cross-session consistency
• Production deployments sensitive to cost and token efficiency

Weaknesses:

• Short conversations (under 10 turns), where curator overhead outweighs gains
• Exploratory tasks, where importance of information is unknown
• Strictly reproducible debugging sessions, since curation introduces uncertainty

The comparison with Manus is also interesting. Manus emphasizes several core principles: prioritizing KV-cache hit rate, masking rather than removing tools, using the file system as external memory, and preserving error traces. None of these actually conflict with proactive curation—you could, for example, make “KV-cache stability” a scoring factor in the curator, penalizing modifications that insert changes early in the prompt.

The real clash lies in Manus’s principle of “preserve errors.” Manus believes failed attempts should remain in context to let the model implicitly update its beliefs. But a proactive curator naturally tends to downscore and remove “resolved errors” from the active tier. The author doesn’t offer a clear resolution here, but a reasonable compromise might be: keep error information in the soft tier, retrievable when needed, not permanently active.

The Bigger Question: How Long Will We Still Need Context Engineering?

After reading this discussion, one can’t avoid the broader question—by 2026, with ever-growing context windows and cheaper KV-cache, do we still need to invest this much engineering in context management?

My view: in the short term, we have no choice; in the long term, part of it will fade away.

Short term: Chroma’s context rot conclusion still holds—the attention diffusion problem in long contexts is rooted in transformer architecture, not simply fixable by scaling up windows. As long as agent tool calls remain in the hundreds (Anthropic’s multi-agent experiments already show this scale), context engineering is still essential.

Long term: models will gradually internalize some context management ability. You can already see the trend in GPT-5 and Claude 4.5—they show early self-awareness of “outdated information” in long contexts and can selectively ignore it. But this internalization remains coarse-grained, far less precise than a dedicated curator.

Thus, the real value of systems like PRAANA, short term, is to compensate for model limitations; longer term, it’s to establish best-practice patterns for context management so that once models absorb these abilities, engineering complexity will naturally drop.

Some Practical Advice

If you’re building an agent system—whether reactive or proactive—here are some tips:

1. Build evaluation before optimization. Retrieval quality, token usage, task success rate, KV-cache hit rate—each should be measurable independently.
2. Mark and monitor placeholder code immediately. The pitfall the author fell into is one nearly every team will encounter.
3. Don’t ditch BM25. Semantic retrieval is trendy, but for code, commands, and exact term matching, BM25 remains the most stable baseline.
4. Don’t over-layer your memory tiers. Three is enough; five or seven tiers are usually over-engineering.
5. On preserving error traces—trust Manus. Unless there’s strong evidence errors actively pollute decisions, don’t rush to clean them out.

As a side note, if you’re comparing context management strategies across multiple models—say, testing the same curator on Claude, GPT, Gemini, and DeepSeek—OpenAI Hub’s one-key multi-model feature makes it easy. It supports the OpenAI-compatible format, so you only change the model parameter instead of adapting each SDK separately.

The engineering focus of the agent era is shifting—from “how to make models smarter” to “how to make models see the right things.” That shift will continue for quite some time.

References

• Why I built a proactive context curator instead of a compactor - Reddit r/MachineLearning — the full technical write-up from PRAANA’s author, including three months of trial and error details