Memory

Memory is how MadoHub agents remember things between sessions. Without it, every new terminal means an agent re-learning your conventions, your stack, your coding style, and the decisions you made last week. Memory survives across sessions and projects, so an agent picks up where the last one left off instead of starting from scratch.

Memory is separate from a session's chat history. Chat history is the conversation you are having right now; memory is the durable background the agent draws on. You stay in control of what gets remembered: an agent's guess about what is worth keeping goes into a review queue first, and you approve it before it lands in long-term memory.

What you can do with it

• Store six kinds of things — preferences, facts, decisions, patterns, postmortems, and events. Each entry is tagged with its kind so the Memory Dashboard can filter and label it cleanly.
• Organize by namespace — keep persona-specific memory separate from project-specific memory. An agent recalling a project convention will not pull in every persona's personal preferences.
• Review before it sticks — every candidate memory sits in a pending queue for your approval. Edit the wording, change the kind, reject it, or approve it as-is.
• Auto-inject relevant memory — turn on automatic recall and matching entries are prepended to each new conversation, so relevant preferences and decisions surface without the agent having to ask.
• Search manually — agents can call recall explicitly with a full-text query when they need something specific.

How to use it

1. Open Settings → Memory to reach the Memory Dashboard.
2. Review candidates in the Pending review tab. For each one you can:
   • Approve as-is
   • Edit the content or kind, then approve
   • Reject it
   • Jump back to the original conversation turn that produced it
3. Browse and manage approved entries in the Approved tab, grouped by namespace. Edit, delete, or manually add new memory from here.
4. Toggle automatic recall injection to choose whether matching memory is auto-prepended to new conversations, or only surfaced when an agent calls recall explicitly.
5. Optional: in the Advanced section, enable policies like auto-approving candidates that have been seen enough times at high enough confidence.

Common use cases

• "We use pnpm, never npm." — a preference an agent can recall on every new session instead of discovering it by failing first.
• "We decided to keep auth in the monolith, not split it out." — a decision that should keep resurfacing so future agents do not re-litigate it.
• "The flaky test in payments.spec is caused by a race in the mock clock." — a postmortem worth remembering next time someone touches that file.
• "This project's API responses are camelCase JSON." — a fact the agent pulls in whenever it generates or edits API code in that workspace.

Tips and best practices

• Review the pending queue regularly. A wrong or stale decision or postmortem is worse than a missing one, because it will keep resurfacing on future recalls.
• Use namespaces deliberately — scope project conventions to the workspace: namespace so they do not leak into other projects.
• Pin entries you never want auto-superseded; pinned entries surface first on recall.
• If memory starts feeling noisy, turn off automatic injection and let agents call recall explicitly only when they need it.

Related features

• MadoAgent — the panel where agents use memory most often.
• Settings — where the Memory dashboard and its policies live.

Limitations

• Recall queries need at least 3 characters — shorter queries are rejected so the agent knows to rephrase rather than silently getting nothing back.
• Candidates auto-archive after 30 days of inactivity, so do not let the queue sit forever.
• Memory does not replace chat history; it is a smaller, curated layer of durable facts.