m@berryhill: ~/berryhill.dev/posts/the-authority-envelope-every-agent-handoff-should-carry.md
~ homeposts/about.md
m@berryhill in ~/posts$ cat the-authority-envelope-every-agent-handoff-should-carry.md 
---
title:  The Authority Envelope Every Agent Handoff Should Carry
date:   2026-07-10
topic:  AI Agents
read:   11 min
words:  2,322
slug:   the-authority-envelope-every-agent-handoff-should-carry
views:  live post
tags:   [AI Agents, Agent Operations, Multi-Agent Systems, AI Governance]
---
essay · long read

The Authority Envelope Every Agent Handoff Should Carry

Agent handoffs do not become trustworthy because two systems can talk. They become trustworthy when every handoff carries authority, state, evidence, risk, and the next allowed action.

by matthew berryhill
·
posted 2026-07-10
·
updated 2026-07-10
·
topic AI Agents
table of contents
  1. The handoff is the risk boundary
  2. What an authority envelope carries
  3. Protocols make exchange legible. Envelopes make action auditable.
  4. A concrete envelope shape
  5. The anti-pattern: role chains without authority chains
  6. What to inspect before you trust a handoff
  7. The real bottleneck
  8. Sources

Agent handoffs fail in the space between "the protocol delivered the message" and "the next actor is allowed to act."

That gap is where most teams are still under-designing their agent stacks.

The new protocol layer matters. Model Context Protocol gives applications a standardized way to expose context, resources, prompts, and tools to models. Agent-to-agent protocols such as A2A make agent communication, capability discovery, task coordination, and information exchange more legible across systems. That is real infrastructure progress. It means the agent stack is getting plumbing instead of every integration being a bespoke wire job.

But plumbing is not permission.

A protocol can tell one system how to call another system. It does not, by itself, decide whether this agent is allowed to touch the customer record, whether the previous step was sufficiently reviewed, whether memory should persist, what evidence must travel with the work, or what human has to approve the next action.

Those are operating questions. They need an operating artifact.

The artifact I would start with is an authority envelope.

Authority envelope core modelA three-stage flow. A sending agent sends a protocol message, the authority envelope adds state, authority, evidence, risk, and next action, and the receiving agent acts only inside the allowed boundary.CORE MODELSending agenthas work to transferAuthority envelopestate • authority • constraintsevidence • risks • human gatenext allowed actionReceiving agentacts inside boundaryThe protocol moves it; the envelope governs it.
A handoff is not just a message. It is a permissioned state transfer.

The handoff is the risk boundary

Most agent-team diagrams make the handoff look too clean: planner hands to researcher, researcher hands to writer, writer hands to reviewer, reviewer hands to publisher. Boxes, arrows, roles.

That picture hides the important question: what exactly crosses the arrow?

If the answer is only "the prompt" or "the latest message," the receiving agent is being asked to reconstruct too much. It has to infer the goal, the current state, the allowed authority, the unresolved risks, the evidence behind prior decisions, and the boundary between suggestion and permission.

That is how agent teams become confident and sloppy at the same time.

The handoff should be treated as a state-transfer event. A new actor is about to continue work it did not originate. Before it acts, it needs a packet that says what has been decided, what has not been decided, what it may do, what it may not do, and what proof exists.

That packet is the authority envelope.

What an authority envelope carries

An authority envelope is not a new protocol. It is the operational layer above the protocol.

The protocol moves the envelope. The envelope explains whether the next move is allowed.

A useful envelope has at least eight fields:

  1. Goal: the business or product outcome this handoff is serving.
  2. Current state: what is known, what changed, and what artifact is being passed forward.
  3. Authority: what the receiving agent is allowed to do without another approval.
  4. Constraints: what it must not change, publish, delete, expose, or assume.
  5. Evidence: links, citations, logs, screenshots, tests, or readbacks that justify the current state.
  6. Open risks: the unresolved issues the next actor must preserve or resolve.
  7. Human gate: whether a person must approve the next step before execution.
  8. Next allowed action: the narrow action the receiver is being asked to take now.

That last field matters. Without it, every handoff becomes an invitation to improvise.

The point is not to make agents bureaucratic. The point is to stop pretending that a fluent continuation is the same thing as a safe continuation.

Protocols make exchange legible. Envelopes make action auditable.

MCP and A2A are useful precisely because they make parts of the exchange explicit.

MCP defines a client-server architecture where applications can share context with models and expose tools and resources. Its tool documentation is also careful about trust: tool invocation can be model-controlled, and implementations are expected to design the user interaction model, including confirmation or denial paths for sensitive actions.

A2A similarly focuses on interoperability between opaque agentic applications. Its specification describes agents discovering capabilities, negotiating interaction modalities, managing collaborative tasks, and exchanging information without requiring access to each other's internal memory or tools. Its enterprise guidance leaves authorization responsibility with the serving side after authentication, and secondary credentials are obtained outside the core protocol flow.

