What Is the Signed Handoff Context? The Beginner's Guide to Signed Agent-to-Agent Handoffs

CodexFuse Team · 2026-11-05T05:46:41.196Z · 23 min read min read

What Is the Signed Handoff Context? The Beginner's Guide to Signed Agent-to-Agent Handoffs

What Is the Signed Handoff Context?

The signed handoff context is a small, signed packet that travels with work when one AI agent hands a task to another, so the receiving agent can check who handed it over, on whose behalf, through which earlier agents, and which prior context the work depends on. If you searched for what is signed handoff context, here is the short version: it is a signed offer, a signed status reply, and the chain of earlier offers that led to the current one, defined so a dropped or reordered intermediate hop can be detected when the chain is carried.

This is signed handoff context explained from the proposal itself. The proposal is Internet-Draft draft-srivastava-agentproto-handoff-context, revision -01, dated 2 November 2026, by Kumar Srivastava of Quantum Learning Machines. It is a work in progress, not an adopted standard, and it expires on 6 May 2027 unless a newer version replaces it.

Its intended status is Informational, and it is offered as input to the IETF agentproto working group's use cases and dialog-context work.

The problem is easy to state. A planner agent asks a coding agent to write a patch, and the coding agent asks a test agent to run it. At each hop, the receiving agent needs to know whether the work is fresh, whether it is meant for it, and whether the delegation chain behind it is intact.

An authorization credential alone does not answer those questions, because it says what an agent may do, not which dialog this handoff belongs to or what answer came back.

The draft's answer is deliberately small. The element is signed by the agents themselves at each hop, and it is small enough to travel beside whatever credential the host protocol already carries. A SHA-256 hash generator shows the smallest piece of the same idea: one input, one deterministic digest, and no room for formatting to change the answer.

Teams building multi-agent systems usually run their agents on infrastructure like VPS hosting, which is the kind of box these delegators and delegates commonly run on.

This guide covers the offer, the status reply, the hash-chained history, the checks a delegate runs before accepting, and the honest limits of the proposal. It also names, plainly, what the draft does not yet define.

How Does a Signed Handoff Work, Step by Step?

A signed handoff works as an offer-and-answer exchange: the delegator signs an offer, the delegate checks it in a fixed order, and the delegate signs a status reply that says accepted, rejected, completed, failed, or canceled. The accept-or-reject arc runs in five steps.

1. The delegator signs an offer naming itself, the intended delegate, the dialog, and an expiry window, and sends it inside the host protocol's own message.
2. The delegate verifies the signature against a key its own trust configuration binds to the sender, and rejects the offer if the signature is bad or the key is untrusted.
3. The delegate checks audience, freshness, replay, dialog, chain, and prior-context references in order, stopping at the first failure.
4. If every check passes and the delegate takes the work, it signs and sends an "accepted" status reply naming the offer by its digest.
5. When the work ends, the delegate signs a "completed" or "failed" status, and a delegator that cancels signs a "canceled" status that follows the chain downward.

Two rules shape the whole exchange. First, an unsigned offer or status must be treated as absent, not as a weaker form of evidence. Second, a missing status is never treated as failure: the delegator asks again, and the hop stays unresolved until a verified status or an authoritative observation settles it.

What Is Inside a Handoff Offer?

A handoff offer is a versioned, signed record with the fields a receiver needs to decide, not a free-form message. Its core members are the version (v: 1), the type ("offer"), a hop identifier, a dialog identifier, the sender (iss), the intended receiver (aud), an issue time (iat), and an expiry time (exp). Optional members add a host-protocol task identifier, the principal on whose behalf the chain's root acted (obo), a digest of the authorization credential the delegate is expected to present (grant), the digest of the previous offer (prev), and references to prior context (refs).

The hop identifier does double duty as the replay nonce. It must carry at least 128 bits from a cryptographically secure random source, encoded in base64url without padding, and it matches the pattern of 22 to 64 such characters in the draft's definition. The draft's own example uses hop "q3Zl0v8bVfQmJm2c4bq1Ww" for a planner-to-coder handoff in dialog "ctx-7c1e" for task "task-42".

That example offer runs from iat 1793000000 to exp 1793000120, a 120-second acceptance window, which sits inside the draft's recommended 300-second maximum lifetime for interactive use.

