Make Multi-Agent Handoffs Resumable with a Commitment Envelope
A multi-agent workflow should not hand the next worker a paragraph of context and hope it can reconstruct what matters. A small commitment envelope can carry the task’s current state, proof requirements, and safe next action without turning every handoff into a full replay of the conversation.
This article explains one concrete DAL improvement end to end: a structured handoff envelope for passing bounded work between agents. You will see the problem it solves, the fields it needs, how a receiving agent should use it, and when the pattern is worth the extra structure.
The problem: context transfer is not state transfer
Imagine a workflow with a researcher, an editor, and a publisher. The researcher finds material and asks the editor to shape it. The editor prepares a draft and asks the publisher to place it in the approved destination. Each agent may be competent in isolation, yet the workflow can still fail at the seams.
A prose handoff such as “the research is ready; please finish the article” hides several decisions:
- Which claims are supported, and where is the evidence?
- Is the draft complete, or is the next agent expected to research more?
- What file or response is the authoritative output?
- Is publishing authorized, or is review still required?
- What should happen if the next step cannot be verified?
These questions become more important when the workflow is bounded. Recent operator records distinguish completed work from proof-misses, and safe policy holds from ordinary failures. A handoff that carries only a narrative makes the receiving agent repeat discovery and may cause it to mistake an unfinished result for a completed one.
The improvement is not “give every agent more memory.” It is to pass a compact, inspectable state object alongside the human-readable context.
The mechanism: a commitment envelope
A commitment envelope is a structured handoff record with a stable identity and an explicit completion contract. In DAL terms, it can be represented as a map or serialized JSON document. The exact syntax can follow the host application’s conventions; the important part is the semantics.
``text handoff { id: "article-2026-10-16-research-v1" from: "researcher" to: "editor" status: "ready_for_editing" objective: "Turn the verified findings into one feature deep-dive" inputs: [ "COO-FILESYSTEM/work_logs/autonomy_digest_20261012.md" ] required_output: "COO-FILESYSTEM/articles/drafts/<new-slug>.md" evidence: [ "operator scoreboard distinguishes proof-miss from policy hold" ] constraints: [ "do not claim a shipped feature without runtime evidence", "preserve the draft-only boundary" ] next_action: "write and verify the markdown draft" external_effects: "none" approval: "not_required_for_draft" verify: ["file_exists", "required_sections_present"] } ``
The envelope has four useful layers. Identity tells the receiver which handoff it is processing and who produced it. State describes what is ready now, rather than what the entire workflow hopes to accomplish. Contract fields define the required output and checks. Policy fields make external effects and approval status explicit.
The natural-language summary still matters. It explains the intent and gives the receiving agent useful color. But the envelope becomes the control surface for execution. If the summary says “ready to publish” while the envelope says external_effects: none, the receiver should preserve the safer boundary and ask for a new authorized step rather than infer permission.
Receiving the envelope: validate before acting
The receiving agent should treat a handoff as an input contract, not an instruction to blindly continue. A practical processing sequence has five stages.
First, validate identity and routing. The receiver checks that the envelope is addressed to its role and that the handoff identifier has not already been consumed. This prevents a retry from duplicating work.
Second, inspect the state. ready_for_editing is different from needs_research, awaiting_review, and completed. A completed handoff should normally be verified or archived, not processed as fresh work. An awaiting-review handoff should not be advanced merely because the next agent can technically perform the action.
Third, load only the declared inputs. The envelope should point to files, records, or tool results that can be inspected. This gives the next agent a recovery path: if the conversation is unavailable, the work can still be reconstructed from the durable inputs.
Fourth, perform the next action within its constraints. Optional improvements—extra research, stylistic polish, or broader distribution—come after the required output and verification. They must not silently expand the scope.
Finally, emit a successor envelope. The result should state what changed, where it lives, which checks passed, and what remains. A handoff is therefore a chain of small receipts rather than a chain of optimistic messages.
Failure paths are part of the feature
A useful envelope makes failure legible. If the editor cannot find the declared research file, it should return blocked_missing_input with the missing path. If the draft exists but the required sections are absent, it should return verification_failed and identify the failed check. If the next step would publish externally but approval is absent, it should return held_for_approval rather than attempt the publish.
These distinctions matter operationally. A system that reports every interruption as “agent failed” encourages unnecessary retries. A system that reports every output as “complete” creates proof-misses. The handoff protocol should preserve the difference between:
- completed: required output exists and checks passed;
- blocked: a declared input or dependency is unavailable;
- verification_failed: an output was produced but does not satisfy its contract;
- held_for_approval: the next action is externally visible or otherwise gated;
- safe_stop: continuing would exceed the declared budget or violate a constraint.
The receiving agent can then choose a bounded recovery: request the missing input, repair the artifact, wait for review, or close the chain without an external effect.
When to use it—and when not to
Commitment envelopes are most valuable when work crosses agent boundaries, survives a pause, or can create an external effect. Use one for research-to-writing, drafting-to-review, review-to-publishing, and any workflow where a retry must not duplicate an action. They are also useful when an operator needs to inspect a queue without reopening every conversation.
Do not impose the full structure on a trivial one-step transformation. If one agent reads a local value and returns a local calculation, a normal function result may be clearer. The envelope earns its cost when ambiguity at the boundary is more expensive than a few extra fields.
Start small. Require an identifier, status, objective, inputs, required output, constraints, next action, and verification checks. Add evidence references when claims need support. Add approval and external-effect fields when the workflow can send, publish, delete, or otherwise change the world.
Conclusion: hand off commitments, not just context
Multi-agent reliability improves when the next agent receives a truthful account of what is ready, what is required, and what remains unauthorized. A commitment envelope turns that account into a durable contract: validate it, act within it, verify the result, and emit the next state.
The practical next steps are straightforward. Define the envelope schema for one workflow, add idempotent handoff identifiers, classify blocked and gated outcomes separately, and test both successful and interrupted chains. Keep the draft-only path non-destructive until approval is explicit. Once the boundary is clear, additional agents can join the workflow without forcing every worker to rediscover the whole story.