# First agent design: recover before repeating the work

LockedIn Labs · Edition 2026-10-30.1 · Separate 45-minute foundation exercise

Use a disposable local folder and fictional records only. This worksheet uses
the existing [outbox replay companion](/templates/fde-outbox-replay.py), Python
3.11+ and its standard library. The original four cases use temporary SQLite
files and owned child processes; they need no package, model, account or network.
The optional HTTP mode is a separate exercise and is not needed here.

The file creates and removes its own databases. Keep the program, your output
files and this worksheet. These are synthetic destination rows, not maintenance
tickets or real dispatch. Missing execution stays unexecuted; a supplied example
does not become your personal run. Allow extra time for setup and support.

## 1. Design the bounded task — 10 minutes

Imagine a maintenance assistant that reads an equipment report, drafts a service
ticket, obtains a person's review and dispatches only under separate authority.
The platform starter itself only reads and drafts. No dispatch is enabled here.

Define the five terms before drawing the workflow:

| Term | Meaning to preserve | Your example |
| --- | --- | --- |
| Proposal | Text or arguments suggesting the next operation | |
| Admission | The application checks the operation and current authority | |
| Intent | A retained record of the work the caller means to deliver | |
| Effect | A committed change at the destination | |
| Acknowledgment | Returned evidence describing a result | |

Write the input, acceptable output, allowed actions and stop conditions. Mark
which steps are already known and which would actually need a model to choose
the next investigation. A fixed sequence is useful when the dependencies are
known. More agents cannot supply missing authorization or a lost receipt.

My workflow / where a model decision would add value:
Application admission / review boundary:
Stop condition / receiving operator:
Original contribution / prior reading / help:

## 2. Predict and run two different recoveries — 15 minutes

Download `fde-outbox-replay.py` from the free action-recovery guide. Keep its
original filename. In that folder, run:

```sh
python3 --version
python3 fde-outbox-replay.py --case naive > naive.json
python3 fde-outbox-replay.py --case guarded > guarded.json
```

Before reading each output, predict the caller's state and the destination effect
count separately. These cases start fresh; `guarded` does not continue `naive`.
The learning command exits 0 after orchestrating an expected child exit 23.
Read `interrupted_delivery`, then `caller_after_crash`, then the separately named
`destination_observer_after_crash`. Identify who can observe each fact.

| Observation | My prediction | My actual field/value / unexecuted |
| --- | --- | --- |
| Naive: caller after child exit | | |
| Naive: independent observer after child exit | | |
| Naive: caller after replay | | |
| Naive: independent observer after replay | | |
| Guarded: caller after child exit | | |
| Guarded: replay status and receipt | | |
| Guarded: independent observer after replay | | |

The independent observer can inspect the destination database. Its effect count
is explicitly unavailable to the caller at the crash boundary. Do not copy it
into the caller's knowledge as if an acknowledgment had arrived.

Compare after your prediction: both cases initially leave the caller
pending/unknown with a null receipt, while the independent observer sees one
effect. Naive replay returns a second result and leaves two effects; the caller
can be confirmed without the operation being unique. Guarded replay returns the
earlier bound receipt and retains one effect. Locate these facts in your actual
output rather than treating this paragraph as an execution record.

Find the caller's intent/outbox commit, the destination commit and the deliberate
child exit in the source. They are two separate transactions. The destination's
guarded effect and replay receipt commit together. This selected local crash
does not test host loss, cloud storage, real authorization or remote cancellation.

My exact file / revision / commands / runtime:
Where the two commits and child exit occur:
Why confirmed does not prove exactly one effect:

## 3. Challenge the work identity — 10 minutes

```sh
python3 fde-outbox-replay.py --case changed-payload > changed.json
python3 fde-outbox-replay.py --case scoped-key > scoped.json
```

Keep the original caller intent. In `changed-payload`, inspect the conflict and
pending original work. In `scoped-key`, another fixed fixture scope denotes
separate work: its returned result cannot acknowledge the original operation.
Find the receipt/intent comparison. The same printed key does not identify the
same work in every scope, and these supplied scope strings do not authenticate
anyone. A real server must establish identity and current access separately.

Case / my prediction / actual replay or mismatch:
Caller original state afterwards:
Useful permitted behavior retained:
My explanation / assistance / unanswered question:

## 4. Receive the comparison and change one assumption — 10 minutes

Assign caller owner, destination owner and receiving engineer. Each keeps their
own record. Ask the receiver to run `naive` and `guarded` and locate the caller
unknown and final destination counts without the author navigating. Record
their exact command, evidence located, explanation, hints and any takeover.
Solo work is self-review; a pod answer cannot replace an individual's evidence.

Now return to the crash boundary **before a matching acknowledgment arrived**.
On paper, remove the retained replay receipt or make authoritative lookup
unavailable. This is a changed-contract reasoning task; the local program has
not run that condition. Do not erase a previously confirmed result in its own
record, or claim the expired/unavailable lookup proves zero effects.

Write a recovery note naming the original operation and accepted payload, what
remains unknown, the action that must pause, the authorized receiving owner and
the evidence that could close the uncertainty. A new key and a requested date
do not resolve the missing outcome. Retrieving a result does not authorize a new
effect or a correction. Keep current read permission and correction authority
separate. The delivery lead should make the unresolved dependency and scope/date
options visible rather than silently promise completion.

Receiver's own command / source comparison / actual explanation:
Help / author takeover / missing run:
Changed-contract note — clearly separate from executed evidence:
Destination owner / lookup evidence required:
Caller owner / safe visible state while waiting:
Delivery lead / useful scope or date option:
Unresolved production contract and next check:

Continue with **AI architecture foundations → Agent design: recover before
repeating the work** in the Academy under existing training access, or the
[free action-recovery packet](/training/guides/action-recovery). Completing this
exercise establishes neither independent delivery nor client placement or
qualification; retain what was actually observed and the help that was needed.