The sender and receiver identifiers are strings, recommended to be URIs, that the receiver's trust configuration maps to keys. The draft's example uses workload-style identifiers such as "spiffe://a.example/agent/planner" for the delegator and "spiffe://b.example/agent/coder" for the delegate. An offer copied to another agent fails the audience check, because aud must equal the receiver's own identifier.

The grant member deserves a careful reading. It holds only the digest of a credential, computed over the credential's octets exactly as presented, and it must never contain the credential itself. That is what lets a delegator bind a hop to one credential without leaking the credential into the handoff element.

The obo member works the same careful way: it names the principal the chain's root acted for, but it is not an authorization claim, and a receiver must not make an access-control decision from obo or from the chain alone.

What Does the Signed Handoff Offer Status Reply Say?

A signed handoff offer status reply is the delegate's signed answer to one specific offer, and it always names that offer by its digest. Its members are the version, the type ("status"), the hop identifier, the offer digest, the sender and receiver, an issue time, and a state. The five states are "accepted", "rejected", "completed", "failed", and "canceled", with an optional reason and free-text detail on rejections and failures.

The reason vocabulary is fixed for the common failures, and it reads like a diagnostic list. It includes "bad-signature", "untrusted-key", "wrong-audience", "stale", "replay", "equivocation", "broken-chain", "cycle", "too-deep", "unverifiable-ref", "ref-mismatch", and "policy". Detail is free text for people, and the draft states plainly that software must not rely on it.

That split matters: machines decide on the state and reason, while humans read the detail.

Sender and receiver swap with the state. For every state except "canceled", the sender is the delegate and the receiver is the delegator. For "canceled", the sender is the delegator, because cancellation is the delegator revoking the hop.

A delegate that receives a valid "canceled" should send "canceled" for each offer it issued whose prev equals this hop's offer digest, so the cancellation follows the hops downward.

One subtle rule protects delegates that have forgotten a hop. A "rejected" status with reason "stale" or "replay" is not terminal and never sets the hop's state. It says only that the delegate does not remember the offer, and a verified status that arrives later still counts.

A delegate must send at most one of "accepted" and "rejected" per hop, and at most one of "completed" and "failed", apart from that nonterminal exception.

How Does the Handoff Chain Hash Work?

The handoff chain hash works as a linked list of digests: each offer names the one before it by hash, so removing or reordering an intermediate hop breaks the link. The digest, called the handoff digest, is the SHA-256 digest of the signed offer's octets exactly as sent. For a JSON handoff, that means the ASCII octets of the JWS Compact Serialization; for a CBOR handoff, the encoded tagged COSE_Sign1 message.

Hashing what was signed, as sent, avoids any need for canonical JSON, and a party that forwards a signed offer in a chain must forward those octets unchanged.

The chain itself travels beside the current offer, not inside it, and that placement is deliberate. Each offer already names its predecessor by digest, and each predecessor names its own, so the prev links fix the chain's membership and order without a second signature over the whole chain. Were the chain inside each signed offer, every offer would carry the chains of all its predecessors, and the size would double at each hop.

Kept outside, the chain grows by exactly one signed offer per hop.

The arithmetic of that growth is worth stating as an original worked example, computed from the draft's own rules. At hop 1, the handoff carries 1 signed offer and 0 chain elements, because the first delegator starts the chain and has no prev. At hop 2, it carries 2 signed offers: the current offer plus 1 chain element, and 1 prev link joins them.

At hop 3, it carries 3 signed offers and 2 prev links. In general, at hop k, the handoff carries k signed offers and k minus 1 prev links. At the draft's recommended maximum chain length of 16, a handoff therefore carries at most 16 signed offers and 15 prev links, which is why receivers must bound chain length and element size.

The draft's worked example shows the same pattern at small scale. An assistant hands a task to a planner, and the planner hands part of it to a coder. The planner's handoff to the coder holds the planner's signed offer plus a chain of one element: the assistant's signed offer to the planner.

The planner's prev is the handoff digest of that chain element, computed as SHA-256 over its 538 ASCII octets. The coder accepts and replies with a status whose offer member is the handoff digest of the planner's signed offer, computed over its 942 ASCII octets.

A chain also has a privacy cost that the draft names openly. The chain reveals every prior agent to every later hop, and obo reveals the principal. A delegator should therefore include the chain only when the next hop needs it, and should use a pairwise or pseudonymous principal identifier where the deployment allows.

Omitting the chain trades verifiability for privacy, while prev still lets a party that already holds the earlier offer check the link.

