Agent with tiered working memory and cross-session learning — architecture, gaps, and what the research didn't cover
▲ 7 r/ContextEngineering+3 crossposts

Agent with tiered working memory and cross-session learning — architecture, gaps, and what the research didn't cover

I've been building PRAANA — a coding agent with two systems I couldn't find combined in one self-contained binary: an Adaptive Context Engine (within-session) and Cognitive Memory (cross-session). Posting because the architectural decisions may be useful independent of the coding use case.

The core problem:

Every agent session is a context window management problem. Append-until-full plus reactive compaction is lossy — by the time you compact, you've already paid the drift cost, and you've lost track of which information was load-bearing.

PRAANA's ACE curates on every turn. A deterministic compiler assembles the prompt in 5 sections:

1. System Frame       — identity + tools
2. Memory Digest      — ranked cross-session learnings
3. Active State       — current work objects, full resolution
4. Peripheral Stubs   — everything inactive, one-line anchors
5. Recent Turns       — last N turns, budget-capped

State objects demote Active → Soft → Hard based on idle turns. Two-pass auto-hydration before each turn: substring keyword match, then BM25 for fuzzy overlap. Scores are density-weighted: decisions score 1.0, narrative scores 0.6, errors score 0.8. The compiler knows what kind of information is filling up, not just token count.

Cognitive Memory:

At /exit, a summariser extracts structured learnings from the transcript. Six kinds: fact, preference, decision, pattern, mistake, constraint — domain-agnostic; coding-specific knowledge lives in content, not schema. Stored in SQLite with sqlite-vec + Transformers.js (in-process, 384-dim). Confidence decays 5%/day. Entries confirmed across two or more sessions promote to Consolidated Memory (10x slower decay). Ranked recall: cosine × confidence × recency × pin_boost.

Where the research fell short:

I surveyed 20+ agent-memory repos. What I found:

Mem0, LangChain, and most memory backends are retrieval systems. They store and recall but have no outcome-based feedback loops. No architecture for "this memory was used and confirmed, increase confidence" vs "this memory was contradicted, reduce it." Letta has the most interesting consolidation work (sleep-time agents) but it's a platform, not extractable, and consolidation is partial.

Nobody combined proactive context curation with learning memory in one self-contained process. The compression tools — Headroom, ACON — are SDK/proxy layers that sit between you and the LLM. They don't own agent state.

The gap I missed: the research covered storage architecture, not learning signal. The reinforcement path in PRAANA — boost confidence when a session succeeds, decay when contradicted — is wired but the session-success signal hasn't shipped yet (#162). I designed a complete feedback loop and then discovered the trigger was the hard part.

The larger plan:

Four systems — Adaptive Context, Cognitive Memory, Background Consolidation, Intelligent Router — all domain-agnostic. No system encodes anything about code. The coding agent is the proving ground; coding outcomes are measurable. Once Phase 1 validates the architecture, Phase 2 extracts the runtime as @praana/runtime. I'm not extracting it until the coding agent proves it works.

Gaps:

Reinforcement path dormant (#162). No A/B eval harness — scorecard ships, headless task runner is next, no published benchmark claims. Background Consolidation Processor schema exists, not scalable yet. Runtime extraction is Phase 2, not started.

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

If you're working on agent memory or context management architecturally, I'd welcome the comparison. What are you seeing in production that the research repos didn't surface?

u/Reasonable_Craft_425 — 9 hours ago

I’ve been thinking about this for a while, and I feel like most of us might be optimizing the wrong thing.

A lot of effort in the LLM space goes into:

  • fine-tuning
  • reinforcement learning
  • better prompting

But all of these assume the same idea:
the model itself needs to get better.

What if that’s not the right place to focus?

Alternative idea

Instead of making the LLM “smarter,” treat it as just a generator and build a system around it that actually improves over time.

Something like:

  • LLM → proposes outputs
  • Evaluator → scores them
  • Decision layer → accepts/rejects/refines
  • Memory → stores what worked vs failed

Loop:

  1. Generate
  2. Evaluate
  3. Decide
  4. Store outcome
  5. Repeat

So instead of:

>

You get:

>

No retraining required.

Why this might matter

  • avoids expensive retraining loops
  • adapts in real time
  • improves behavior through experience
  • reduces repeated mistakes

Feels closer to a “decision system” than a “thinking model.”

What I don’t see discussed enough

A lot of current work (prompting, agents, reflection, etc.) improves reasoning…

…but doesn’t really build a persistent decision policy from past outcomes.

Everything resets too easily.

Question

  • Is this already a well-explored idea under a different name?
  • What breaks if you try to scale this?
  • Would this outperform fine-tuning in practical systems, or just complement it?

Curious where I’m wrong here.

reddit.com
u/Reasonable_Craft_425 — 2 months ago