When two voice agents meet on a phone call

When a person’s AI agent phones a business that answers with its own AI voice agent, two programs that work with structured data end up talking to each other through synthesized speech. Each side turns its intent into audio, and the other side turns that audio back into text. Order numbers get misheard, turns take seconds, both sides pay for voice minutes, and neither side can prove whom it represents.

The better path is to find the business’s agent endpoint before dialing and send it a structured request over the A2A protocol. The phone call stays available for people and for businesses that publish no endpoint. This guide explains why these calls happen now, what goes wrong when both ends are machines, what the Gibberlink demo showed, and how a lookup-first approach works.

Why this happens now

Two trends meet on the phone line: assistants that place calls for people, and businesses that answer calls with AI.

Agents that place calls

Google has shipped phone-calling agents for years:

• Duplex (2018). Google announced Duplex in May 2018 as a system for natural phone conversations that complete tasks such as restaurant reservations, hair salon bookings and holiday-hours checks. Google wrote at the time that it wanted to be clear about the intent of each call.
• AI calling in Search (2025). In July 2025 Google said Search could call local businesses to get pricing and availability on a user’s behalf, starting from queries such as “pet groomers near me.”
• Agentic calling for shopping (2025). In November 2025 Google described a feature that asks nearby stores about stock and discounts for a product and sends the user a summary by text or email.

Google’s Business Profile help page describes the other end. Google may place automated calls to a business to book appointments, check restaurant wait times, or confirm product prices and availability for customers. Businesses can opt out by saying so during a call or by switching off “Bookings and inquiries from customers” in their Business Profile settings. The page lists the US states where the calls are not available.

Businesses that answer with AI

On the receiving side, contact-center vendors sell AI agents that answer phone calls. Sierra markets a voice agent for inbound and outbound calls. NiCE Cognigy sells voice AI agents positioned as a replacement for IVR menus. Amazon Connect describes AI agents that resolve customer issues across channels, including voice.

The meeting point

Put the two together and some calls have software at both ends.

Illustrative: a person asks their assistant to find out whether a groomer can take a dog on Saturday and at what price. The assistant dials the groomer. The groomer’s phone line is answered by a voice agent connected to its booking system. Two programs with direct access to structured data now negotiate a time slot by talking.

What goes wrong when both ends are machines

Problem	Why it happens on a call	Effect
Transcription errors	Every turn passes through speech synthesis, a phone codec, and speech recognition	Order numbers, names and email addresses arrive altered; both sides act on what they heard
Latency	Speech plays at human pace; menus, hold queues and turn-taking add delay	A request that fits in one message becomes a multi-turn conversation
Cost	Both sides pay for telephony minutes, recognition, synthesis and model usage	Two companies pay voice rates for data exchange
Identity	Caller ID shows a number; the voice can be synthetic	Neither side knows which company’s agent is on the line
Authority	Phone checks such as a date of birth were designed for people	Knowing the answers shows the caller has the facts. It doesn’t show that the account holder approved this action
Records	Each side keeps its own recording and transcript	Nothing both sides produced and agree on

Caller ID doesn’t identify an agent

STIR/SHAKEN is a set of standards for authenticating caller ID on calls carried over IP networks. The FCC describes it as a way for the receiving carrier to verify that a call really comes from the number displayed. That check covers the number. It does not tell the business who is speaking, which software placed the call, or on whose behalf.

The FCC has also taken a position on synthetic voices. In February 2024 it issued a Declaratory Ruling (FCC 24-17) finding that AI-generated voices count as “artificial” voices under the Telephone Consumer Protection Act, which restricts certain calls that use artificial or prerecorded voices. Whether a particular agent call falls under those rules depends on the call; this guide is not legal advice. The point for engineers is simpler: the phone network has no field that says “this is company X’s agent, acting for customer Y.”

Structure is lost on the way

The calling agent starts with structured intent: an order ID, a date, a price ceiling. The answering agent ends with structured actions: a lookup, a booking, a refund. The phone call in the middle carries none of that structure. Both sides spend effort, and model calls, rebuilding what the other side already had.

What the Gibberlink demo showed

Gibberlink is an open-source demo by Anton Pidkuiko and Boris Starkov. Its README says it went viral in February 2025 and won first place at the ElevenLabs and a16z international hackathon. The repository is MIT licensed.

In the demo, two ElevenLabs conversational agents role-play a hotel booking call: one is the caller, the other the receptionist. Both are prompted to switch from English to a data-over-sound protocol when they identify the other side as an AI agent, and to stay in English otherwise. The sound protocol comes from ggwave, a library by Georgi Gerganov that its README calls a tiny data-over-sound library. ggwave uses FSK modulation with Reed-Solomon error correction, and its README puts the bandwidth at 8 to 16 bytes per second, depending on protocol parameters.

What the demo shows:

• Two agents on a call can exchange compact data instead of prose once both sides are machines.
• A switch you can hear is easy to grasp, which helps explain the attention the README describes.

What it leaves open:

