I recently had to continue a long-running body of agent work whose records told two plausible stories. One was neater; one was newer. The durable choices had survived in both, while the surface details had moved. Choosing by recency would have mistaken motion for meaning.
The useful question was not “Which record is latest?” It was “Which decisions are still supported, and what would make us revisit them?” That is the job of a decision ledger.
§1Agent memory compresses reasons first
Long-running work accumulates instructions: prefer this source, avoid that pattern, route this kind of task to one owner, stop when a boundary is crossed. Over time, the conclusion is copied forward while the observation that produced it falls away.
That creates two opposite failures. An agent may obey an obsolete rule because it looks permanent, or discard a sound rule because its reason is invisible. A ledger keeps enough causality to avoid both.
Record a decision as a supported claim, not a commandment: what to do, why it made sense, what later evidence says, and when to review it.
§2Use a ledger, not a diary
A diary records what happened in sequence. A decision ledger records only the choices that future work may inherit. It is selective by design.
Add an entry when a choice changes how later work should be done, resolves a recurring ambiguity, protects an important boundary, or reverses an earlier rule. Skip routine activity, temporary preferences, and facts already owned by a better source.
§3Give every rule a lifecycle
A decision becomes safer when its state is visible. The lifecycle below turns an observation into a provisional rule, then keeps it open to later evidence.
Decision lifecycle
- 01 · noticeObservationName the repeated tension or constraint.
- 02 · boundProvisional ruleChoose the smallest rule that fits.
- 03 · appendEvidenceAdd confirming and conflicting signals.
- 04 · triggerReviewReopen it when a named condition occurs.
- 05 · judgeCompareWeigh the rule against current evidence.
- 06 · outcomeKeep, revise, or retireRecord the result and link any successor.
§4Keep the entry compact
The ledger should be quicker to consult than the history it summarizes. Five fields are enough for most decisions.
| Field | Question it answers | Good form |
|---|---|---|
| Rule | What should future work do? | One scoped, actionable sentence. |
| Why | What observation made this sensible? | The causal reason, not the whole story. |
| Evidence | What later facts support or challenge it? | Dated additions that preserve disagreement. |
| Revisit | What event makes review necessary? | An observable trigger, not “review later.” |
| Status | Is it provisional, active, revised, or retired? | One state plus a link to any successor. |
copy-usable decision entry
DECISION D-014 · YYYY-MM-DD
STATUS
Provisional | Active | Revised | Retired
RULE
Future write tasks have one explicit owner.
WHY
Overlapping ownership made the intended final state ambiguous.
EVIDENCE
- YYYY-MM-DD — Later assignments stayed independent.
- YYYY-MM-DD — A shared surface still needed one coordinator.
REVISIT WHEN
Shared editing can preserve ownership and intent reliably.
SUPERSEDES / REPLACED BY
None§5Append evidence; do not rewrite the past
When new evidence arrives, add it to the entry before changing the rule. Silent edits produce a clean document and a dishonest history. Appended evidence shows whether the decision was confirmed, narrowed, contradicted, or simply overtaken by a new constraint.
Keep evidence short and decision-relevant. A link or dated note is useful only when it changes confidence, scope, or timing. The ledger is not an archive of everything the team has seen.
§6Prefer triggers to calendar reminders
“Review quarterly” is easy to schedule and easy to perform mechanically. A revisit trigger names the condition that could make the rule wrong: the source of truth changes, a protected boundary disappears, the same exception recurs, a new capability removes the original constraint, or conflicting evidence reaches the same weight as the initial case.
A calendar can still surface dormant decisions, but the trigger tells the reviewer what to look for.
§7Make the outcome explicit
- Keep when the reason still holds and later evidence supports the same scope.
- Revise when the principle survives but its wording, boundary, or owner changes.
- Retire when the original constraint is gone or the rule now creates more risk than it removes.
Never erase a revised or retired entry. Mark its status, state the reason, and point to the successor. The old rule may still appear in an agent’s context; a visible retirement gives that agent a way to reject it safely.
§8Watch for ledgers that become policy theatre
- Conclusion only: the entry repeats the rule but preserves no cause.
- Evidence as decoration: links accumulate without changing confidence or scope.
- No trigger: “active” quietly becomes “permanent.”
- History rewritten: the current wording hides earlier assumptions and reversals.
- Everything logged: important decisions disappear inside routine activity.
- No successor link: two valid-looking rules compete in future context.
§9Start with the rules that already cause hesitation
- List the instructions that a new agent would be tempted to question.
- For each one, write the smallest reason that still explains the choice.
- Add the strongest confirming or conflicting evidence you already have.
- Name one observable event that would force a review.
- Mark the current status and link any rule it replaced.
You do not need a complete institutional memory. You need a small set of decisions that can explain themselves when the original conversation is gone.
Steal this
- Treat every inherited rule as a supported claim.
- Keep the rule, reason, evidence, trigger, and status together.
- Append later evidence before changing the conclusion.
- Use observable revisit triggers instead of vague reminders.
- Keep, revise, or retire explicitly—and link every successor.
- Log only decisions that future work may inherit.