A2A Voice Handoffs Need One Contact-Level Receipt

Amazon Connect Customer Agent-to-Agent makes the boundary concrete. A parent agent can bring an Amazon Connect, Amazon Bedrock AgentCore or external collaborator into a live voice or chat contact. The collaborator may work in the background or speak with the customer. AWS extends the underlying protocol with contact continuity, voice streaming and observability, then records the interaction under one contact.

That is valuable infrastructure. It does not remove the operator's acceptance problem. A protocol task can finish while a booking is unobserved, trace evidence is incomplete, the parent agent never resumes or the human queue never acknowledges the escalation.

The reference gate below passes 25 local cases. It is dependency-free Node.js evaluated against synthetic fixtures. It proves a classification rule, not call quality, integration correctness, customer acceptance or business outcomes.

One contact can cross several evidence systems

AWS announced Customer A2A on September 22, 2026, with bidirectional voice or text collaboration and a contact record that can contain dialogue, tool calls and timing. The service overview describes three collaborator locations: another Connect agent, an AgentCore-hosted agent or an external endpoint.

The customer experiences one conversation. The operator sees at least four evidence planes:

1. Contact identity: the durable customer interaction and channel.
2. Protocol work: the A2A context, task, turn and terminal finish event.
3. Business effect: the booking, case, order or routing record in the authoritative system.
4. Control disposition: the parent resumed, a human queue acknowledged the contact or the workflow stopped.

Do not collapse these into one generated summary. A fluent transcript cannot prove that the CRM accepted a case. A successful tool response cannot prove that the destination record retained the same action. A terminal task cannot prove that someone now controls the live contact.

The protocol itself supports the distinction. The A2A specification separates messages from stateful tasks and artifacts, and cautions against using messages alone to deliver critical results. Conversation output is evidence, but it is not the whole acceptance record.

Name every handoff with stable keys

The receipt should start with identifiers that survive retries and reconnects:

{
  "contactId": "contact-17",
  "contextId": "context-17",
  "taskId": "task-17",
  "turnId": "turn-3",
  "traceId": "trace-17",
  "channel": "voice",
  "finishType": "COMPLETE"
}

Amazon's external collaborator setup is API-only and uses an external endpoint. Its developer contract specifies JSON-RPC over WebSocket, context and task identifiers, and W3C trace context. Voice keeps a persistent connection, while chat can reconnect using the same context.

Treat those keys as joins, not decoration. The contact ID owns the customer interaction. The context and task IDs own collaborator work. The turn ID owns one invocation and its trace. The business effect key owns one intended source-system change.

Never create a new business effect key merely because a network retry created a new request. Reconcile the existing intent first. Otherwise the agent can produce two bookings while every individual request looks technically successful.

This extends the boundary in the GPT-Live delegation authority method. The application still owns permissions, confirmations, business state and review authority. A collaborator receives a bounded task, not the right to redefine the customer's workflow.

Gate voice output and terminal events

Voice makes ordering part of correctness. Amazon's developer guide requires the channel to be ready before the collaborator sends output on a handoff. It also defines three supported terminal finish types: COMPLETE, ESCALATE and COMPLETE_WITH_ERROR. No output should follow the terminal finish event. A standalone ERROR is informational rather than terminal.

The first gate can therefore be deliberately mechanical:

if (receipt.channel === "voice" && receipt.channelReady !== true) {
  return { status: "invalid", reason: "voice channel was not ready" };
}

if (!["COMPLETE", "ESCALATE", "COMPLETE_WITH_ERROR"].includes(receipt.finishType)) {
  return { status: "invalid", reason: "finish type is unsupported" };
}

if (receipt.outputAfterFinish === true) {
  return { status: "invalid", reason: "output followed finish" };
}

These checks do not judge whether an answer was useful. They establish whether the exchange followed the release contract at all. Content quality belongs in representative conversation evaluations. Ordering and terminal-state validity belong in deterministic admission.

The current service quotas and limitations make the control boundary even sharper. Only one collaborator can be active at a time, though different collaborators can participate sequentially. Voice requires Amazon Lex V2. Once a voice collaborator starts, mid-contact handback is not available; the collaborator must complete or escalate. The collaborator therefore needs a tested exit path before it receives a real contact.

Make trace completeness a release condition