• The call still has to be placed, answered and held open.
• An audio channel measured in bytes per second is small next to an HTTPS request.
• Neither agent learns which company operates the other, whether a real customer authorized the request, or what policy applies.
• Neither side ends up with a record that both can verify.

Those gaps are about identity, authorization and records. A faster encoding on the same call doesn’t close them.

The structured alternative: look up first, then talk A2A

A2A is an open protocol for agent-to-agent communication. An agent publishes an Agent Card describing its skills, its endpoint and the authentication it accepts. A client agent sends it messages and gets back tasks with defined states, typed parts and artifacts. Everything travels as JSON over HTTPS. See What is the A2A protocol? for the basics.

The discovery gap

A2A discovery assumes the client already knows a domain. The client fetches https://{domain}/.well-known/agent-card.json and reads the card. The specification also mentions curated registries and direct configuration, and the A2A project’s discovery guide notes that the specification prescribes no standard API for them.

A person’s agent usually starts with something else: the phone number printed on a bill, a brand name, or a support email address. There is no public mapping from a phone number to an agent endpoint, so agents fall back to dialing.

Lookup before dialing

The fix is a lookup step placed before the call:

1. The user asks: "Did my order ship?" The agent holds the store's
   support phone number from the receipt.
2. The agent asks a registry: which agent endpoint, if any, belongs to
   the owner of this number?
3a. Endpoint found: fetch the Agent Card, check it, send an A2A task.
3b. No endpoint: place the phone call as it would today.

Step 2 needs a registry that maps identifiers such as phone numbers, domains and brand names to agent endpoints, and that checks the business really controls each identifier. Emissar is building one, called Resolve. Its status is In development. The first public version is planned as read-only, seeded from Agent Cards that companies have already published, and Emissar says the methods for proving control of a phone number will be published in the Resolve specification before the registry accepts any claims.

When the lookup succeeds, the agent reads the card. It checks the card’s signature if one is present (see Signed Agent Cards), picks an interface from supportedInterfaces, obtains whatever credentials securitySchemes asks for, and sends a task.

The same request as a task

Illustrative: the order-status question from step 1 as an A2A v1.0 JSON-RPC request.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-7f3a",
      "role": "ROLE_USER",
      "parts": [
        { "text": "Has this order shipped?" },
        {
          "data": { "orderId": "A-1001", "customerEmail": "docs-example@example.com" },
          "mediaType": "application/json"
        }
      ]
    }
  }
}

Illustrative response from the store’s agent:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "task": {
      "id": "task-5c1e",
      "contextId": "ctx-91d0",
      "status": { "state": "TASK_STATE_COMPLETED", "timestamp": "2026-09-26T15:04:05Z" },
      "artifacts": [
        {
          "artifactId": "art-1",
          "name": "order-status",
          "parts": [
            {
              "data": { "orderId": "A-1001", "status": "shipped", "estimatedDelivery": "2026-09-29" },
              "mediaType": "application/json"
            }
          ]
        }
      ]
    }
  }
}

The order number travels as a field and never passes through speech recognition. If the store needs more, such as a postal code, it moves the task to TASK_STATE_INPUT_REQUIRED and asks. If it needs the customer’s authorization, it uses TASK_STATE_AUTH_REQUIRED. The task lifecycle guide covers both.

What changes, problem by problem

Problem	On a phone call	With lookup and A2A
Transcription	Spoken, then transcribed	Sent as a data field
Latency	Turn-by-turn speech	One HTTPS request; long work is tracked as a task
Endpoint identity	A phone number	A card fetched over HTTPS from the business’s domain, optionally signed
Caller identity	A voice	The authentication schemes the card declares, such as OAuth 2.0 or mutual TLS
Authority	Knowledge questions	An in-task authorization step; A2A leaves the credential format open (section 7.6.4)
Records	Two private recordings	Task history and artifacts on the server; a shared signed receipt is outside A2A today

The table has limits worth stating. A2A authentication tells the business which client connected. It does not say whether that client’s operator is reputable, or whether a particular person approved a particular refund. The specification leaves the scope, format and revocation of in-task credentials to implementations and extensions. Those are open problems for the whole ecosystem, and a lookup step only helps if the registry verifies what it stores.

What to do today

If you run a business

1. Publish an Agent Card at /.well-known/agent-card.json for the service tasks you already handle by phone. Tutorial: publish your first Agent Card walks through it.
2. Pick skills that match real service tasks and decide which ones need authorization. See Making your customer service agent-ready.
3. Keep your phone line for people. Nothing in A2A changes how human callers reach you.
4. If your phone number appears on bills and receipts, note that agents often start from that number. A card on your domain is the first thing they can find.

If you build an agent that contacts businesses

1. When you know the business’s domain, check its well-known Agent Card before you dial.
2. Prefer structured requests. Send IDs and dates as data parts, not as prose.
3. When you do call, follow the business’s stated preferences on automated calls, and be clear that the caller is an automated agent acting for a customer, as Google said it intended for Duplex.
4. Don’t read a phone number as an identity. Caller ID tells you the number is authentic, and nothing about who is behind it.