# First agent recovery receiving session

Prepare Python 3.11+ and the [complete agent-design kit](/templates/fde-foundation-agent-design-kit.zip)
before this eighty-minute paired practice. [Preview the prepared agenda](/training/guides?starter=first-agent-receiving#guide-session-title)
before explicitly choosing whether to use it. The estimate excludes setup,
reading and breaks. Planning creates no assignment, attendance or entitlement.

Each participant keeps a separate folder with the unchanged
[outbox replay companion](/templates/fde-outbox-replay.py) and
[first agent-design worksheet](/templates/fde-agent-design-first.md).
The original cases create and remove their own temporary SQLite databases and
owned child processes. Use a disposable folder; no packages, model, account,
network or real records are required. Optional HTTP mode is separate.
Keep redirected JSON reports under new filenames rather than replacing evidence.

Each person retains predictions, exact files, commands, outputs, help and later
corrections. Supplied output is not another person's execution. Declare prior
reading, combined roles and solo self-review. Published cases are practice,
not a held-out test of unaided performance. Missing runs remain unrun.

## Minutes 0–25: separate permission, intent and effect

Follow worksheet sections 1–2. The rounds and review below replace sections 3–4.
Define proposal, admission, intent, effect and acknowledgment in a bounded
maintenance-assistant design. Identify where a fixed sequence suffices and where
a model decision would need evidence; a receipt does not grant permission to act.

Keep your own `naive` and `guarded` reports. Both leave the caller pending with
unknown outcome after a child exits following a destination commit. The
independent observer sees one effect. Naive replay later confirms the caller
while leaving two effects; guarded replay returns the earlier bound receipt
with one effect. Confirmed therefore does not establish uniqueness by itself.

Locate the two separate commits, `caller_view`, `destination_observer` and
`acknowledge` in the original source. The observer's direct database count is
not a receipt the caller already received. Temporary databases are removed
before the program finishes; keep the JSON reports and source comparison.
These local rows are not a real dispatch, model action or provider guarantee.

## Minutes 25–45: receive a changed payload without changing the original intent

A prepares the unchanged file and boundary notes; B receives. Before running,
B predicts the original caller outcome and the destination count separately:

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

This case starts fresh. A destination effect commits, then an owned child exits
23 before returning an acknowledgment. The parent learning command exits 0
after checking that interruption and the subsequent replay; a missing Python
runtime, unexpected exit or interrupted run is a different result.

The replay keeps the original scope and key but changes its note. Locate
`replay.acknowledgment`: `status: conflict` and `error: key_payload_conflict`.
The original caller stays pending/unknown with a null receipt, while the
independent destination observer still sees one effect and one receipt.
A conflict does not mean the first effect failed or disappeared.

Find the payload comparison in `receive`, the receipt checks in `acknowledge`
and the source's `durable_caller_intent_changed` assertion. The saved caller
snapshot is not the entire stored intent. Do not edit that intent to fit the
changed request or acknowledge it with a different result. B keeps their own
command, report and explanation before A discusses the evidence.

## Minutes 45–65: swap roles and receive a result from another scope

B now prepares the unchanged file and A receives. Predict the scope of the
returned receipt and whether it can acknowledge the original caller:

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

This is another independently reset case. Its redelivery changes the fixture
tenant from North to South while retaining the printed `OP-1` key and payload.
The receiver returns `status: applied` with a South receipt. The caller rejects
it with `replay.caller_acknowledgment_error: receipt_intent_mismatch` and retains
its original pending/unknown state and null receipt.

The independent observer now counts two effects and two receipts across two
scopes. Those counts do not mean the original North operation ran twice.
A valid-looking result from other work cannot close the original uncertainty.
Locate the compound scope/key lookup and the caller's scope, key and payload
comparison; the key text alone is insufficient.

These are supplied partition labels. The fixture permits its declared labels
without authenticating a caller or checking current real-world authority.
Do not report this as a cross-tenant authorization test or a real permitted
South dispatch. Each receiver retains the actual report, lookup, assistance and
correction separately from the team's final explanation.

## Minutes 65–80: return unresolved work to the receiving owners

On paper, make authoritative lookup unavailable before a matching acknowledgment
arrives. This is an **unrun contract change**, not another executed fault case.
Retain the original operation and accepted payload, keep the uncertain outcome
visible and pause an unproven repeat. A fresh key does not resolve earlier work.
Preserve previously confirmed observations in their own records.

| Receiving responsibility | Next evidence to establish |
| --- | --- |
| Application owner | Preserve original intent and bind accepted receipts to scope, operation and payload. Define the safe visible state while reconciliation is unavailable. |
| Destination owner | Establish retained effect/receipt history, supported lookup, retention and a result that can close this exact operation. An observer's local count is not that contract. |
| Identity/service owner | Verify the caller and current read, replay or correction authority. Supplied scope strings and an old receipt establish none of these. |
| Pod lead | Agree the next test, accountable role and update; show a bounded scope/date option while the dependency remains unresolved. Keep real acceptance with its owner. |

One record per person:

```text
Alias / actual role / prior reading and help:
My first prediction / exact file revision and command:
Parent exit / expected child exit / actual acknowledgment:
Original caller snapshot / separate destination observation:
Scope, key and payload binding I located in source:
Receiving action I performed / hints or author takeover:
My first explanation / later correction and its evidence:
Unrun changed-contract note / owner and evidence required:
Next agreed test / expected behavior / next update:
```

Assign actual people later. The session establishes no production recovery
guarantee, real authorization, model quality, independence, qualification or
client placement. The next useful outcome is an answerable receiving task.