Agent memory isn't one thing

Every week a new "agent memory" project ships. Hindsight, Hippo, Honcho, AgentMemory, GBrain — pick a launch. Most of them claim the same job. Spent a week putting five of them next to each other and the actual finding is that "memory" is being used as a label for five different jobs that don't share a contract. That ambiguity is the reason every comparison thread devolves into "well it depends what you need it for" — because nobody named the it.

Symptom — every memory tool sounds like every other memory tool

Pull up Hindsight, Hippo, Honcho, AgentMemory, and GBrain. Read the pitches back-to-back. They all say some version of: durable context, persists across sessions, learns over time, retrieval-aware. The mechanics differ — SQLite vs vector DB vs markdown vs hosted API — but the marketing surface is identical. So is the failure mode you hit when you try to use two of them at once: you end up with two canonical stores of "what's true," which is soup.

Cause — "memory" is doing five jobs at once

The actual jobs hiding under that one word:

1. Durable canonical knowledge. Things that are true about the world (this repo, this API, this person, this decision). Should be inspectable. Should survive any agent. Markdown + wiki is the right shape here. GBrain is the place this lives in my stack; for many people it's just Obsidian. Either way: this layer is human-curated, agent-readable.
2. Runtime adaptive recall. What the agent saw this week, last week, last quarter. Decays. Strengthens with retrieval. Consolidates during sleep cycles. This is what Hippo's "memory is also about forgetting" pitch describes. Lifecycle is the load-bearing word — without decay/reinforcement, this layer just becomes a slow database.
3. Relational / user / session state. Who this agent is talking to, what role they have, what they like. Honcho's territory. This layer is more volatile than world facts and more personal than runtime recall.
4. Reflective synthesis. Observations the agent has formed by looking at its own history. Mental models. Beliefs. Hindsight separates these from world facts and from raw experience for a reason — they decay differently, they need different provenance, they can contradict each other.
5. Coding-agent continuity. What this agent learned about this codebase over many runs. AgentMemory and similar tools fill this slot. Heavy overlap with (1) and (2); the differentiator is the MCP/REST surface and the auto-capture-from-tool-calls behavior.

When a tool says "agent memory," it's claiming territory in some subset of those five. Most claim more than they should. Some genuinely span multiple — Hindsight's strongest move is naming the epistemic split between world facts, experiences, and synthesised observations explicitly. But none of the existing tools cleanly covers all five, and the ones that try collapse into the soup problem: two stores claiming to be canonical, both partially right.

Another axis gets mixed into the same soup: mechanism. Sliding windows, summaries, vector indexes, graphs, and self-managed memory tools are not jobs. They're ways to do jobs. Confusing those two categories is how a vendor demo turns into an architecture diagram with five boxes all labelled "memory" and no answer to the only question that matters: who is allowed to treat this as true?

The mechanism ladder looks roughly like this:

That ladder is useful for teaching because each step fixes the previous failure. It is not a governance model. The governance model is the job split above: canon, recall, relationship state, reflection, coding traces. The same mechanism can serve different jobs, and the same job can use several mechanisms underneath it.

What helps — layer by job, not by vendor

The architecture I keep landing on for my own stack:

• Layer 1 — canonical knowledge. Obsidian-style markdown wiki. Tracked in git. The agent reads it, the agent doesn't write it without a review step. GBrain is the named version of this for me. Inspectability matters more than retrieval cleverness — if I can't cat it, I don't trust it.
• Layer 2 — adaptive recall. Lifecycle primitives borrowed from Hippo: half-life decay, retrieval strengthens, errors stick longer, sleep consolidation. Doesn't have to be Hippo specifically — the primitives matter, not the package. Could ship as a small SQLite + markdown-mirror layer inside .agents/ (which is where chalk-bag puts everything else, so the homing instinct is right).
• Layer 3 — runtime/social state. Honcho or something like it. Stays separate from world facts. Boundaries matter; you don't want the relational layer feeding back into the canonical wiki.
• Layer 4 — reflection. The piece I'm least sure about. The Hindsight reflect() operation is interesting because it explicitly takes the bank's directives and disposition as input — that's an agent reasoning about itself and its data. I think this is where the actual learning (in the long-horizon sense) is going to happen. It's also the layer that needs the most provenance discipline; reflective claims should always be traceable back to evidence.
• Layer 5 — coding-agent automation. This is where AgentMemory-style tools live. I lean toward not having a separate canonical store here — instead, the coding-agent layer should write back into Layer 1 with a review gate. That keeps the source of truth single.

What I'd watch for

A few load-bearing constraints I'm holding myself to as I keep building this out:

• Two canonical stores = no canonical store. If Layer 1 (wiki) and Layer 5 (coding-agent auto-capture) both claim to be the truth about the codebase, you've lost. Pick one, make the other a derived layer that flows up with a human in the loop.
• Lifecycle is the contribution, not the leaderboard. The useful idea in Hippo is not "this retrieves better than X on benchmark Y." It's that memory records should have a lifecycle: decay when stale, strengthen when reused, consolidate when repeated, and surface conflicts when evidence disagrees. Retrieval quality matters, but it's only one mechanism inside that lifecycle.
• Reviewability is the audit format. Markdown is one good shape, but it is not the requirement. HTML, SQL rows, graph edges, vector chunks, YAML, whatever — the requirement is that a human can inspect the source, trace why a memory was written or retrieved, and debug when the system's memory stops matching reality. If the only explanation is an opaque embedding hit, it's tech debt.
• Reflection without provenance is hallucination at rest. If reflect() produces an observation, the observation should carry pointers to the evidence that produced it. Otherwise you're persisting confabulation as fact.

Series map

This post is the hub. The follow-ups split the jobs out:

1. Canon is not memory — llm-wiki, GBrain, Obsidian, repo docs, and why reviewed truth should be inspectable.
2. Semantic memory is for recall, not authority — Hindsight, vector stores, adaptive recall, provenance, and why vector hits need evidence before authority.
3. Relationship memory is its own layer — Honcho-style user, role, preference, and session state.
4. Coding-agent memory is a black-box recorder — AgentMemory, Hermes traces, tool events, failed attempts, and continuity across runs.
5. Orchestrators need projections, not one giant memory — why explore, climb, and summit need different context slices.
6. Who gets to write truth? — the write path: observe, retrieve, synthesize, propose, review, canon.

Outcomes

• The "agent memory" tools I'm planning to use (in their respective slots): GBrain for L1, Hippo's primitives for L2 (not necessarily Hippo wholesale), Honcho for L3, Hindsight's epistemic split as an idea for L4, none for L5 — feed coding-agent context back into L1 with review.
• The next chalk-bag iteration should consider whether Layer 2's lifecycle primitives belong in .agents/ as a first-class concept or live as a separate companion tool.
• The thing I'm holding for a follow-up post: how reflection (L4) interacts with the in-context-prompting-vs-agent-orchestration debate — if the orchestrator's job shrinks to runtime + verification, where does reflection's writes go?

Notes

• The most useful single read on this was hindsight's epistemic separation. Even if you don't adopt Hindsight, the world-facts-vs-experiences-vs-observations split is the framing I wish I'd had a year ago.
• Hippo's tagline ("the secret to good memory isn't remembering more — it's knowing what to forget") is the kind of one-liner that's load-bearing. Decay isn't a feature, it's the point.
• I'm currently leaning against any architecture where the agent's reflective layer can write directly to the canonical wiki. The wiki is the human-readable artifact; agent writes go through a review step or they end up creating their own truth.