What Checks Must a Delegate Run Before Accepting?

A delegate must run seven checks in order, and the first failure ends processing. The table below states each check, what it verifies, and the rejection reason the draft assigns.

Freshness has numbers attached, and they are recommendations, not hard limits in the draft's own words. A skew of no more than 60 seconds is recommended for clock differences. A maximum lifetime of 300 seconds is recommended for interactive use, measured as exp minus iat.

A receiver must remember each (iss, hop) pair that passed the first three checks, with its handoff digest, at least until exp plus the skew, and should keep answered hops in storage that survives a restart.

Chain checking has its own seven rules. Each chain element's signature is verified; each offer's prev must equal the handoff digest of the previous offer; each previous offer's aud must equal the next offer's iss, which is continuity; each earlier offer must have been live when the next was issued, which is timing. If the first chain element itself has a prev, the chain is partial and does not reach the start.

If any identifier appears as sender more than once, or the receiver's own identifier appears earlier in the chain, the chain contains a cycle. And the receiver must enforce a maximum chain length, with 16 recommended.

References are checked only as far as local policy requires, and the outcomes are fourfold: verified, mismatch, unverifiable, or not checked. A receiver must not report a reference as verified unless it performed the check. The reference kinds are "digest", "salted-digest", "scitt-receipt", and "learnlog-head", plus any other kind named by an absolute URI.

For a salted digest, the salt is at least 16 octets from a secure random source and is delivered with the object, never inside the element, which protects low-entropy content such as a short prompt from being reversed by hashing guesses.

How Do Handoff States Map to A2A Task States?

Handoff states map to the nearest Agent-to-Agent task states, while the host protocol keeps its own task state alongside them. The draft's mapping table is reproduced below, because it is the bridge between the handoff lifecycle and the protocol most readers will already know.

A2A states with no handoff entry, such as TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED, stay in the host protocol and do not change the hop's state. That separation is the point of the whole design: the handoff element tracks the hop, and the host protocol tracks the task. Neither replaces the other.

The lifecycle has two more rules that catch beginners out. A delegate may send "completed" or "failed" without first sending "accepted", and the delegator then treats "accepted" as implied. And an offer that reaches exp at the delegator with no status is expired there, but expiry is local and provisional: no message is sent, and a status that arrives later and passes the checks still counts and replaces "expired".

Signed Handoff vs A2A: What Is the Difference?

Signed handoff vs A2A is not a contest between two protocols, because the signed handoff context is an element that travels inside A2A, not a replacement for it. A2A provides the messages, tasks, and task states; the handoff element provides the signed offer, the signed status, and the hash-linked chain that ride inside those messages. Asking which one to choose misses the design: you use A2A as the host, and you add the handoff element when the receiver must trust the delegation chain.

The carrying rule for A2A is specific. The signed offer goes in Message.metadata under a key equal to the extension URI "https://quantumlearningmachines.com/a2a/ext/agent-handoff/v1", and that URI is listed in Message.extensions. The value is the Handoff object: the signed current offer plus its chain.

A status goes under the same key in the metadata of the Message that carries the reply, or of the status message of the returned Task. A delegator's "canceled" status goes under the same key in the metadata of its Cancel Task request.

That URI is an identifier, and nothing needs to be fetched from it. The draft notes that if the working group takes up this work, the URI would move to one the group chooses. Until then, the vendor-domain URI is the convention the draft defines, and implementers should treat it as a label, not as a web address to resolve.

The same element travels in MCP by a parallel convention. When one agent delegates through an MCP tool call, the Handoff object goes under the key "quantumlearningmachines.com/agent-handoff" in the _meta object of the request params, which MCP's base request type allows. A status goes under the same key in the CallToolResult's _meta object, and a delegator's "canceled" status goes under the same key in the _meta object of its notifications/cancelled notification.

Because a tool call gets one reply, a delegator that delegates over MCP learns of any later status for the hop by retransmitting.

The draft defines no new transport and no HTTP header. That restraint is a feature: existing protocols carry the element in their own extension points, and a future agentproto dialog context could carry it unchanged through mediators. One check does not survive translation today, because the dialog member holds the host protocol's identifier, and a mediator that maps one protocol's identifier to another's leaves the dialog check to fail unless the receiver's policy knows the mapping.

What Happens When Something Goes Wrong?

