Two loops, one brain

Enterprise agent sprawl is not a coordination problem. It is a classification problem — and it begins with treating memory and knowledge as the same asset.

Pradeep / Agent Adda / Recursive Insight / 9 min

Knowledge is shared, owned by no loop. Memory is local, owned by one loop.

Diagram: a stateless outer loop reaches a shared knowledge base; a stateful inner loop runs a nine-stage pipeline and holds local PostgreSQL memory.

Two loops share knowledge via a KB — not state via a context blob.

The problem

Stated precisely

Every organization running more than one AI agent hits the same failure mode within weeks. The coding assistant re-derives context the runtime agent already has. The runtime agent has no visibility into what the coding assistant just changed. Each one re-reads source files, re-guesses command syntax, re-solves problems the other loop solved an hour earlier.

The cost lands twice: tokens burned on redundant grounding, and drift between agents meant to be working on the same system.

The standard remedy — wire every agent into every other agent's context, keep the fleet in sync — is the wrong remedy. It fails for a structural reason worth naming.

Memory is the record of a specific, unfolding interaction — what this user asked three turns ago, which workflow is mid-flight, which report is open. Knowledge is the set of durable facts about how a system works — commands, schemas, ordering rules, prior architecture decisions.

Memory belongs to one loop. Knowledge belongs to none of them, and should be built that way.

The test case

Two loops that share almost nothing

Agent Adda runs two agentic loops against a single codebase. The outer loop is a stateless orchestrator that starts cold every session and handles development and operational work. The inner loop is a REPL agent (nse_agent.py) — stateful by design, running a nine-stage short-circuit pipeline, carrying a five-turn context window and writing each turn to PostgreSQL.

These loops have almost nothing in common structurally, and that is the point. Unifying them through shared memory would mean forcing a disposable orchestrator to carry state it does not need, or forcing a stateful REPL into synchronization with a process that does not persist between sessions.

What they share instead is narrower and more durable: a knowledge layer that neither one owns.

What it buys

What each loop stops carrying

The outer loop stays disposable. Every task opens with a knowledge base query instead of a cold read of source. Grounding is retrieved, not accumulated. Kill the session, restart it, lose nothing.
The inner loop stays lean. PostgreSQL memory carries only conversational state (active symbols, open reports, options awaiting a reply). It does not duplicate the skill catalogue or command reference.
Both loops get auditability: lookup latency + estimated token savings are natural to log when there is one gateway.

The counterfactual

What the alternative costs

Remove the shared layer and every outer-loop task needs one of two things: full source re-reading on each invocation (slow and expensive), or a persistent memory of how the system works maintained by humans (which rots the moment code changes).

A knowledge base avoids both. It rebuilds whenever skill cards change, so it cannot drift out of sync the way a hand-maintained memory inevitably does.

The rule

For architects building multi-agent systems

Identify what the agent is actually missing before you give it memory. If the gap is knowledge, route it through a shared, indexed layer. If the gap is continuity, that is memory, and it stays local.
Synchronize through a shared lookup, not a widened context window. Context synchronization scales with agent count multiplied by what each one tracks. A knowledge layer scales once.
Instrument the lookup, not just the answer. Token accounting at the gateway turns “we believe this is more efficient” into a number — provided you are honest that it is an estimate.
A stateless orchestrator and a stateful worker can coexist without either compromising its nature — provided what they share is knowledge, not state.

The evidence

What was checked, and what was not

The structure described here was checked against source on 25 August 2026 — file by file, not from memory. Most of it held. Some of it did not, and the corrections are more instructive than the confirmations.

The limit

Where the claim stops

This is not a universal solvent. Some coordination genuinely requires shared state. Two agents working the same in-flight investigation need to see each other’s completed steps, not just static facts about the system — which is why in-flight workflow state sits deliberately outside the knowledge base.

The discipline is not “never share memory.” It is classifying each piece of information correctly before deciding where it lives.