Teaching MadoHub to Remember

Every agent session starts from zero. You tell Claude Code your project uses pnpm, not npm, on Monday. By Thursday's session, that's gone — unless you type it again, or unless something else is holding onto it for you.

That "something else" is what we've been building into MadoHub over the last several phases: a memory system that sits underneath the chat history, survives across sessions and projects, and gives agents a way to read and write what they've learned. This post is about how that system is shaped, and about the one design decision in it that we think is the most important: extracted memory doesn't become real memory until a human says so.

How MadoHub handles it

Six kinds of memory

Every memory entry carries a kind, and the set is closed to exactly six values:

There's no seventh option and no free-form field. That's deliberate: the Memory Dashboard filters and labels by kind, and a "ghost" kind that slipped through would just be a category nothing can search or display correctly.

Namespacing by persona and project

Memory is partitioned by namespace, so what an agent recalls can be scoped. A persona: namespace ties memory to whichever persona is active; a workspace: namespace ties it to a specific project. When an agent writes a memory without specifying a namespace, it defaults to the active persona. When it recalls, it can narrow to one namespace — pulling only from a project's memory, for instance, instead of every persona's at once — so recall stays relevant instead of surfacing clutter from unrelated projects.

Three ways a candidate gets born

An agent writing a memory explicitly is the obvious path, but it's not the only one. MadoHub also watches your conversations in the background:

• Explicit remember — the agent decided, mid-conversation, that something was worth keeping and wrote it down.
• After each turn — a lightweight model pass scans the last exchange for anything durable, because most of what's worth remembering surfaces in normal conversation rather than at deliberate "remember this" moments. This runs on every turn, so it's noisier by design.
• Before compaction — right before a long conversation window gets summarized to save context, the same kind of scan runs over the messages about to be compressed. This one matters because compaction is lossy: once a range of messages is summarized away, anything not extracted from it is gone from long-term memory for good. A quiet stretch of conversation costs one cheap model call and adds nothing rather than padding the queue with noise.

Manual entries from the Memory Dashboard round out a fourth path, still routed through the same candidate table, just entered by a person instead of extracted by a model.

Why review, not auto-write

Here's the design choice at the center of this system: none of those four paths writes into searchable memory. Every one of them lands in a candidate queue with a status that starts at pending and moves on to approved or rejected — or, if nobody reviews it at all, archived after it's sat untouched for 30 days. Only approved candidates get promoted into the memory that agents actually search.

You'd think this slows things down, and it does, by design. The alternative — letting a model's judgment about what's "important enough to remember" write straight into a store that gets pulled into every future conversation — means a bad guess doesn't just cost you a wrong answer once. It costs you a wrong answer every time that memory gets recalled from now on, compounding silently until someone happens to notice the agent citing something that isn't true. That risk is worst for exactly the two kinds you'd most want to trust: postmortem and decision entries tend to get weighted heavily by whatever consumes them later, so a stale or wrong one does more damage than a missing one ever would.

Review happens in Settings → Memory, split across a pending queue — content, kind, namespace, source, confidence, and how many times an equivalent candidate has been seen, with the option to edit before approving or jump to the originating turn — and an approved view grouped by namespace where entries can be edited or deleted. There's also an Advanced section with opt-in auto-approval: once a candidate has been seen enough times at high enough confidence, it can promote itself without a manual click. That policy defaults to off. Left off, every single thing an agent decides you might want it to remember passes in front of you first — which is, for now, exactly the point.

Practical guidance

• Skim the pending queue regularly. Memory only helps once it's approved, and candidates that sit untouched for 30 days get archived. A quick pass through Settings → Memory every few sessions keeps the queue from backing up.
• Edit before approving. If an agent captured the right idea in the wrong words — "uses npm" when you actually use pnpm — fix it in the queue rather than approving and correcting later. Approved memory is what agents will cite.
• Scope with namespaces. Project-specific facts belong in the workspace: namespace so they don't bleed into unrelated projects. Persona-level preferences belong in persona:.
• Be careful with decision and postmortem. These get weighted heavily when agents recall them, so a stale or wrong entry does more damage than a missing one. Prefer rejecting an iffy candidate over approving it and hoping it's fine.
• Turn on auto-approval only if you mean it. The Advanced setting can promote high-confidence, frequently-seen candidates without a click, which is convenient but removes the human gate. Leave it off until you trust the extraction quality.

Related docs

• Memory
• Settings