A2H (Agent-to-Human) is an open, MIT-licensed protocol specification from Twilio for the human leg of agent communication. When an AI agent needs to notify a person, collect structured input, get an approval, or hand off to a live human, A2H defines one standard message envelope and interaction lifecycle instead of a separate integration per channel. Version 1.0 launched in February 2026 at twilio-labs/Agent2Human, with a written spec, an OpenAPI 3.1 schema, and a reference implementation.

How is A2H different from A2A?

A2A (Agent-to-Agent) standardises how two software agents talk to each other over JSON-RPC, discovered via Agent Cards. A2H standardises how an agent talks to a human — approvals, data collection, and escalation delivered over human channels like SMS, WhatsApp, push, email, and voice. They are complementary legs of the same stack: MCP connects agents to tools, A2A connects agents to agents, and A2H connects agents to the people they act for.

What is the /.well-known/a2h endpoint?

It is A2H's discovery document — the one static artifact a scanner can probe. An A2H gateway serves a JSON document at /.well-known/a2h (an RFC 8615 well-known URI) advertising supported protocol versions (a2h_supported), delivery channels, supported authentication factors such as passkey.webauthn.v1, a jwks_uri for verifying message signatures, and optional spending limits.

Is A2H a Twilio product or an open standard?

An open specification. The spec, OpenAPI 3.1 schema, and reference implementation are published under the MIT licence by Twilio Labs, and anyone can implement an A2H gateway. Twilio has said standards-track submissions (W3C, OpenID Foundation, AAIF) are planned from v1.2 onward — but as of mid-2026 it is a young, single-vendor spec with no named adopters yet.

What is A2H? The Agent-to-Human protocol

What is A2H?

A2H (“Agent-to-Human”) is an open protocol for the human leg of agent communication. The agent stack already has standards for the other two legs — MCP connects agents to tools and data, and A2A connects agents to other agents. But when an agent needs a person — an approval before spending money, a missing piece of information, or a handoff to a live operator — teams have historically built a separate one-off integration for each channel: SMS, email, WhatsApp, push, voice. A2H replaces that with one standard message envelope and interaction lifecycle that works across all of them.

A2H was introduced by Twilio in February 2026 as an open-source, MIT-licensed specification at twilio-labs/Agent2Human: a v1.0 written spec, an OpenAPI 3.1 schema, and a reference implementation with a WebAuthn/passkey demo. Standards-track submissions (W3C, OpenID Foundation, AAIF) are planned from v1.2 onward.

What are the five A2H intents?

Every A2H interaction is one of five intent types. The intent determines whether a response is expected and how it is validated:

Intent	What it does
`INFORM`	One-way, fire-and-forget notification — no response expected.
`COLLECT`	Gather one or more structured input fields from the human.
`AUTHORIZE`	Gate a specific high-stakes action behind an approve/decline answer, optionally requiring strong factors (passkey, OTP).
`ESCALATE`	Transfer the human to a different channel — typically a live person.
`RESULT`	Deliver the agent's final response or outcome after the action completes.

How does an A2H message work?

Every message shares a common envelope. Two details stand out. First, both parties are identified by DIDs — the agent_id is the software actor and the principal_id is the human who delegated authority to it; phone numbers and email addresses live only in channel.address. Second, every message carries a detached JWS signature over the JCS-canonicalised payload, with replay protection via message idempotency, timestamp validation, and TTLs. An abridged AUTHORIZE request looks like this:

{
  "a2h_version": "1.0",
  "type": "AUTHORIZE",
  "interaction_id": "0197f3a2-…-uuidv7",
  "message_id": "0197f3a2-…-uuidv7",
  "agent_id": "did:web:travel-agent.example.com",
  "principal_id": "did:example:alice",
  "channel": { "type": "sms", "address": "tel:+15551234567" },
  "params": {
    "action": "Book flight JFK-LHR for $842",
    "assurance": {
      "level": "HIGH",
      "required_factors": ["passkey.webauthn.v1"]
    },
    "ttl_sec": 900
  },
  "created_at": "2026-07-17T09:00:00Z",
  "signature": "<detached JWS over the JCS-canonicalised payload>"
}

Each interaction moves through a defined lifecycle — PENDING → SENT → WAITING_INPUT and then to ANSWERED, EXPIRED, or CANCELLED — and only WAITING_INPUT accepts a response. High-stakes approvals can demand strong authentication factors such as WebAuthn passkeys, one-time passcodes, or push confirmation, graded by an assurance level.

