Degraded Mode: When The Source Of Truth Is Down

What an agent should do when the system holding the authoritative data is unavailable — and what it must never do.

Prerequisites

An agent that depends on an external system of record — a CRM, a database, a task tracker. A local cache or mirror of the important parts.

If there is no cache, degraded mode has only one branch: say the source is down and stop. That is a valid design and this playbook is short for you.

Steps

1. Detect unavailability distinctly from emptiness. The two look identical in most APIs — an error and an empty result set both produce nothing useful. Check explicitly, because no records and no answer lead to opposite actions.

2. Announce the mode before the content. The first line of any degraded answer says so:

⚠ source unavailable — answering from cache, last synced 2026-08-13 09:12 (29 h)

Not a footnote. The reader decides how much to trust everything below based on this line, so it goes above.

3. Label figures by age, with a threshold that escalates. A number 2 hours old and one 3 weeks old are different kinds of claim. The working thresholds: flag over 14 days, mark [STALE] over 30, and refuse to use it as the basis for an irreversible decision at all.

4. Queue writes; never apply them blind. Changes made during an outage are recorded locally and marked pending, not written to the cache as though they were confirmed. A cache that accepts writes stops being a cache and becomes a second system of record — the failure that produces two confident answers.

5. Reconcile explicitly on recovery. When the source returns, replay queued changes, then compare rather than assume. Anything that changed on both sides during the outage is a conflict, and conflicts get surfaced, not silently resolved by timestamp.

6. Decide in advance which questions cannot be answered at all. Some things must not come from a cache under any circumstance — anything feeding an irreversible action, anything where the value of being current is the whole point of asking. List them, and have the agent refuse rather than serve stale data with a label:

cannot answer from cache: current stock before a purchase commitment, payment status, anything with a legal deadline

A refusal is a worse experience and a better outcome. The alternative is a correctly-labelled number that gets acted on anyway, because a label is a request for caution and caution is what disappears under time pressure.

Verify

Simulate it. Block the source and run 3 normal requests. The answers should be usable, visibly labelled, and none of them should have written anything.

Then check the recovery path with an induced conflict: change the same record on both sides, restore, and confirm it surfaces rather than one side quietly winning.

Troubleshooting

Degraded answers look like normal answers. The mode line is missing or too subtle. This is the whole failure — an unlabelled cached answer is worse than no answer, because it spends trust it has not earned.

The cache drifts far from the source. Sync frequency is too low for the volatility of the data, or the sync is failing silently. Check that a failed sync is distinguishable from a quiet period.

Queued writes pile up and get applied in bulk without review. Cap the queue. Past a threshold the correct behaviour is to stop accepting changes and say so, rather than accumulating a reconciliation problem nobody will read.

[Degraded Mode: When The Source Of Truth Is Down](https://stillvalid.dev/playbooks/degraded-mode) — stillvalid, SV-9686 (playbook, verified 2026-08-14)