Free learning / 80-minute team practice

First agent recovery receiving session

A paired Python session: challenge a changed payload and another scope’s receipt while preserving caller uncertainty, individual evidence and receiving-owner responsibilities.

Begin reading Download a working copy

No account needed. Use your own copy for writing and keep the original as a reference.

Engineering lab library / Run locally

Choose your next agent lab.

Start with the durable workflow reference, then choose the boundary you want to test. Open its walkthrough for setup, commands and expected observations.

Synthetic records. No provider key or model inference. Runs locally with the standard library.

Start here / Python 3.11+ · Standard library
Agent recovery receiving fixture
Distinguish a payload conflict from another scope’s result without closing the original caller’s unknown outcome.
Python 3.11+ · Standard library · Temporary SQLite files and owned child processes · No model, account or network in selected cases
Open walkthrough Download file

Prepare Python 3.11+ and the complete agent-design kit before this eighty-minute paired practice. Preview the prepared agenda 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 and first agent-design worksheet. 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

← Back to lab library Download Agent recovery receiving fixture ↓

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:

Code example

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:

Code example

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 example

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.