Handoffs
Choose when to delegate independent work and define handoffs, shared-state rules and evaluation.
THE IDEA
Handoffs
A handoff is how one worker passes work to another. Include the artifacts, the evidence, the assumptions, the unresolved issues and the completion status. If each hop just forwards a summary without evidence, mistakes compound: in a toy model where each hop keeps a claim right with probability 0.9, three hops leave 0.729 and five leave about 0.59.
| hops | 0 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|---|
| still correct | 1 | 0.9 | 0.81 | 0.729 | 0.656 | 0.59 |
Predict first. Should the receiver treat another worker's confident claim as verified evidence?
Chapter context
Delegation can divide a task into focused work units, but coordination creates costs and new failure paths. Add helpers when their independent contributions can be integrated and checked more clearly than one agent can do the work alone.
TRY IT YOURSELF
Part 1. Do it hands-on
Compute how errors compound by hand, then write a handoff validator.
| hops | 0 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|---|
| still correct | 1 | 0.9 | 0.81 | 0.729 | 0.656 | 0.59 |
- To do: A good handoff carries artifacts, evidence, assumptions, unresolved issues and completion status. How many fields is that?
- To do: Toy model: each ungrounded hand-off keeps a claim correct with probability 0.9. After 3 hops (3 decimals)?
- To do: After 5 hops (3 decimals)?
- To do: Should the receiver treat another worker's confident claim as verified evidence? Type yes or no
Part 2. Do it in code
- REQUIRED = ["artifacts", "evidence", "assumptions", "unresolved", "status"] (PROVIDED).
- handoff_problems(h): "missing:<field>" for each required field absent from the dict h (in REQUIRED order); "status_invalid" if status is present and not one of done, partial, blocked.
- ungrounded_claims(h): h['claims'] is a list of {"text", "evidence"}; return the texts of claims whose evidence list is empty or missing.
- verified_claims(h): the texts of claims that DO carry evidence (still to be checked by the receiver, but not just asserted).
- survival(p, hops): the probability a claim is still correct after `hops` ungrounded forwards when each hop keeps it correct with probability p (p ** hops). ValueError for p outside [0, 1] or negative hops.
- should_reverify(h): True if the handoff has any ungrounded claim OR its status is not done (the threshold argument is unused and may be ignored).
Stuck, or something not working? You can come back to it any time.
CHECK YOUR UNDERSTANDING
Should the receiver treat another worker's confident claim as verified evidence?
Chapter reference: math, worked example & code
This section belongs to the whole chapter, so it is the same on every lesson in it and may cover a different lesson's topic. The code for the experiment you just ran is inside the experiment itself.
Math and notation
With independent parallel task durations and merge time m, an ideal lower-bound schedule is , excluding orchestration overhead. If independent tasks each succeed with probability p, all n succeed with probability ; correlated failures invalidate that simple model.
Worked example
Three tasks take 2,5 and 3 minutes; integration takes 1. Ideal sequential duration is 11 minutes, while fully independent parallel duration is 6. Separately, three independent 90%-reliable components all succeed with probability 0.9^3=0.729. The latency gain does not itself establish a reliability gain.
Reference code
The following example uses the Python standard library and does not call a remote service.
from math import isclose
times,merge=[2,5,3],1
assert sum(times)+merge == 11
assert max(times)+merge == 6
assert isclose(.9**3,.729)
Python examples are provided for study and local execution; this page does not execute Python.
Common mistakes
Parallel workers need explicit ownership of shared artifacts. Agreement can reflect correlated failure. More agents can increase token usage and integration work even when wall-clock time falls.