USE CASES
Where causal memory earns its place
Any agent that makes decisions and later learns what happened has something worth recording. These three have the shortest path from a recorded edge to a different next action.
Updated · English
One loop, three domains
The interface does not change between domains. A decision, the context it was made in, the outcome that followed, and the relation between them. What changes is which outcome is valuable: a coding agent needs the rejected alternative, an on-call agent needs the mitigation that prevented a worse outage, and a research agent needs the counterfactual it can compare against later.
That is why the pages below are not templates with the nouns swapped. Each one names a different failure mode of text-only memory, and a different metric that should move if the causal record is working.
The three use cases
- Coding agentCausal memory for a coding agentA coding agent already remembers the diff. Causal memory makes it remember why the diff was wrong the first time.
- On-call agentCausal memory for an on-call agentAn incident timeline records what happened. Causal memory records which mitigation actually prevented the worse outcome — and which one only looked like it did.
- Trading agentCausal memory for a trading research agentA P&L number tells you what happened. A causal decision journal tells you which part of your reasoning was wrong — and what you would have gotten if you had done the other thing.
The same three fields, filled in differently
These are illustrative payloads, not customer results. The point is the shape: a decision that can be compared later only exists if the context and the relation are recorded with it.
| Field | Coding agent | On-call agent | Trading agent |
|---|---|---|---|
| decision | Replaced the unbounded retry loop with a bounded queue | Rolled back the checkout service during the latency spike | Cut gross exposure before the scheduled macro release |
| context | Go 1.22, four workers, replaying the ingest backlog | Peak traffic, primary at its connection ceiling | Event week, elevated implied vol, thin liquidity |
| outcome | Replay stopped dropping events; retries no longer amplified load | Error budget stopped draining; the database stayed below its ceiling | Realised volatility stayed below the level the position was sized for |
| relation | caused | prevented | caused |
How to choose your first use case
Start where a wrong decision is expensive and the lesson is currently lost. That is usually incident response or a migration, not a greenfield feature: the decision is explicit, the outcome is observable within hours, and the failure repeats if nobody writes it down.
Avoid starting with a domain where the outcome takes months to observe. An edge with no outcome is not a causal memory yet; it is a note. The trading workflow works because the review horizon is explicit, not because the domain is easier.
- Start with one task_tag and record every decision in it for two weeks before judging recall quality.
- Record the rejected alternative at decision time; inventing it during review is hindsight bias.
- Pick a metric that can move in a quarter — repeat incidents, reverted retries, re-argued architecture — not a revenue number.
- Read the comparison pages if you are deciding whether to add causal memory at all, and the CausalEval page before trusting any number.
What the benchmark supports
The capabilities these use cases depend on are exactly the ones CausalEval measures: intervention prediction (75% vs 40%), inhibition (80% vs 50%), counterfactual choice (95% vs 80%) and belief revision (100% vs 80%). Fact recall is not on that list, because none of these workflows becomes better at remembering a preference. Source: causal-memory README v0.10.0 · CausalEval v13, read 2026-10-21.
See the protocol, the per-capability table and the C6 limitation →
Related
Pick the decision you make most often
Record it once, add the outcome when you know it, and ask for it back before the next one. The use case pages are the same loop with different nouns.