07 · Handoffs and reviews
Chain owned work across agents; review at a different runtime than the author.
Goal
Give Codex a small documentation fix, then hand its findings to Claude Code for a read-only review, with both owned steps tracked.
You need
01–06 done; Codex and Claude Code ready. Run these commands from
the intended repository root. Choose one existing documentation file you own
and can safely edit; pause other edits to that file until review finishes.
Choose a file that actually states a license: rg -n -i 'licen[sc]e' docs README.md
can help find one. If the statement is already accurate, a reviewed no-change
result is useful; do not introduce a mistake to make the exercise produce a diff.
The idea
Both implementation and review are owned work: use ask for each, not send.
--project . --harness ... asks the broker to choose or create a worker for
this checkout without guessing an agent name. --notify returns a receipt
without waiting for completion; it does not automatically pass the first
worker's answer to the second. New sessions default to background placement.
This walkthrough uses a license-text correction, not a runtime behavior change. The commands below are instructions to run, not evidence of a completed run.
Walk it
1. Ask Codex for a one-file fix
Replace <docs-file> in both prompts below with the same existing relative
path. Use LICENSE as the source of truth; do not assume the docs are stale.
Save the actual receipt, including its flightId and any returned ref, work,
conversation, or session handles. Replace the placeholders below with receipt
values; they are not sample output.
get reads current state; wait stops on completion, failure, cancellation,
or its timeout. A timeout is not completion: inspect the same flight again,
not a duplicate ask. A routing receipt alone does not prove the edit happened.
Before proceeding, read the actual final report and inspect the file.
2. Inspect the diff and explicitly carry the findings forward
This is the checkout's diff, not necessarily changes made only by Codex. Compare
it with the implementer's named file and findings. Keep unrelated concurrent
work out of the review scope. A no-change result is valid; review the current
license statement against LICENSE rather than manufacturing a diff.
Copy the first worker's actual final output into the second prompt below,
replacing <paste implementation output here>. Include its findings, paths,
checks and blockers, plus the actual first-flight handle. Scout does not copy
that output merely because both asks share a label or project.
3. Ask Claude Code for a read-only review
If the copied report contains shell quotes or is long, instead put the complete review prompt and copied report in a UTF-8 file outside the checkout, then run this alternative (not a second review ask):
--prompt-file supplies the whole prompt body; it is not an automatic attachment
of the previous flight's result. Save the review's own receipt, then inspect it:
Read the review findings before accepting the fix. PASS is the reviewer's
judgment, not permission to commit, merge, or deploy. If either flight fails or
its final output is missing, preserve the handles and report the unresolved
state; do not claim the two-step handoff succeeded.
4. Check runtime evidence and find the related work
Read each completed flight as JSON:
When the transport records it, the runtime evidence is at
flight.metadata.dispatchAck.executionResolution; a flight may also retain
executionResolution entries in flight.metadata.sessionTrace. The plain-text
flight view does not print this block. Check both flights independently:
- Requested: the harness constraint you supplied (
codexorclaude). These examples do not pin a model or effort. - Resolved: the broker's selected launch values; source explains where each value came from. Launch arguments show intent, not harness acceptance.
- Observed: harness-owned evidence of what actually ran. Compare requested, resolved and observed per dimension, and inspect any drift.
A missing block or observed harness is unverified, even if routing selected the requested harness or a report arrived. Do not infer runtime verification from an agent name, a successful receipt, or absent drift alone. Record missing observations and mismatches separately from whether the document was changed and reviewed. A notify-mode ask returns before execution completes, so its initial receipt is not expected to prove what eventually ran.
The label groups matching flights and work items for later inspection. It does not transfer prompt context or prove completion.
How to tell it worked
- Both asks have real receipts and final reports, not just routing acknowledgements.
- The implementation output was explicitly copied into the review input.
- The selected file matches
LICENSE, or the implementer correctly reported no change needed; the reviewer independently checked it and reported findings. - Requested/resolved/observed runtime evidence is recorded, with missing observations marked unverified rather than called a confirmed cross-harness run.
- The label brief makes both owned steps findable. No commit or deployment was needed for this exercise.
Next
08 — Scout remembers: find past work without keeping notes.