AWS's A2A observability requirements call for input and output messages, tool calls and results, per-span timing and a contact finish type. The page also encourages model identifiers, token usage, first-token latency, finish reasons and sub-agent detail.

The receipt gate should bind the trace to the exact turn and require the event classes the turn actually used:

const kinds = new Set(trace.events.map((event) => event.kind));

for (const required of ["input-message", "output-message", "contact-finish"]) {
  if (!kinds.has(required)) return { status: "incomplete-evidence" };
}

if (receipt.businessAction) {
  for (const required of ["tool-call", "tool-result"]) {
    if (!kinds.has(required)) return { status: "incomplete-evidence" };
  }
}

This is an evidence gate, not a telemetry wish list. Amazon's trace-enforcement guidance says an external endpoint can be disabled for new contacts when required trace evidence is missing, while in-flight contacts continue. That is a useful operating distinction: stop admitting new work without abandoning a customer already in the workflow.

Trace completeness still does not prove business completion. A tool result may report acceptance while the source system later rejects, rewrites or fails to expose the record. Preserve the trace as the execution history, then ask the authoritative business system what now exists.

Read the business effect back

For any action, keep both the provider acceptance and the authoritative record:

if (!receipt.businessRecord) {
  return { status: "uncertain", reason: "record was not read back" };
}

if (
  receipt.businessRecord.effectKey !== receipt.businessAction.effectKey ||
  receipt.businessRecord.acceptanceId !== receipt.businessAction.acceptanceId
) {
  return { status: "divergent", reason: "record contradicts action" };
}

This produces distinct terminal states:

• Incomplete evidence: a required trace or receipt field is absent.
• Uncertain: the action may have happened, but no authoritative record was observed.
• Divergent: the authoritative record contradicts the accepted intent.
• Observed: identifiers, trace, accepted action and read-back agree.

Do not turn uncertain into failed. Do not retry it with a fresh effect key. An uncertain booking may already exist. The safe next action is a read or an operator review, not another write.

The source system decides which read-back is authoritative. A calendar event may need an event ID, exact time window, owner and participant set. A support case may need the case ID, queue, workflow state and customer identity. A route may need the destination, transfer status and current owner. The receipt schema should name those fields before the pilot begins.

Record who controls the contact next

Business state and contact control are separate. A completed collaborator turn is not accepted until the parent agent resumes. An escalation is not accepted until the human route acknowledges the contact.

For an escalation, record the intended queue, the request time, the acknowledgment and the person or system now responsible. If acknowledgment is absent, the receipt is uncertain even when the protocol emitted ESCALATE.

For COMPLETE_WITH_ERROR, retain a stable error code and prove that parent control resumed. The parent can then choose a bounded fallback, explain the stop or escalate. A terminal error without a new controller is abandonment wearing a protocol label.

This is why the broader agent workflow operating contract separates answer, action, approval, handoff and refusal. Each route needs its own accepted terminal. A generic done state hides the exact outcome the business owner must review.

Release against the 25 synthetic cases

The retained reference gate passes 25 of 25 dependency-free Node.js cases:

• one fully traced completion after parent resume;
• four missing identity keys;
• unsupported finish type, premature voice output and post-finish output;
• missing or detached trace evidence;
• missing input, output and contact-finish events;
• protocol and trace finish divergence;
• missing tool-call and tool-result evidence;
• incomplete action receipt, missing read-back and business-record divergence;
• matching authoritative read-back;
• unacknowledged and acknowledged human escalation;
• missing parent resume;
• incomplete and recovered terminal error.

The cases prove deterministic classification against synthetic fixtures. They do not prove the chosen agent can understand callers, produce low-latency speech, invoke the right collaborator, write the right system or satisfy customers. A production pilot still needs representative calls, channel-level latency evidence, interruption and reconnect tests, source-system reconciliation, human handoff drills and a workflow owner who can stop release.

Start with one collaborator and one business action path. The platform can support sequential collaborators, but a larger graph multiplies joins and failure combinations before the team has labelled evidence. Add a second collaborator only after the first receipt exposes accepted outcomes, uncertainties, divergences and operator interventions.

The primary metric should be accepted contacts with a complete receipt divided by eligible contacts, alongside the rate of uncertain and divergent terminals. Do not optimize collaborator invocations or task completions. Those are activity counts. The buyer cares whether the customer interaction ended in an observed answer, action, acknowledged handoff or safe stop.

Frequently asked questions