When something goes wrong, the draft's first rule is to stop guessing and ask again. A delegator that has not received a status it expects may retransmit the offer, but it must resend the identical octets, and it should wait longer after each attempt. A delegate that receives a retransmission must not process the offer again or do the work again.

If it already sent a status, it should resend the last status as the identical octets; if it has taken the work but sent none, it should send "accepted"; if it has sent none and has not yet decided, it sends nothing for now.

Equivocation is the sharper failure, and it has a precise definition. Two signed offers with the same sender and hop but different octets are equivocation, because signature algorithms such as ES256 produce different octets each time they sign. A receiver that sees the second must not accept it and must not send a status for it.

If it has neither taken the work nor answered the first, it should reject the first with reason "equivocation". If it has taken the work but sent no terminal status, it should stop the work if it can, and then report the outcome it knows, flagging the conflict to its operator.

Unknown outcomes stay unknown, and the draft is strict about that. A delegate must not send "completed" or "failed" while it does not know whether the work took effect; until it knows, the hop stays "accepted". If part of the work took effect and the rest did not, a delegate that sends "failed" must list in refs what took effect, so the delegator does not assume nothing changed.

If the record is lost and the outcome cannot be learned, the delegate must not guess: it keeps the hop "accepted" and flags it to its operator.

Cancellation has its own honest limit. A "canceled" status revokes the hop, but the element itself revokes no authority, and a cancel does not show that the work took no effect, because the delegate may have done the work before the cancel arrived. Some host protocols also suppress the reply to a canceled request, as MCP does, so a delegator that cancels over MCP may never see the delegate's last status, and the hop is then unresolved.

The draft does not resolve such races; it makes them visible to both sides.

How Does the Signed Handoff Context Relate to Envelopes, Receipts, and Audit Trails?

The signed handoff context relates to its sibling proposals by mechanism, and each sibling answers a different question. The Mitra protocol carries a signed envelope with a token budget, while the signed handoff context carries the offer and status chain at handoff time. AER-1 produces execution receipts after the fact, while the handoff context is checked before the work is accepted.

TRAIL provides cross-organization audit and live revocation records, while the handoff context is consumed at handoff time to decide whether to accept work, not kept as a record for later review.

AgentProto itself is the abstract that sits above these pieces: the working group's dialog-management direction, not a single mechanism. A-SIP covers session-initiation dialogs, which is the conversation before the handoff, not the handoff itself. None of these is a rival to the signed handoff context, because none of them signs the same offer-status-chain triple for the same decision.

Treating them as competitors would be a category error; they are adjacent lanes in the same agent-protocol map.

One citing draft is worth naming precisely, because it shows the chain being reused rather than reinvented. The Agent Action Confirmation Protocol, or AACP, is a different draft that cites the signed handoff context for chain binding. When a task reached an agent through a signed handoff chain, AACP's confirmation request and confirmation evidence carry the digests of that chain, which binds the confirmation to the delegation path, not merely to the final operation.

The chain itself is carried by the handoff protocol, not by AACP, and AACP references it only by digest.

The draft also names two appendix references without making them part of the core. A SCITT receipt or a Learnlog signed head can be referenced from a handoff through the refs mechanism, with support for both kinds optional. Those appendices show how prior context can be anchored to a transparency or capture record, while the core element itself still names prior context by digest only and treats whatever stores it as opaque.

Who Should Use Signed Handoff Context, and Who Should Wait?

Teams building multi-agent handoffs where the receiver must trust the delegation chain should read this draft first, because it is the only proposal that signs the offer, the answer, and the history together. That audience includes platform teams running planner-to-coder-to-tester chains across vendors, enterprise teams whose agents cross trust boundaries, and protocol implementers working on agentproto dialog context. For them, the draft's checklists are immediately useful even before any implementation exists, because they state what a receiver must verify before it accepts work.

Builders should also take the draft's own advice about policy. A receiver that needs to know the origin must require a full chain whose first element is signed by an origin it trusts, because a delegator can omit prev and the chain and present itself as the start, and that offer is still valid. Without the chain, a receiver also cannot tell whether the delegator passed on an offer that had expired, been rejected, or been canceled.

The draft gives receivers the checks; deployments must choose how strict to be.

Everyone else should wait, and the draft gives them reasons to. There is no implementation, vendor adoption, or deployment guidance claimed in the draft, and this guide claims none either. The agent handoff context ietf discussion is still at the input-to-the-working-group stage, with open questions the draft lists itself: whether the dialog check should admit mappings across mediators, whether reason values need a registry, whether CBOR should use integer map keys, and whether cancellation propagation should be a must.

