Source: MongoDB — 2026-08-18
Summary
MongoDB's latest harness-architecture post argues that "memory" is often conflated with "state," and that conflation causes teams to bolt memory onto agents as an external service instead of designing it as a first-class layer of the harness itself. It draws a hard line between agent-side working memory — the context assembled fresh for a single run — and harness-side persistent memory, which has to survive across sessions, get written back selectively, and be retrievable without re-processing everything that ever happened.
Key Takeaways
- State is run-bounded: it's the working data of one execution and disappears when the run ends. Memory is meant to outlive the run and be read back in future sessions — treating them as the same thing is what leads teams to lose context between sessions or bloat every new run with irrelevant history.
- Context compaction — deciding what to keep when the context window fills up — is lossy by construction: every compaction step discards information, so what you choose to keep back is a design decision, not an implementation detail to defer.
- The piece positions persistent memory as needing its own retrieval path (e.g., vector search over episodic/entity stores) distinct from the working context an agent assembles per turn, rather than one undifferentiated blob of "everything the agent has ever seen."
- It's explicitly framed as one part of a series — the next installment covers observability: seeing what an agent retrieved, what it did with it, and why, once the system is live in production.
Reel Script
Hook (17s, ~38 words): If your AI agent forgets everything the moment the conversation ends, it's not a memory problem — it's an architecture problem. MongoDB just published a piece arguing most teams are building agent memory in exactly the wrong place.
Core Concept (70s, ~160 words): The core distinction is state versus memory, and it's easy to blur them. State is what an agent needs during one run — the scratch pad it fills up while solving the task in front of it right now. When the run ends, that scratch pad is supposed to go away. Memory is different: it's what should survive across runs — what the agent learned about you, your codebase, or your preferences last week that it should still know today. The mistake MongoDB calls out is treating memory like it's just leftover state — bolting a database onto the side of the agent and dumping everything into it, instead of designing memory as part of the harness — the surrounding system that actually runs the agent loop — from day one. Get that distinction wrong, and you either get an agent with amnesia between sessions, or one that's drowning every new run in irrelevant history.
Hands-On (55s, ~130 words): The piece zeroes in on one specific mechanism: context compaction. Every agent eventually fills its context window and has to decide what to throw away to make room for new information. MongoDB's point is that this is lossy by construction — every single compaction step permanently discards something. So the question isn't "how do we compact," it's "what do we protect from compaction," and that has to be a deliberate design choice tied to a real persistent-memory layer with its own retrieval path — think vector search over distinct stores for episodic history, entities, and long-term preferences — not a single undifferentiated log getting trimmed from the bottom.
Takeaway (25s, ~55 words): If you're building a production agent and memory feels like an afterthought you'll wire in later, this is your sign to stop — treat what to remember and what to forget as a first-class design decision now, before your context-compaction logic quietly deletes the one fact your agent actually needed to keep.