The Decision Log Your AI Tools Keep for You

Somewhere in your history is the moment your team decided to drop the monthly plan, or standardize on one vendor, or stop selling to a whole segment. Try to find it. Now try to find why: what the alternatives were, who was in the discussion, what would need to change for the decision to be revisited.

You probably will not, because decisions made in conversation are rarely written down. The conclusion gets acted on and the reasoning is lost. Six months later half the team argues the question again because nobody can say why it was settled, while the other half assumes the old answer still stands. New hires inherit the outcomes with none of the reasons, which is how “that’s just how we do it” becomes a company’s most-cited policy.

This is getting worse, because more of the reasoning now happens inside AI chats. You work a pricing question through with Claude for an hour, reach a conclusion, and close the tab. The reasoning was never anywhere a colleague could see it.

Companies that take decisions seriously have always kept decision logs. Almost nobody sustains one by hand, because the log competes with real work every day. A better way is to let the tool you were already thinking with write the entry when you decide.

What counts as a decision

The definition comes first, because it keeps the log worth reading. A decision is a choice with consequences and a reason: “we decided X because Y, over alternative Z.” A simple test is whether someone would later ask “why did we decide that?”

Context Engine enforces part of this. A decision memory needs a rationale. If you cannot say why, it is a note.

Three things fail the test on purpose. Tasks are not decisions (“Anna will update the deck” is a commitment, which has its own piece). Reference facts are not decisions (“the new domain is live” is a note). Open questions are not decisions yet, and recording them as decisions makes the log wrong. A log that records everything is as hard to use as no log at all.

What a saved decision looks like

Here is one decision as it appears in an export of the engine: Markdown with YAML frontmatter. The field names are an illustration of the shape, and the scenario is invented:

---
type: decision
title: Annual-only pricing for new customers
rationale: >-
  Monthly customers churned far faster than annual ones and needed
  more support each. Existing monthly customers keep their plan.
alternatives:
  - Keep both plans (pricing page confusion, support cost)
  - Quarterly plan as a compromise (worst of both)
decided_at: 2026-03-12
tags: [pricing]
---
Agreed by Deniz, Anna and Mert on the March 12 pricing call.
Raised by Anna. Takes effect for signups from April 1.

• The decision in one line, because a log gets scanned before it gets read.
• The reason, with the alternatives and why they lost. This is the part conversations lose and the part future you needs most. When someone proposes the quarterly compromise next year, the log already says why it was rejected.
• Who and where: the people involved and the conversation it came from, so the entry can be traced.
• Links: to the people, customers and projects it touches. On the Map in Memories you can see a decision beside the people and customers it connects to.

Every change to a memory records who made it, with which tool, and what it was before. When you change your mind, save a new decision that says it replaces the old one rather than quietly editing it. The log then keeps the history of changing your mind, which is often the most useful part.

How it works

Context Engine does not listen to your conversations. Your AI tool, connected to an engine with Can read and save, saves a decision when it recognizes one or when you say so. The engine stores it and links it. Every other tool that reads that engine can find it, and so can everyone on the team in the app.

There are two ways to get decisions in, and you will use both.

At the moment of deciding. You are in a chat with Claude or ChatGPT, or in Claude Code or Cursor, and you land on an answer. Say: “Save that as a decision in the Payments engine, with the rationale and the options we rejected.” The tool writes it and tells you what it saved.

By standing instruction. Better still, put a short rule in the AI tool’s standing instructions, so you do not have to remember. In a Claude project or ChatGPT’s custom instructions, or in a repository’s CLAUDE.md or Cursor rules for coding work:

When we make a decision (a real choice with a reason, not musing),
save it to the Payments engine as a decision: one-line title, the
rationale, the alternatives we rejected and why, and who was involved.
Search the engine first so you don't save it twice. Save only what we
actually decided, never what you would have decided. Tell me in one
line what you saved.

Two phrases do most of the work. “Not musing” keeps out ideas that were only discussed. “Never what you would have decided” keeps the tool recording your decisions instead of making its own. For coding work, this keeps architecture decisions from getting lost in pull request threads. Claude Code saves “we chose a queue over cron for retries, because…” to the engine, and the next session, in any tool, starts knowing it.

After a meeting. Decisions made out loud evaporate fastest. If you have a transcript, drop it into Files or paste it in and ask your tool to save the decisions in it, each with the reason stated in the meeting. See the meeting-notes piece.

Checking what got saved

There is no separate review queue to work through. Three things keep the log honest instead:

• The tool says what it saved, in the chat, as it saves. Read the line. If it is wrong, say so and it can correct it; the history keeps both versions.
• Repeats are caught when they are saved. A decision whose title matches one already saved is refused, and the tool is pointed to the existing one to update. Lookalikes are reported back to the tool. A reworded repeat can still get through; archive it.
• Summaries gives you a written account of each day, rolled into weeks and months, from what was saved. A glance at the week shows what got decided and by whom, without anyone writing a report.

Tuning it

Choice	Starting point	Alternatives
When to save	on standing instruction	only when you say “save that”
Which engine	one per team or project	one per client
Threshold	real choice with a stated reason	add your team’s own definition
Confirmation	tool reports one line per save	tool asks before saving
Meetings	from transcripts you drop in	from your own recap after the call

Every team has its own decision dialect: “locking this in”, “final answer”, “ship it”. Put yours in the standing instruction so the tool recognizes them.

What changes

“What did we decide about X?” becomes a question with an answer. Anyone, in Ask in the console or in any AI tool connected to the engine, gets the decision, the date, the reason and the people, with the memory it came from.

The longer-term effects matter more. Settled questions get reopened less often, because “we chose annual-only in March, here is the reasoning, has anything changed?” is a five-second lookup instead of a forty-minute meeting. New hires get up to speed faster, because they can read a year of decisions with the reasons attached. And decision quality tends to rise once people know the reasoning gets recorded: “because I said so” reads worse in a log than it sounds in a meeting.

The same entries feed everything else that reads the engine: pre-meeting briefs mention decisions involving the people in the room, and account memory shows decisions affecting a client beside their calls.

Failure modes, and the fixes

The log fills with noise. The tool is treating strong opinions as decisions. Tighten the standing instruction (“a real change of course with a stated reason”) and archive the misfires.

The log misses the big ones. Big decisions happen in meetings, and nobody tells the tool. Make the end-of-meeting save a habit, or drop the transcript in.

Entries lack a reason. The engine will not take a decision without one, so the tool will ask, or save a note instead. Treat that as a useful prompt to ask “wait, why did we decide this?” while everyone still remembers.

Only one person’s tool is saving. A log fed by one person is one person’s log. Give each person who decides things their own connection to the engine, so their tools save there too.

Build this yourself

1. Create an engine with a purpose that names decisions, for example: “How we run payments: what we decided and why, who owns what, open questions. Not customer data.”
2. Connect each AI tool you think in with Can read and save. Claude Code takes one command, for example claude mcp add --scope user --transport http ce-payments https://app.contextengine.com/mcp/c/<id>.
3. Add the standing instruction above to each tool’s project instructions, with your team’s phrasing.
4. Ask a week later, in Ask: “What did we decide this week, and why?” If the answer is thin, tighten capture before anything else.

Few teams keep a decision log going by hand. This one asks only that you read one line when your tool says it saved something. See plans, or start free.