The Decision Log That Writes Itself

Somewhere in your chat 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 chat is 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.

Companies that take decisions seriously have always kept decision logs. Almost nobody sustains one manually, because the log competes with real work every single day. The fix is to stop asking humans to maintain it.

What counts as a decision

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

Three things fail the test on purpose. Tasks are not decisions (“Anna will update the deck” is a commitment; that has its own flow). 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 captured decision looks like

Each entry the flow records has four parts, and the shape matters more than the tooling:

Decision: Annual-only pricing for new logos
Why: monthly churned at 3x annual; support load per monthly
  customer ~2x. Grandfathering existing monthlies.
Considered: keeping both (rejected: pricing page confusion,
  support cost); quarterly compromise (rejected: worst of both).
Who: Deniz, Anna, Mert. Raised by Anna.
Evidence: #pricing thread, Mar 12, "ok let's go annual-only
  for new signups starting April"
Linked: pricing project, Q2 revenue plan

• The decision in one line, at most eighty characters, because a log gets scanned before it gets read.
• The rationale, with the alternatives considered and why they were rejected. This is the part chat loses and the part future-you needs most: when someone proposes the quarterly compromise next year, the log already contains its rebuttal.
• The people involved and the evidence: the actual exchange that justifies recording it, quoted or paraphrased, so every entry can be traced to its source. Nothing enters the log that did not happen.
• Links into the graph: the projects, accounts, and people the decision touches, so it is reachable from any of them. Ask about the pricing project and this decision is part of the answer; ask about the decision and the affected work is one hop away.

One decision, one record. When a decision changes later, the new record supersedes the old one rather than silently editing it, so the log preserves history, including the history of changing your mind, which is often the most instructive part.

The config, shown

Two flows cover the two ways decisions actually happen. The evening sweep is the workhorse:

name: decision-log
trigger: schedule
cron: "0 19 * * *"          # every evening, 19:00
tools: [engine]
watch_conversation: true
confirm_first: false
prompt: |
  Review the team conversation above for genuine DECISIONS the
  team reached, a real "we're going to do X" with a reason, not
  musing. For each, search the engine to avoid duplicates, then
  record it as a decision with its rationale and who was
  involved. Keep it faithful: capture what was actually decided,
  not what you'd have decided. If nothing was decided, say so in
  one line.

And the keyword catch handles the moment itself, for teams that want zero lag:

name: decision-catch
trigger: keyword
keywords: ["decided", "we'll go with", "decision:"]
tools: [engine]
watch_conversation: true
prompt: |
  A message suggested the team just made a decision. From the
  recent conversation, work out what was actually decided and
  why. If it's a real decision, search the engine to avoid
  duplicating it, then record it as a decision with its
  rationale and who was involved. If it was just talk, not a
  decision, do nothing.

Run both: the catch gets the explicit moments, the sweep gets the decisions nobody flagged. The duplicate search in each prompt is what lets them coexist without double-logging.

Two lines carry most of the quality. “Not musing” is the filter. “Capture what was actually decided, not what you’d have decided” is the honesty rule: the agent is a stenographer with judgement, never an author. And note “If it was just talk, do nothing”: a flow that knows when to stay silent is a flow people keep enabled.

Teams that run meetings through a recorder extend the same capture to calls: transcripts flow into the engine through the meeting-notes pipeline, and decisions made out loud get logged with the same rigor as decisions made in writing. In practice, spoken decisions outnumber written ones two to one, and they are the ones evaporating fastest today.

The review queue, and why it stays

Each captured decision lands as provisional, in a review queue. A human, usually whoever already reads end-of-day updates, glances at the day’s captures and confirms or discards. A minute, most days.

Resist the urge to remove this step once the flow proves accurate. The queue is not scaffolding; it is the trust boundary. A log where every entry passed a human eye can be cited in an argument and settle it. A log that might contain misfires gets double-checked every time, which quietly costs more than the minute the queue takes. If the volume grows, tighten the filter rather than skipping review.

Tuning it

Knob	Default	Alternatives
Sweep cadence	daily, 19:00	twice daily for busy teams
Keyword catch	on, three triggers	off, or add your team’s phrasing
Confirmation	provisional, human review	auto-confirm trusted channels
Scope	team channels	add per-project channels
Meeting capture	via transcript pipeline	chat only

The keyword list deserves ten minutes of thought: every team has its own decision dialect (“locking this in”, “final answer”, “ship it”). Add yours.

What changes

The immediate effect: “what did we decide about X?” becomes a question with an answer. Anyone, including any AI agent your team runs, can ask the engine and get the decision, the date, the reasoning, and the people, with a citation to where it happened.

The compounding effects are bigger. Relitigation drops, because “we chose annual-only in March, here’s the reasoning, has anything changed?” is a five-second lookup instead of a forty-minute meeting, and the recorded rejection of the alternatives pre-answers most reopenings. Onboarding sharpens, because a new hire reading the last year of decisions with rationale is the closest thing to downloading institutional judgement that exists. Decision quality itself tends to rise once people know reasoning gets recorded: “because I said so” reads worse in a log than it sounds in a meeting.

There is also a weekly dividend: a Friday review flow can compile the week’s decisions into a digest automatically, so leadership sees the decision velocity of the company, what got settled this week and by whom, without anyone writing a report. The same entries feed pre-meeting briefs (decisions pending with the people in the room) and account histories (decisions affecting a client appear alongside their calls). One capture, read everywhere.

Failure modes, and the fixes

The log fills with noise. The filter is too loose, usually because the sweep is treating strong opinions as decisions. Tighten the prompt’s definition (“a real change of course with a stated reason”) and let the review queue teach it: consistent discards are the signal.

The log misses the big ones. Big decisions often happen in meetings, not chat. If your log looks thin next to how the company actually feels, the missing piece is almost always the transcript pipeline, not the chat sweep.

Entries lack rationale. Sometimes the team genuinely did not state a why. The flow records what exists; a rationale-free entry in the queue is a useful prompt to ask “wait, why did we decide this?” while everyone still remembers. The log improves the conversation, not just the record.

Build this yourself

• A connected chat source (Slack or Telegram in most installs), so the sweep has the day’s conversation to read.
• The two flows above, sweep plus catch, with your team’s decision dialect in the keyword list.
• The transcript pipeline, so spoken decisions are captured too. This is the difference between a log and half a log.
• The one-minute review habit, assigned to a named person, not “the team.”

The discipline this replaces is one nobody sustains by hand. The discipline it requires, confirming a short list each evening, is one anyone can.

This is the kind of workflow we install during a transformation: wired to your actual chat and call tools, tuned on your team’s real conversation style, and running on an engine you own. It starts with a $1,500 assessment of where your decisions currently evaporate.