Skip to main content
This page runs a real handoff. The sender records the delegation boundary and current state. The receiver inspects an exact . The result links back to that transfer. Handoff does not need a generation model here. The caller supplies typed data already inspected, so the minimum Server is enough. A real handoff: Work Contract, prepare, commit, acknowledge exactly, then record a Task Outcome.
Work Contract fields and Handoff APIs follow the latest published official docs. This page helps you finish one handoff and see which step writes a Source.

What the loop looks like

The Work Contract, Handoff boundary, acknowledgement receipt, and Task Outcome each leave a Source receipt. A committed Handoff also has an immutable Artifact Revision. Preparing writes a boundary Source, so it is not a read-only preview.

Complete Python example

Create handoff_loop.py:
Run it:
The example uses model_validate for nested requests because the JSON contract names the field schema, while generated Python models expose an internal alias.

Boundaries at each step

Work Contract is a delegation baseline

It records the objective, in-scope work, exclusions, completion criteria, authorization notes, and consequential questions. The Contract is an untrusted_input Source and grants no new authority. A claim with basis="verified" needs exact evidence; a declared claim carries none.

handoff_current_work writes a boundary Source

It returns:
Pass prepared_work.handoff, not the whole response, to commit or continue. This operation creates no Handoff Revision, but it does persist the boundary Source. It is not a read-only preview.

Temporary transfer needs no commit

The example first uses continue_handoff(selection="prepared"). A temporary transfer works and has selected_revision=None. Call commit_handoff only when the work needs a durable milestone.

latest discovers; exact acknowledges

Latest returns the current head in both selected_revision and current_revision. After inspection, bind acknowledgement to that exact Revision. acknowledge_handoff does not accept selection="latest".

Accepted has hard requirements

All three checks must be confirmed, and all evidence must be available:
When a check cannot be confirmed, use needs_clarification or declined with a message. Acknowledgement records receiver judgment. It grants no permission. Use:
as handoff_receipt_ref. Only an accepted receipt with exact selection and a selected committed Revision can cover a durable Handoff. A prepared acknowledgement receipt cannot establish that link.

Outcome and check states

Overall TaskOutcome.status accepts:
Individual TaskCheck.status accepts:
One passed check does not make the overall result succeeded. A check that never ran should not be reported as passed.

Negative experiments

Read latest without commit

Before commit, continue_handoff(selection="latest") returns status="empty". The Prepared Handoff still works with selection="prepared".

Accept with authorization unchecked

Change authorization to not_checked. The operation rejects accepted status. Use needs_clarification and state what is missing. Acknowledge prepared, then use that receipt as handoff_receipt_ref. The Server rejects it because the receipt is not bound to an exact committed Revision.

Prepare twice from one base

Prepare two Handoffs, commit the first, then commit the second. The second returns a Revision conflict. Read the new head and prepare again rather than guessing a revision.

Boundary succeeds and commit fails

The boundary Source remains, but no new Handoff Revision exists. Report both facts. Do not say that nothing was written or that the milestone was saved.

How you know it worked

  • The Work Contract receipt is saved.
  • Prepared Handoff can continue temporarily.
  • Commit returns an exact Handoff Revision.
  • After you find the latest version, acknowledgement binds to that exact Revision.
  • Before accept, you check evidence, live state, capability, and authorization.
  • Task Outcome links the acknowledgement receipt SourceRef.
  • Overall outcome and individual check statuses stay separate.
If this does not match, start with Troubleshooting.
If PowerContext fails while automatically fetching context, keep working. If you explicitly write a Memory, commit a Handoff, approve a proposal, or export a Skill, you must see the failure. Read fail-open for the full rule.

Next step

Experience, Skill, and Review

A Candidate enters Review first. An approved Skill still needs an explicit export.

If you are stuck

You asked for a preview, then called Handoff. Start there.