Why I built a proactive context curator instead of a compactor — and what I got wrong for three months [P]

Two ways to handle a context window that's filling up.

Reactive: wait until it's full, then compact everything. Proactive: be picky about what gets added every turn so noise never piles up in the first place.

Most coding agents take the reactive path. I spent months building the proactive one, and I want to be honest about what actually worked and what didn't.

What held up

A decision your agent made on turn 3 is worth more tokens than tool output from turn 15 that's already resolved. Treat them the same and you get context rot. PRAANA's compiler splits working memory into active, soft, and hard tiers. It scores context units by information density, then uses BM25 plus semantic similarity (Transformers.js, running in-process) to decide what gets pulled back into the active window.

What I got wrong — semantic recall was quietly broken for weeks

I threw together a hash-based embedder early on as a placeholder. The problem was it was injecting noise into recall ranking. Memories came back in the wrong order, irrelevant items floated above relevant ones. The worst part: it looked plausible. No errors, just wrong answers. Took three weeks to even notice. I fixed it by switching to Transformers.js with keyword-only full-text search as the fallback. New rule: if there's no real semantic embedder available, you get keyword-only recall. No fake vectors, ever.

The measurement gap

For most of the project, I couldn't actually prove the context engine beat a plain transcript agent. "Feels better" doesn't count as evidence. A telemetry scorecard landed a few weeks ago — session-level signals like context pressure, memory recall percentage, skill load and decay, per-section token accounting. The A/B evaluation harness is next. Lesson learned: build the measurement before you build the thing you're trying to measure.

The honesty problem in agent marketing

PRAANA's memory stores and recalls with time decay. The reinforcement path — boosting confidence when a session succeeds — is wired up, but the signal that actually triggers it hasn't shipped yet. So I call it "stores and recalls" until that loop closes and I can show it working. A user who sees memory surface a stale belief at high confidence loses trust in the whole system. Publishing your limits before your benchmarks isn't just an ethics call — it's a product decision.

The larger plan

Four systems: Adaptive Context, Cognitive Memory, Background Consolidation, Intelligent Router. All domain-agnostic. Nothing in the system knows anything about code specifically. The coding agent is just the proving ground because outcomes are easy to measure: did the code work, how many turns did it take, did it avoid repeating the same mistake from last session. Phase 2 is extracting the runtime so other developers can build domain agents on top of it. I'm not touching that extraction until Phase 1 validates the architecture. That discipline has been the hardest part of the whole project.

GitHub: amitkumardubey/praana — MIT, TypeScript, Bun.

Version 2: Conversational, slightly rougher edges

Two ways to deal with a context window that's getting full.

Reactive: let it fill up, then compact. Proactive: curate what goes in every turn so noise never builds up.

Most coding agents go reactive. I spent months on the proactive approach, and here's what actually held up versus what fell apart.

What actually worked

An agent decision from turn 3 is worth more than resolved tool output from turn 15. Treat them equally and you get context rot. PRAANA's compiler tiers working memory into active, soft, and hard layers. It scores context units by information density, then uses BM25 plus semantic similarity (Transformers.js, in-process) to decide what gets promoted back into the active window.

What broke — and stayed broken for weeks

I built a hash-based embedder early as a placeholder. It was silently injecting noise into recall ranking. Memories came back out of order, irrelevant stuff surfaced above relevant stuff. The failure mode was plausible-looking wrong answers, not obvious errors. Three weeks before I caught it. Switched to Transformers.js with keyword-only FTS as the fallback. The rule now: no real semantic embedder means keyword-only recall. Never fake vectors.

Where I was flying blind

For most of the project I couldn't prove the context engine beat a plain transcript agent. "Feels better" isn't evidence. A telemetry scorecard merged a few weeks back — context pressure, memory recall percentage, skill load and decay, per-section token accounting. A/B eval harness is next. The lesson: build your measurement before you build the thing you're measuring.

The marketing honesty thing

PRAANA's memory stores and recalls with time decay. The reinforcement loop — boosting confidence on session success — is wired but the trigger signal hasn't shipped yet. So I say "stores and recalls" until I can actually show the loop working. A user seeing memory surface a stale belief at high confidence loses trust in everything. Publishing your limits before your benchmarks is a product call, not just an ethics one.

Where this is going

Four systems — Adaptive Context, Cognitive Memory, Background Consolidation, Intelligent Router. All domain-agnostic. Zero code-specific assumptions baked in. The coding agent is just the testbed because results are measurable: did it work, how many turns, did it avoid repeating last session's mistake. Phase 2 is extracting the runtime for other developers to build domain agents on. Not happening until Phase 1 validates the architecture. That restraint has been the hardest part.

GitHub: amitkumardubey/praana — MIT, TypeScript, Bun.