DM, built by AuzzurA, is shared context for human + AI teams. It governs the Decisions, Rules, and Skills that define how your organization works, resolves the subset that’s current, applicable, and permitted for a given task, serves that to a human or a connected AI agent, and lets agents propose new learning that a human reviews before it becomes trusted.
The core question DM answers isn’t “what happened before” — plenty of tools remember that. It’s “what applies to this task, right now?”
The problem it solves
Every AI agent you deploy is capable, fast, and tireless — and shows up to every task with no sense of how your organization already decided to work. Humans hold that context in a few tenured heads. Agents rebuild it from scratch every task and discard it at the end. The layer the whole human + AI team should share simply doesn’t exist.
The result is work that is technically plausible but organizationally wrong: code that compiles and passes tests while quietly using a database driver you banned, skipping the repository layer you standardized on, or logging customer identifiers you decided never to log. Nothing in the repository told the agent what you had already decided.
What “decision memory” means, and why DM is more than that
You’ll sometimes see the term decision memory used as a general concept: the idea of keeping a durable, retrievable record of what an organization decided and why, as distinct from a raw meeting note or a chat log. That concept is genuinely useful, and it’s part of what DM does.
But DM isn’t only that. Remembering a decision happened is not the same as knowing whether it still applies. DM adds a governance and applicability layer on top of that raw record: it decides what’s current, what’s authoritative, what’s permitted for a given actor, and what a task actually needs — then serves only that. Decision memory is an input. DM is the system that governs and resolves it into something safe to hand to a human or an agent.
What actually lives in DM
DM isn’t a pile of notes. At minimum, it governs these object types:
- Decision — what was chosen, and why: the rationale, the evidence, and the alternatives you rejected.
- Rule — what must or must not happen: constraints, exceptions, and what needs approval.
- Skill — how a class of work is expected to be done.
- Authorization context — who may do what, where, and under which conditions. This informs the task context DM prepares; your runtime still enforces what an agent is actually allowed to do.
One task usually touches several of these together. A single “store machine artifacts as JSON” decision comes with a rule (never store them in Excel), a skill (define the schema, validate, store an example), and authorization context (the agent may write to the repo, but an external upload needs approval).
The loop: context in, learning back
DM works as a loop rather than a static document:
- Capture evidence — meetings, decisions, tickets, and the reasoning behind them.
- Govern — a human approves what becomes trusted, governed context.
- Resolve — DM determines what’s current, applicable, and permitted for the task in front of a person or agent.
- Work — the human or connected agent does the task with that context.
- Propose — new learning, applied rules, and open questions come back as a candidate.
- Review — a human decides what becomes trusted for next time.
The invariant across the whole loop is simple: AI proposes, humans approve. Connected agents read permitted, applicable context and submit candidates. They never approve organizational knowledge themselves.
What DM is not
| It is not… | Because… |
|---|---|
| a meeting note-taker | a note-taker captures what was said; DM governs what was decided and whether it still applies. |
| a generic chatbot or RAG search | it answers from approved, applicable context, not from an unfiltered document dump. |
| just an LLM wrapper, or a Mem0/Graphify wrapper | Mem0 and Graphify are implementation providers for specific capabilities (memory, repository intelligence); DM is the governance and applicability layer that sits above them. |
| a runtime policy-enforcement engine | DM determines what context applies and is permitted; enforcing what an agent is allowed to do remains with your own systems. |
| cloud storage for Cursor rules | it’s one resolved source of what applies to a task, not duplicated per-tool files that drift. |
| a replacement for Jira or Confluence | it’s shared context across the tools you already use. |
That last point matters. In mature teams the problem often isn’t missing documentation — it’s that the context behind a decision gradually disappears, and decisions get buried inside pages that are hard to retrieve later. DM preserves that history and makes it findable even when you don’t know the exact keyword.
How agents connect
Coding agents reach DM over MCP: dm.prepare_task_memory for already-approved context that applies to the task, dm.search_decisions to search approved decisions, dm.check_conflicts to detect contradictions, dm.propose_decision to submit a candidate, and dm.submit_memory_update to propose new learning for human review. It runs alongside Cursor, Copilot CLI, and Claude Code rather than replacing them. Connecting an agent is explicit.
Where to start
Most teams begin with one workflow and one decision domain. If you deploy coding agents, see why AI coding agents ignore team standards and the coding-agent alignment use case. If your challenge is scattered technical direction, see the strategy and architecture use case.
One team. One workflow. One governed loop.
Test AuzzurA with a single agent workflow in 2–4 weeks.