Academy Use case

The Decision Log Your AI Tools Keep for You

July 28, 2026 · updated October 6, 2026

Decisions made in chats and on calls vanish within weeks. Have your AI tools save each one with its reason, so "what did we decide?" always has an answer.

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 will not find it, because conversations are where decisions go to dissolve. The conclusion gets acted on, the reasoning evaporates, and six months later the company has the classic argument: half the team relitigating a settled question because nobody can reconstruct why it was settled, while the other half quietly 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.

It is getting worse, not better, 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. The fix is to let the tool you were already thinking with write the entry, at the moment of deciding.

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.” The test: would someone later ask “why did we decide that?”

Context Engine holds the line for you. 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 if they were is how a log starts lying. A log that records everything is as useless as no log; the value is in the filter.

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 contains its rebuttal.
  • 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 instructive 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, links it, and hands it to every other tool that reads that engine. One tool writes it; every tool can find it.

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 carry most of the quality. “Not musing” is the filter. “Never what you would have decided” is the honesty rule: the tool is a stenographer with judgement, never the author. For coding work this is where architecture decisions stop dying 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.
  • Home asks about near-duplicates. Identical memories are merged with both histories kept, and you can undo that from the memory. Similar ones are raised on Home for you to decide.
  • 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

ChoiceStarting pointAlternatives
When to saveon standing instructiononly when you say “save that”
Which engineone per team or projectone per client
Thresholdreal choice with a stated reasonadd your team’s own definition
Confirmationtool reports one line per savetool asks before saving
Meetingsfrom transcripts you drop infrom 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 compounding effects are bigger. Relitigation drops, 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. Onboarding sharpens, because a new hire reading a year of decisions with reasons is the closest thing to downloading institutional judgement that exists. 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. One save, read everywhere.

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.

The discipline this replaces is one nobody sustains by hand. The discipline it requires, reading one line when your tool says it saved something, is one anyone can. See plans, or start free.