How do agents call A2H? (MCP tools)

Agents don’t speak A2H directly — an A2H gateway handles delivery, state, and evidence collection, and exposes the protocol to agent frameworks as a set of canonical MCP tools: human_inform(), human_collect(), human_authorize(), human_escalate(), and human_send_result(). That makes the human-in-the-loop step just another tool call from the agent’s point of view, while the gateway worries about which channel reaches the person and what cryptographic evidence the approval produces.

What can a website publish? (/.well-known/a2h)

Unlike A2UI, which defines no publisher-side artifact at all, A2H does have a static discovery surface: a gateway advertises its capabilities in a JSON document at /.well-known/a2h (an RFC 8615 well-known URI):

{
  "a2h_supported": ["1.0"],
  "channels": ["sms", "email", "push", "voice"],
  "factors": ["passkey.webauthn.v1", "otp.sms.v1", "push.v1"],
  "jwks_uri": "https://example.com/.well-known/jwks.json",
  "limits": { "max_single_usd": 500, "daily_usd": 1500 }
}

The honest framing: this is a gateway’s document, not something every website should rush to publish. If you don’t operate an A2H endpoint — something that can actually deliver approvals and collect signed responses — there is nothing for the file to advertise. Its significance is that it makes A2H support externally verifiable, the same property that makes MCP server cards, A2A Agent Cards, and llms.txt scannable.

Does Agent Ready check for A2H?

Not yet — and that is deliberate. A2H v1.0 is only months old, single-vendor, and has no named adopters beyond Twilio’s own examples, so a scored check would grade sites against a surface almost nobody publishes. Agent Ready tracks the protocol instead. If real deployments appear, a discover-then-validate check on /.well-known/a2h would follow the same pattern as the NLWeb (C12), API Catalog (C13), and A2UI (C17) checks: sites that publish the surface get it validated, sites that don’t are never penalised.

A2H sits alongside the other agent-readiness signals — NLWeb, llms.txt, AGENTS.md, and the protocol manifests in the spec registry. To see where your site stands today, run a full agent-readability scan.

Frequently asked questions

What is A2H?: A2H (Agent-to-Human) is an open, MIT-licensed protocol specification from Twilio for the human leg of agent communication. When an AI agent needs to notify a person, collect structured input, get an approval, or hand off to a live human, A2H defines one standard message envelope and interaction lifecycle instead of a separate integration per channel. Version 1.0 launched in February 2026 at twilio-labs/Agent2Human, with a written spec, an OpenAPI 3.1 schema, and a reference implementation.
How is A2H different from A2A?: A2A (Agent-to-Agent) standardises how two software agents talk to each other over JSON-RPC, discovered via Agent Cards. A2H standardises how an agent talks to a human — approvals, data collection, and escalation delivered over human channels like SMS, WhatsApp, push, email, and voice. They are complementary legs of the same stack: MCP connects agents to tools, A2A connects agents to agents, and A2H connects agents to the people they act for.
What are the five A2H intents?: INFORM sends a one-way, fire-and-forget notification. COLLECT gathers one or more structured input fields from the human. AUTHORIZE gates a specific high-stakes action behind an approve/decline answer, optionally requiring factors like a WebAuthn passkey. ESCALATE transfers the human to a different channel, typically a live person. RESULT delivers the agent's final outcome after the action completes.
What is the /.well-known/a2h endpoint?: It is A2H's discovery document — the one static artifact a scanner can probe. An A2H gateway serves a JSON document at /.well-known/a2h (an RFC 8615 well-known URI) advertising supported protocol versions (a2h_supported), delivery channels, supported authentication factors such as passkey.webauthn.v1, a jwks_uri for verifying message signatures, and optional spending limits.
Is A2H a Twilio product or an open standard?: An open specification. The spec, OpenAPI 3.1 schema, and reference implementation are published under the MIT licence by Twilio Labs, and anyone can implement an A2H gateway. Twilio has said standards-track submissions (W3C, OpenID Foundation, AAIF) are planned from v1.2 onward — but as of mid-2026 it is a young, single-vendor spec with no named adopters yet.
Does Agent Ready check for A2H?: Not yet. A2H v1.0 is only months old and adoption is still forming, so there is no A2H check in the registry today. Agent Ready tracks the protocol, and if deployments appear in the wild a discover-then-validate check on /.well-known/a2h would follow the same pattern as the NLWeb (C12), API Catalog (C13), and A2UI (C17) checks — sites that publish no A2H surface would never be penalised.