When to keep a human in agent-to-agent requests

Agent-to-agent exchanges are fast because both sides follow rules. That is also where they fail. Five kinds of request need a person on at least one side: emotionally sensitive situations, judgment calls, policy exceptions, strong identity proofing, and commitments beyond what someone approved in advance. In each, an agent that finishes the task alone does worse than a human channel would. The design goal is to recognize these cases early and hand them over with the full exchange attached, so nobody starts again.

How it works today

Human channels have judgment built in. A representative on the phone can hear distress, sense that the facts do not add up, bend a rule for a long-standing customer, or ask a supervisor. Automated channels often lose that. The CFPB’s 2023 review of chatbots in consumer finance found they can fail to recognize when a consumer is invoking federal rights such as a dispute, trap people in loops of unhelpful answers, and make it hard to reach a person.

Some rules already require a person in the loop:

Rule	Where	What it requires
Directive on Automated Decision-Making (current version modified June 2025)	Government of Canada	For impact levels III and IV, the final decision must be made by a human, with defined human involvement during the process. Clients must be told their recourse options
SB26-189, signed May 2026, in effect 1 January 2027	Colorado	A consumer can request meaningful human review and reconsideration after a covered automated system makes a consequential decision with an adverse outcome. It repeals and reenacts the 2024 Colorado AI Act
SB 243, approved October 2025	California	Operators of companion chatbots must keep a protocol that refers users expressing suicidal ideation or self-harm to crisis services
NIST SP 800-63-4, final July 2025	US federal guidance	The highest identity assurance level, IAL3, requires an attended, on-site proofing session with a trained proofing agent and at least one biometric

A customer service agent is not a companion chatbot and most businesses are not government departments. The rules still show where lawmakers and standards bodies have drawn the line.

The agent-to-agent version

In these cases the agent-to-agent version is a handover. Illustrative. A customer’s assistant asks a bank’s service agent to close a joint account and mentions that the co-owner has died. The bank’s agent does not proceed. It keeps the task open, tells the assistant a person will handle it, and says when:

{
  "id": "task-close-8820",
  "contextId": "ctx-acct-3317",
  "status": {
    "state": "TASK_STATE_WORKING",
    "message": {
      "messageId": "msg-close-8820-2",
      "taskId": "task-close-8820",
      "contextId": "ctx-acct-3317",
      "role": "ROLE_AGENT",
      "parts": [
        { "text": "We are sorry for your loss. A member of our bereavement team will contact the account holder by phone within one business day. Nothing on the account will change until then." }
      ]
    }
  },
  "metadata": {
    "handledBy": "person",
    "team": "bereavement-support",
    "expectedContactBy": "2026-10-02T17:00:00-04:00"
  }
}

The metadata keys are a local convention. A2A defines no standard field for “a person is handling this”.

The five cases and how to route them:

Case	Signals	Route
Emotionally sensitive	Bereavement, fraud victims, financial hardship, health news, any sign of crisis	A person, reached without the customer repeating their story; crisis resources where there is any sign of risk
Judgment call	Conflicting evidence, facts outside the agent’s data, goodwill decisions	A person with authority to decide, holding the full exchange
Policy exception	The request is reasonable but outside published rules	A person who can grant or refuse the exception and say why. Agents should neither invent exceptions nor refuse silently
Strong identity proofing	Account recovery, changing payout details, porting a phone number, adding a new authorized user	The business’s own proofing channel. An agent relaying what a person typed is not proof of who they are
Beyond pre-approved limits	An amount, term or action outside what the principal approved	Back to the principal for fresh approval, through TASK_STATE_AUTH_REQUIRED or the principal’s own app

What has to be true

Identity. The person who takes over must know which agent and which principal they are dealing with, and their own identity and role should be recorded. For strong proofing, the business’s process must run on a channel it controls. NIST’s highest assurance level requires an attended, on-site session with a trained proofing agent, which no intermediary agent can stand in for, and lower levels still depend on evidence the business checks itself.

Authority. Limits need to be explicit before they can be enforced. AP2 shows one pattern for payments: the user reviews and approves mandate content on a trusted surface that is not itself an agent. Open mandates carry constraints the agent must satisfy, and any constraint a verifier does not recognize fails. Anything outside those constraints goes back to the person. Businesses need the same clarity for their own side: who may approve an exception, up to what amount, and on what grounds.

Record. The handover must carry the whole exchange: what each agent asked and answered, what the principal authorized, and why the task was flagged. The person’s decision must go back into the same task, so both agents and both records agree on the outcome.

Standards involved: A2A’s interrupted states (TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED, section 3.2.2) and its in-task authorization rules (section 7.6, which gives human approval before a destructive action as an example); A2A push notifications, designed for long-running work with humans in the loop; NIST SP 800-63-4 for identity assurance; AP2 for payment limits.

Where Emissar fits

• Handoff (in development) is the module for this page: it passes a task to a person with the full exchange attached, in the help desk the team already uses, and returns the person’s decision to both agents.
• Mandate (spec in progress) is a proposal for writing down the limits whose breach should trigger a handover.
• Ledger (spec in progress) records the human decision alongside the agents’ exchange.
• Verify (in development) can answer “ask for more proof” instead of allow or refuse, which is often the first step toward a person.

None of these is available today. Until they are, the same pattern can be built with A2A task states, a status message and the business’s existing help desk.

Open questions

• How should a requesting agent signal that its user is distressed without sharing more sensitive detail than needed?
• Should A2A have a standard way to say “a person is handling this”, perhaps as an extension?
• What response time is reasonable when a task waits for a person, and how is it communicated?
• If agents file requests at volume, who pays for the human review they trigger?
• Can a person’s agent insist on a human? Colorado’s review right is one legal hook; most situations have none.