Teams that need a shipping solution today should use their host protocol's existing authentication and task tracking, and watch the draft's revisions.

Developers who build coding agents day to day will recognize the workflow shape even if the protocol is new. Learning how to use Claude Code teaches the same discipline at human scale: small, specific jobs, a plan read before action, and every change reviewed before it lands. The signed handoff context applies that discipline machine to machine, with signatures where a human would use judgment.

What Does the Signed Handoff Context Not Do?

The signed handoff context does not grant authority, and that limit is the most important sentence in this guide. Authority comes from credentials carried by the host protocol, issued under OAuth, WIMSE, or a similar framework, and the grant member only binds a hop to one such credential by digest. A valid signature shows that the holder of a trusted key signed the offer; it does not show that the signer had authority to delegate, that the referenced context is correct, or that the work was done as reported.

It also does not define an audit log, and the agentproto charter lists audit data structures as out of scope for this element. The handoff context is consumed at handoff time, to decide whether to accept work and to correlate hops, and it is not a record kept for later review. A delegate keeps some state for each hop so it can answer a delegator that asks again, but that state serves the dialog while it runs, not a later investigation.

It does not solve key distribution. The draft states plainly that it does not define how a receiver learns which keys speak for which agent, and a key carried inside the message itself, without a binding from the receiver's trust configuration, shows nothing about who signed. Workload identity credentials, certificates chaining to a configured anchor, or keys configured out of band are the examples the draft gives, and the choice belongs to the deployment's trust architecture.

Finally, it does not prove the truth of the chain's contents. A verified chain shows that each listed agent signed an offer to the next, in that order, while the earlier offer was live. It does not show that the agents were authorized, or that what they said was true.

It also does not show that an earlier offer had not been rejected or canceled when the next was issued, and the start of a chain can be dropped by omitting prev. Those gaps are why the draft pairs every mechanism with a policy decision, and why a signature should never be read as a promise.

Sources

Srivastava, K., "Signed Handoff Context for Agentic Dialogs", Internet-Draft draft-srivastava-agentproto-handoff-context-01, 2 November 2026, expires 6 May 2027. Fetched 5 November 2026. (Offer, status, chain, signing, lifecycle, checks, carrying, and limits throughout.)

Srivastava, K., "Signed Handoff Context for Agentic Dialogs", Internet-Draft draft-srivastava-agentproto-handoff-context-01, plain-text form, 2 November 2026. Fetched 5 November 2026. (Revision date, expiry, and author affiliation cross-check.)

IETF Datatracker, draft-srivastava-agentproto-handoff-context-00, October 2026, and revision history. Fetched 5 November 2026. (The -00 revision dated 26 October 2026, superseded by -01.)

Liu et al., "Agent Action Confirmation Protocol (AACP)", Internet-Draft draft-liu-agent-action-confirmation-00, November 2026. Fetched 5 November 2026. (AACP as a separate draft citing the signed handoff context for chain binding.)

Frequently Asked Questions

What is signed handoff context in one sentence?

It is a signed offer, a signed status reply, and the hash-chained history of earlier offers, defined in an IETF Internet-Draft so a receiving agent can verify a delegation chain before accepting work.

Is the signed handoff context an adopted IETF standard?

No. It is Internet-Draft draft-srivastava-agentproto-handoff-context-01, a work in progress dated 2 November 2026 that expires on 6 May 2027, offered as input to the agentproto working group. It must not be cited as a finished standard.

How is a signed handoff different from an authorization credential?

A credential says what an agent may do and within what limits, while a handoff says who handed this work over, to whom, in which dialog, through which earlier agents, and what answer came back. The handoff travels beside the credential and binds a hop to one credential by digest, but it grants no authority itself.

What happens if a middle hop is dropped from the chain?

The chain check fails, because each offer's prev must equal the handoff digest of the previous offer and each previous offer's audience must equal the next offer's sender. Dropping or reordering an intermediate hop breaks the prev link or the continuity rule, and the delegate rejects the offer with reason "broken-chain".

Can a signed handoff prove that delegated work was actually done correctly?

No. A verified chain proves signing order and consistency, not authorization, truth, or completion. Completion is claimed only by a signed "completed" status from the delegate, and the draft requires that claim to be true when sent, with the delegate keeping the hop "accepted" while the outcome is unknown.