A multi-agent pipeline processes large-scale data transformation tasks. Agent A (Extractor) retrieves data from an upstream source and passes control to Agent B (Transformer). In production, Agent A occasionally fails mid-run, and the pipeline must be restarted with Agent B picking up from where Agent A left off. Currently, Agent B receives only the raw output of Agent A, but when Agent A fails mid-run, Agent B does not know which records were successfully extracted and which were not. Which handoff documentation design would BEST enable Agent B to resume accurately?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Handing off 'some data' with no manifest is like a relay racer passing the baton while shouting 'I've already run some of the distance — figure out the rest.' The next runner has no idea where they are or where to start. A structured handoff document is the GPS coordinates: here is exactly what was done, what wasn't, and where to pick up.
Full explanation below image
Full Explanation
Handoff documentation is a critical pattern for multi-agent pipelines that must be resilient to partial failures. The handoff document serves as the contract between the upstream and downstream agent:
Required handoff document contents: 1. Successfully extracted records: A list of record IDs with checksums, proving the records Agent B receives are complete and unmodified 2. Failed/unattempted records: An explicit list of records that were not successfully extracted, so Agent B can flag or re-request them rather than silently producing a partial transform 3. Cursor position: The last processed position in the upstream source (e.g., last page number, last record timestamp, last offset). This is the precise resume point. 4. Status flag: COMPLETE or PARTIAL — Agent B's logic branches differently. For a COMPLETE handoff, Agent B transforms all records. For a PARTIAL handoff, Agent B transforms available records and logs a warning about missing records.
Option A (Agent A always completes before handing off) is not always feasible — upstream source failures, rate limits, or infrastructure timeouts may prevent completion regardless of retry count. Retry loops with hard failure modes do not eliminate the need for graceful partial handoffs. Option C (Agent B re-extracts everything) is correct in one scenario (small dataset, idempotent extraction) but wastes work for large datasets where Agent A successfully extracted 90% of records before failing. It also assumes re-extraction is possible, which may not be true for streaming sources. Option D (shared counter at offset) provides a resume point but not a record-level manifest — Agent B knows to start at record 1,001 but does not know which specific records 1-1,000 were extracted successfully. Records extracted out of order would produce incorrect offset semantics.