The same tenant task — with memory.
A coding agent can write code that compiles, passes tests, and still violates decisions your team already made. Decision Memory serves the agent only the memory that applies to the task, flags conflicts before they ship, and returns what it learned for human review.
Before the task, in the task, and back for review.
What the agent lacked
- Structured tenant data stays in SQL
- Uploaded files stay in SharePoint
- Writes go through the repository layer
- Never log customer identifiers
- Schema changes require architecture review
DM serves the subset
- Only decisions & rules for this task
- Constraints + exceptions
- Authorization context
- Any conflicts flagged
Returned for review
- Decisions & rules applied
- Proposed ADR + open question
- Follow-up task + evidence
Why capable agents still ship the wrong thing
Give a coding agent a ticket that says “implement tenant administration” and it will read the ticket and the repository, then write clean, working code. Tests pass. Code compiles. Nothing in the repo tells it that six months ago your team banned a database driver, standardized on a repository layer, and made a firm rule to never log customer identifiers.
So it stored file blobs in SQL, bypassed the repository layer, logged customer identifiers, added an unapproved retry library, and changed the schema without review. Every one of those was already decided against — the agent just couldn't see it. It was optimizing against the code it can read, not the decisions your organization already made.
The problem was never code quality. It was missing approved decision context.
What “task memory” actually contains
When the agent picks up the task, Decision Memory resolves and serves only the in-scope subset: the tenant and data-model decision (with the rationale and the alternatives that were rejected), the repository-layer rule, the “never log customer IDs” constraint, the authorization context for what the agent may touch, and — critically — any conflicts between what's being asked and what's already been decided.
It is deliberately not the whole registry. Loading everything is how .cursor/rules files become unusable. The point is to render the current, applicable memory for this task.
The agent proposes; a human approves
When the work is done, the agent writes back: the decisions and rules it applied, a proposed architecture decision record, an open question it couldn't resolve, and a follow-up task with evidence. None of that silently becomes organizational truth. A human reviews each candidate and approves, edits, or rejects it. Agents never approve organizational memory. Decision Memory is a memory and governance product — your runtime still enforces the actions the agent is allowed to take.
How the agent connects
Coding agents reach Decision Memory over MCP: dm.search_decisions to search approved decisions, dm.get_decision_context to pull the permitted context for a task, dm.check_conflicts to detect contradictions, and dm.propose_decision to submit a candidate for human review. This works alongside Cursor, Copilot, and Claude Code rather than replacing them.
New to the idea? Start with what Decision Memory is, or see why AI coding agents ignore team standards.
Point one coding agent at your decisions.
One team, one agent workflow, one decision domain — 2–4 weeks. We measure decision recall, repeated discussions, and conflicts caught before they ship.