That is the right division of labor. The protocol should not pretend to be the full operating model for every company, surface, and risk level.

But builders should read that division clearly: if the protocol does not own your approval policy, your rollback path, your proof standard, or your memory boundary, then your system still needs a place where those decisions live.

The authority envelope is one candidate for that place.

A concrete envelope shape

Here is the simplest version I would want before letting one agent hand work to another in a production-adjacent workflow:

goal: "Prepare a customer-safe recommendation for renewal outreach."
current_state:
  artifact: "draft recommendation"
  summary: "Usage increased, support burden decreased, expansion signal is moderate."
  changed_since_last_gate: "Added pricing sensitivity note."
authority:
  allowed:
    - "summarize account history"
    - "draft internal recommendation"
    - "request missing evidence"
  not_allowed:
    - "send customer email"
    - "change CRM fields"
    - "quote pricing"
constraints:
  privacy: "Do not expose internal support notes verbatim."
  brand: "No certainty claims about customer intent."
evidence:
  - type: "source"
    description: "usage dashboard readback"
  - type: "source"
    description: "support ticket trend summary"
open_risks:
  - "pricing sensitivity has not been confirmed by account owner"
  - "usage spike may be seasonal"
human_gate:
  required_before: "external_send"
  owner: "account owner"
next_allowed_action: "revise recommendation and flag evidence gaps"

This is not glamorous infrastructure. That is why it is useful.

It gives the receiving agent less room to hallucinate authority. It gives the reviewer a surface to inspect. It gives the system a durable record of why the next action was permitted. It turns "agent collaboration" from a vibe into a controllable workflow.

The anti-pattern: role chains without authority chains

Role chain versus authority chainSide-by-side comparison. The left side shows role handoffs with unclear permissions. The right side shows the same work moving with authority, evidence, risk, and human gate labels.FAILURE MODERole chainAuthority chainResearcherWriterExecHidden questionWho is allowed to approve the next action?Statewhat changedAuthoritywhat is allowedGatewho signsInspectable handoffpermission, proof, and risk travel with the work
Role chains make demos look alive; authority chains make production work inspectable.

A lot of agent-team demos show role chains: one agent researches, one writes, one critiques, one executes. The demo looks alive because each role speaks in its own voice.

But role assignment is not authority design.

A critic agent can say something is ready. That does not mean it has the authority to approve publication. A researcher agent can find a source. That does not mean it has established the source is sufficient for a public claim. A coding agent can pass tests. That does not mean it can deploy. A support agent can draft a reply. That does not mean it can send it to a customer.

The operating mistake is letting the role name smuggle in the permission model.

An authority envelope forces the distinction. It says: this is the role, this is the state, this is the permitted action, this is the evidence, and this is the gate that still belongs to a human or a narrower approval process.

That distinction will matter more as protocols improve, not less. Better interoperability increases the number of actions agents can reach. It does not automatically increase the number of actions they should be allowed to take.

Authority envelope checklistA two-column checklist with eight fields: goal, current state, authority, constraints, evidence, open risks, human gate, and next allowed action.OPERATOR CHECKLISTWhat must cross the handoff boundary1Goalthe outcome this work serves2Current statewhat changed and what travels3Authoritywhat it may do alone4Constraintswhat it must not touch5Evidenceproof behind the current state6Open riskswhat must not be washed out7Human gatewho must approve sensitive action8Next allowed actionthe narrow move now
The checklist is boring on purpose: boring fields are what keep agent work governable.

What to inspect before you trust a handoff

If you are building agent teams, do not start by asking whether your agents can talk to each other. Assume that part gets easier.

Ask harder questions:

  • Does every handoff carry the goal and current state, or only the latest message?
  • Does the receiving agent know its authority boundary before it acts?
  • Is there a field that explicitly says what is not allowed?
  • Does evidence travel with the work, or does the reviewer have to reconstruct it?
  • Are unresolved risks preserved across the handoff, or accidentally washed out by summarization?
  • Is the human gate named before the system reaches the sensitive action?
  • Can you audit why the next action was permitted?
  • Can you roll back or pause a workflow when the envelope is incomplete?

These questions are boring in exactly the way production systems are boring. They turn agentic behavior into something an operator can reason about.

The real bottleneck

The next agent bottleneck is not whether agents can exchange messages. That layer is improving.

The bottleneck is whether the work can move through a system without losing authority, evidence, state, and accountability at every handoff.

Protocols make agents interoperable.

Authority envelopes make agent work inspectable.

If you are building a serious agent stack, you need both. But do not confuse them. The protocol gets the next agent in the loop. The envelope tells it what it is allowed to do once it gets there.

Sources

#tags # AI Agents # Agent Operations # Multi-Agent Systems # AI Governance
m@berryhill in ~/posts$
$ cd ../ · back to posts/