Giving an agent access to decisions was easy. Teaching it when those decisions matter was harder.
When I started building DecRec, MCP looked like the obvious interface.
DecRec stores decisions. Agents need to search them, read them, create draft records, and update their state.
So I exposed a handful of MCP tools:
search_decisionsget_decisioncreate_decisioncommit_decision- ...
It worked.
But the agent had the tools without knowing when to use them.
That turned out to be the harder problem.
The hard part wasn’t storing decisions
Consider a normal conversation with a coding agent.
You discuss whether authentication belongs in the application or at the edge. You explore both approaches, examine deployment constraints, reject one option, and decide to keep authentication in the application.
There is probably a decision worth remembering in there.
Now consider another conversation.
You’re implementing a button. You put it on the left, don’t like it, move it to the right, and keep going.
Technically, you made a choice. It probably shouldn’t become part of your organization’s permanent memory.
Exposing a create_decision tool doesn’t teach an agent how to distinguish between those situations. Tool descriptions can explain arguments and return types, but the important questions happen one level above the API:
- Is this actually a decision?
- Is it important enough to remember?
- Has the user decided yet?
- Should I search for an earlier decision first?
- Are we making a new decision or reopening an old one?
- Should I say something or let the user work?
Those turned out to be the interesting problems.
We didn’t want DecRec everywhere
The naive solution is to make the agent aggressive: search DecRec constantly, offer to record every choice, and keep reminding the user that decision records exist.
That would make DecRec unbearable.
While building the DecRec Skill, we settled on a simple test. A choice is worth capturing when all three of these are true:
- There were credible alternatives.
- The choice meaningfully constrains future work.
- Someone could reasonably return later and ask, “Why did we do it this way?”
That excludes a lot.
Renaming a variable isn’t a decision. Moving a button isn’t a decision. Following an existing convention isn’t a decision.
Choosing Postgres over DynamoDB because reporting requirements matter probably is.
Deferring team accounts until there is evidence of collaborative demand probably is.
Choosing local-first state because offline behavior is a product requirement probably is.
Bad memory can be worse than no memory. If an agent records every small choice, useful decisions eventually disappear into noise. The goal isn’t to remember more; it’s to remember the right things.
MCP provided capability. We still needed behavior.
The DecRec MCP server answers questions like:
What decisions match this query?
What does DEC-42 say?
Create a draft decision record.
Commit this decision.
The Skill addresses a different set of questions:
When should I search?
When should I offer to create a record?
What information belongs in it?
Has the user actually decided?
When should I leave them alone?
MCP provides durable state and operations. The Skill guides the agent’s behavior around that state.
For example, the Skill defines decision boundaries where recall becomes useful: when the user is about to make a consequential choice, when current work appears to conflict with an established direction, or when an existing constraint is being reconsidered.
It doesn’t search DecRec before every task. The goal is to make recall situational rather than ambient.
MCP made DecRec accessible to the agent. The Skill made that access useful without requiring the user to orchestrate it.
Recall changed how I thought about the product
It’s natural to begin designing a decision system around capture: a decision happens, so you record it.
But the more important moment comes later.
Imagine that three weeks ago you and Claude discussed account architecture. You considered organizations, workspaces, and single-user accounts. You decided to remain single-user because there wasn’t enough evidence that customers needed collaboration.
You record the decision and move on.
Three weeks later, you’re in Cursor with a different agent and a fresh conversation. You’re implementing invitations, and the obvious approach starts pushing the data model toward organizations.
This is where DecRec should matter.
Before casually redesigning the account model, the agent should be able to discover:
We already made a decision about this. Here’s why.
That recall can’t depend entirely on the user remembering to say, “Search DecRec for anything relevant.”
If you remembered the decision well enough to ask every time, much of the problem would already be solved.
The MCP server can perform the search. The Skill helps the agent recognize when earlier decisions may constrain the work in front of it.
Old decisions are context, not commandments
Persistent memory introduces another problem: decisions can become wrong.
Maybe three customers now need team accounts. Maybe the constraint behind a local-first architecture no longer exists. Maybe usage has grown enough to justify revisiting an earlier tradeoff.
Recall shouldn’t mean:
DEC-12 says X. Do X.
It should mean:
DEC-12 says we chose X because of A, B, and C. The current work appears related. Do those reasons still apply?
Models are good at following instructions. If you give an agent a pile of old decisions and imply they are permanently authoritative, organizational memory can become organizational inertia.
The value of a decision record is not merely that it preserves the chosen direction. It preserves the reasoning that made the direction sensible, so changed evidence can trigger a deliberate reconsideration rather than an accidental reversal.
Human commitment matters
This led to another rule in DecRec:
The agent doesn’t get to decide that something has become an organizational commitment.
It can explore alternatives, identify tradeoffs, draft a decision record, and notice when a conversation appears to have reached a consequential choice.
But the human commits it.
There is what the AI said.
And there is what the human decided.
Those are not the same thing.
I don’t want an agent brainstorming five pricing models and silently turning one suggestion into company policy because the conversation happened to move on.
A draft can be created and refined with AI. The committed record must represent a choice someone actually made.
AI explores.
You decide.
DecRec remembers.
That line began as product language, but it became an architectural constraint.
Why not keep everything in files?
For a single developer, a single repository, and a single agent, I would probably start with files.
An AGENTS.md, a directory of ADRs, or a well-maintained Markdown file can work remarkably well. Not every developer needs an MCP server for something a text file already solves.
The problem DecRec addresses starts when decisions need to stay discoverable and consistent across people, projects, and tools.
A product decision might happen in ChatGPT.
An architectural decision might happen in Claude Code.
Implementation might continue in Cursor.
Someone else might join the project next month.
Files can preserve decisions across time, but you still need conventions for discovery, structure, status, ownership, and updates. DecRec provides those conventions as a shared system that multiple compatible agents can access.
The decision shouldn’t belong to Claude or Cursor, or to the conversation where it happened.
It belongs to the work.
MCP is a good interface for that shared state. The Skill makes the interface usable without requiring the human to operate it manually all day.
The tools weren’t the whole product
There’s a temptation when building an MCP server to think the work is mostly done once the tools are well designed: expose useful capabilities, write clear descriptions, and let the model figure out the rest.
A better question for us turned out to be:
What does an agent need to understand to use these tools well?
The agent needed a model of what a meaningful decision is. It needed capture criteria and rules around human authority. It needed to distinguish exploration from commitment, know when recall would help rather than interrupt, and understand that an earlier decision can be relevant without being permanently correct.
That’s behavior, not API documentation.
The DecRec Skill is open source, so you can see the actual instructions rather than take my word for it.
DecRec ended up as both: an MCP server that gives agents access to a shared, durable decision layer, and a Skill that teaches them how to behave around it.
Packaging the two together as an Agent Plugin now feels obvious.
It wasn’t obvious when I started.
The larger lesson
I’m increasingly skeptical that agent memory is simply a matter of giving models more context.
We already have plenty of systems that remember things.
ChatGPT can remember preferences.
Claude can maintain project context.
Cursor understands code.
Slack keeps conversations.
Notion keeps documents.
Git keeps history.
DecRec doesn’t need to replace any of them. It is interested in a narrower kind of memory:
What did we decide, what alternatives did we consider, and why did we choose this direction?
That information is small and infrequent, but it has an unusually long half-life.
A six-month-old conversation may be useless. The decision that came out of it may still determine how the product works.
In practice, the DecRec plugin should search when current work appears constrained by an earlier decision, surface the reasoning without treating it as law, and offer to draft a record only when a consequential choice becomes clear.
Nothing becomes an organizational commitment until the user confirms it.
That’s the thing I want an agent to remember.
Building DecRec taught me that storing it was the easy part. The harder part was teaching the agent when it matters.