A Building Agentic AI

Blog / Enterprise / When Personal AI Agents Start Calling: Is Your Contact Center Ready?

When Personal AI Agents Start Calling: Is Your Contact Center Ready?

Personal AI agents now phone contact centers for customers. What that changes in IVA selection, identity checks and implementation, and what to ask vendors.

Muhammad Arbab

Muhammad Arbab · 14 years shipping AI

· 18 min read · Enterprise

When Personal AI Agents Start Calling: Is Your Contact Center Ready? Enterprise A bank contact center at dusk. On the desk, beside an old desk phone, a smartphone shows a banking app prompt reading "Approve a dispute on your card?" with an Approve button not yet tapped. A thin line of light runs from the phone to a monitor, where a contact center agent in a headset is looking at a caller card labelled "AI agent caller", reason for call "Dispute a charge", with ticks beside "Security questions passed", "Navigated phone menu" and "Transferred to agent". Serif text at the top left reads "When Personal AI Agents Start Calling".
Share LinkedIn · X · Email ·

Consumers have started sending AI agents to make their customer service calls for them. This piece is for anyone choosing or modernising an IVA (intelligent virtual agent) right now: what has actually shipped, where the risk sits, and what to ask a vendor or an implementation partner before you sign. I have not seen one of these calls on a line I worked on, so everything here comes from what vendors, analysts and reporters have published, most of it since September.

A dispute call nobody dialled

Here is an illustrative call, built from what vendors have published about these calls rather than from a client story. It is an architecture thought experiment, not a documented Gemini or Muse call: Google’s help page says Gemini cannot complete financial transactions or share sensitive financial information over the phone.

A customer spots a card charge she does not recognise. Instead of phoning her bank, she tells her personal AI agent to sort it out, and the agent phones the bank for her.

The bank’s phone menu asks the caller to press 1 for cards. The agent presses 1. It reaches the bank’s IVA, says it is calling on her behalf, and asks to dispute the charge. The IVA asks the usual security questions: date of birth, the last four digits of the card, the ZIP code on the account. The agent knows all three, because she gave them to it. It passes.

Then it adds one more thing. While it has the bank on the line, could it update her mailing address? She moved last month and asked it to tell everyone.

Every step of that call is ordinary. The bank’s systems will record a customer who passed security, raised a dispute and changed an address.

Now run the same call again, except the agent belongs to someone who bought her date of birth and card details. It sounds the same and gives the same answers, and the address change is now the request that matters most. Pindrop, which tracks automated callers for contact centers, lists address and phone number changes among the things account takeover bots ask for.

From inside the bank, the two calls look almost the same.

What changed this autumn

Google’s Gemini can now place calls for people in the US who have a Pixel 11, a paid Google AI plan and the beta of Google’s phone app, and it is rolling out gradually. Google’s help page says Gemini starts every call by disclosing that it is an AI assistant from Google calling on a recorded line on the user’s behalf, gives the user’s name, and calls from the user’s own phone number. Meta expanded a beta of its Muse assistant making outbound calls to US businesses on 16 September. Meta’s page for businesses describes those calls and offers an opt-out form; I found nothing on it about telling the business that the caller is an AI.

The measures I found come from vendors that sell to contact centers, so read them as vendors’ own figures. In Pindrop’s write-up, weekly Muse call volume across its customers in the fourth week was 8 times the first week’s. Cresta reported that traffic from personal agents contacting its customers spiked more than 80 times in mid-September. The populations, definitions and periods differ, so neither figure is an industry growth rate, and the two should not be compared. Among Pindrop’s customers, financial institutions received the most Muse calls, then healthcare, then retail, which is why our call goes to a bank. Pindrop gives no absolute counts and no share of total calls.

One detail matters more than the growth: some of Pindrop’s customers flag Muse calls as fraudulent, and others classify them as legitimate. So there is no shared default to copy yet.

The demand underneath is easier to believe than the volume. In a Gartner survey of business and consumer customers in February and March, 58% of those who use generative AI said they had used it to complete a task on their behalf. That covers every kind of task, not just calls, but it is the habit these features build on.

What nobody can tell you yet, me included, is what share of a contact center’s calls come from personal agents, or how fast it will grow. I found forecasts and one single-site figure I could not verify, and nothing I would plan on. Plan for agent callers without pretending to know the number.

Spotting a machine answers one question of three

Within weeks of each other, several vendors announced ways to detect these callers. Pindrop’s BotStopper, Sierra’s fleming-1, Cresta’s Sentry and Decagon’s Personal Agent Gateway each try to tell you, during the call, that the caller is probably an AI agent. That answers one of the three questions the bank actually has:

  • Is the caller a machine? Detection answers this.
  • Who is it acting for? This is identity, and it is about the customer behind the agent.
  • What is it allowed to do? This is delegated authority. The dispute, yes. The address change, maybe not.

Detection should inform how a call is handled, not automatically block it. A legitimate customer using assistive speech technology could also trigger an AI-caller signal.

The vendors are candid about the gap. Pindrop’s launch says BotStopper “answers the first question about an AI caller: is it a machine?” and that the questions that follow, which agent it is, who it represents and what it should be allowed to do, “are where Pindrop is taking the platform next.” Cresta’s announcement says a likely AI caller “still needs to show that it represents the customer”, and gives the example of a policy under which account changes or payments require additional verification or the customer’s approval.

The phone line also gives the bank very little to check against. Pindrop put it plainly: “A phone call doesn’t arrive with a verified session attached.” On a website, an agent can carry a token the customer granted. On a call, the bank gets a voice, a phone number, and whatever answers the agent was given.

That is why the security questions in our call proved so little. They show that the caller has the data. They do not show that the caller is the customer. An agent she handed her details to will pass them every time, and so will one built by somebody who bought them.

Even when she really did send the agent, passing them tells the bank nothing about what she sent it to do. Her answers got the agent through security. They do not record that she asked for a dispute, and they say nothing at all about the address change. Getting through security and being authorised for a request are two separate checks, and the call in our example only ever ran the first.

So the rule I would design around is this: knowing what is calling does not tell you whether to trust it. Verify the person behind the agent, and let the agent do only what that person handed over. NICE gives the same advice in its own words. In the near term, it says, “authenticate the principal rather than the agent.”

Following the call through the contact center

Back to the bank, and what each part of the contact center has to do with that call.

The old phone menu comes first. In Pindrop’s data, 47% of Muse calls press keypad digits to get through the phone menu. Your legacy IVR (interactive voice response) is often the first system an AI caller meets, and it was built for a person pressing the keys. If detection only runs inside the new IVA, the old menu has already routed the agent before anything notices it.

Detection has to reach the call flow. A “likely agent” score that appears in tomorrow’s dashboard changes nothing about this call. The flow has to be able to act on it while the caller is still there: add a check, change the route, or tag the call. Sierra’s own example is this one: “A bank might want to add a verification step when the caller is an agent.”

Verify the person away from the call. The check I would reach for first happens off the phone line. The bank’s app on her registered phone asks “Approve a dispute on your card?”, and she taps yes. The approval comes from her device and her login, which the bank already trusts, and it names the one request she is approving. That check may be a platform feature, a partner product or the bank’s own identity system and app. Either way, the IVA has to trigger it mid-call and wait for the answer, and wiring that in is integration work.

Decide what an agent may do, request by request. Her approval covers the dispute. Should it cover the address change? A sensible first rule lets an agent caller raise the dispute once she has approved it, and holds anything that changes where mail or money goes until she confirms it herself. In a bank, that rule belongs to CX, fraud and security together, and it has to live somewhere they can change without waiting for a software release.

Put the fraud signals in one decision. The detection score, the number’s history, the device history and the request itself often come from different vendors. The decision to allow, check or hold should see all of them. Whether that decision point is native, comes from a partner or has to be built differs by platform, so check.

Tell the person who picks up. Pindrop found that 64% of Muse calls get through to a human agent. Before speaking, that person needs to see that the caller is an AI agent, who it says it acts for, what was verified and what was approved. Otherwise they start over with a machine, or make the address change because the security questions were passed. What arrives on that screen is its own problem, covered in AI-to-human handoff in the contact center.

Measure agent calls separately. An agent does not mind holding, and Salesforce expects that one asked to watch an order “can call back every few hours until the order ships.” Report containment, handle time and repeat contacts for agent calls separately, or your IVA’s results will move for reasons unrelated to the IVA, and you will lose sight of whether it is resolving issues rather than deflecting them.

Where each part of the dispute call usually sits
Part of the call What the IVA platform may give you What to confirm, configure or build
The phone menu Keypad handling and routing Whether agent callers are spotted before the old menu routes them, or only after
Spotting a likely agent A detector, if your vendor ships one, or a partner product connected to it Making the signal something the call flow can act on during the call
Verifying the customer A way to call an outside check in the middle of a flow The check itself, whether native, from a partner or in your identity system and app
What the agent may do Flow logic for each kind of request The rule for each request, who owns it, and how it changes without a release
Fraud Connections to fraud and authentication vendors, on some platforms One decision that weighs every signal before allowing, checking or holding
Handoff to a person A transfer with data attached A screen that says: agent caller, acting for whom, verified how, approved for what
Reporting Standard containment and handle time reports Every metric split between agent callers and people
A planning view, not a vendor audit. The split differs by platform, so check yours.

What each platform has published

The table below is a snapshot of what the main IVA and contact center AI vendors had said in public about agent callers when I read their pages on 24 October 2026. This area is changing week to week, so treat it as a dated record of published material rather than a ranking or a current feature list. Each cell describes specific published material, not a vendor’s full capability. A detector does not make a contact center ready for agent callers, and a vendor that has published nothing on a point may still support it. Ask.

Public information snapshot, 24 October 2026: what each vendor has published about agent callers
Vendor Spots a likely AI caller Identity, authorization and policy, as published Agent protocol work
Pindrop BotStopper, available (16 Sep), with no other Pindrop product required. Recognises known agents from a registry of AI voices Names which agent, whom it represents and what it may do as where the platform goes next. Also sells Passport caller authentication and Protect fraud risk scoring; the material reviewed does not establish how these apply to AI callers Not covered in the material reviewed
Sierra fleming-1, launched 8 Oct for voice agents built on Sierra; scores call audio during the call A separate initiative: co-developing Personal Agent Protocol with Meta. Draft (9 Oct) covering websites, APIs and the company's own agent; the phone line appears only as today's fallback Personal Agent Protocol, draft, as co-developer
Cresta Sentry-0.1, available to Cresta customers (12 Oct). Reads the conversation, not the audio Gives the example of a policy by request: allowed requests proceed, while account changes or payments require more verification or customer approval. Real-time guidance tells staff which actions need the customer to confirm by SMS or in-app. Also analytics Says it supports the new protocols; the post does not detail them
Decagon Personal Agent Gateway flags likely agents in chat and voice (1 Oct). No release date given Permission scopes inside its Agent Operating Procedures for agents using its personal agent channel. Separately, PACT (6 Oct), an open-source specification on A2A and OAuth 2.0 for verifying whom an agent represents and what was authorised; the PACT post does not mention voice A2A, through PACT
Parloa Not covered in the post reviewed Personal Agent Middleware applies a company's permission and workflow rules to requests from personal agents. Limited design partnership (15 Oct). The post does not establish whether it covers voice Built on Personal Agent Protocol, MCP, OAuth 2.1 token exchange and A2A
NICE (CXone, Cognigy) Not covered in the guidance reviewed (23 Sep) Advises a controlled front door that authenticates the person behind the agent and enforces policy, and says identity standards are still maturing. Listed by Sierra as a partner on Personal Agent Protocol Says Cognigy supports A2A and MCP today. The A2A server endpoint added on 29 Sep is labelled experimental and not intended for production use
Genesys Not covered in the post reviewed Co-developing Personal Agent Protocol (6 Oct). Says a business needs to know who an agent represents and what it has permission to do Personal Agent Protocol, draft, as co-developer
Amazon Connect Not covered in the A2A announcement Support for its own Voice ID caller authentication ended on 20 May 2026. AWS points customers to partners such as Pindrop for caller authentication A2A collaboration over text or bidirectional voice with AI agents the business brings in, launched 22 Sep. The announcement does not address personal agents calling in
From each vendor's own pages, plus Sierra's partner list for NICE, read on 24 October 2026. "Not covered" means the material reviewed does not establish it, not that the product lacks it.

For Five9, Talkdesk, PolyAI, Microsoft, Salesforce and Google’s contact center products, the public material I reviewed did not establish a capability specific to verifying an AI caller on a phone call. That is a limit of my search, not a finding about their products.

Two things stand out. Detection is the most clearly available piece: Pindrop, Sierra and Cresta describe theirs as launched or available. For authorization, the published approaches either confirm consequential requests with the customer directly, as Cresta describes, or give agents scoped permissions through a channel or protocol built for them, as Decagon, Parloa and Personal Agent Protocol describe. The documents reviewed describe the second kind for digital channels, or do not establish whether it covers a phone call.

Agent to agent, and why the phone stays

The longer-term answer is that many of these calls stop being calls. If the bank publishes an interface that Personal Agent Protocol or PACT can use, the customer’s agent arrives with a permission she granted, limited to raising a dispute, and the bank checks it the way it checks any app login, without having to judge a voice. A2A, the agent-to-agent protocol PACT is built on, is already in contact center products. Amazon Connect has launched A2A collaboration with AI agents a business brings in, over text or bidirectional voice; the announcement does not address personal agents calling in. NICE says Cognigy supports A2A and MCP today, and Cognigy’s release notes label the A2A server endpoint added in September experimental and not intended for production use.

That is worth designing toward, but it will not replace the phone soon. Today’s consumer agents call phone numbers, the protocol is a draft whose own launch post describes the support line as the fallback, and plenty of customers and businesses may never use it. Bret Taylor, Sierra’s co-founder, told CNBC that “it is kind of chaos until such a standard exists.” For now, plan for both: a door for agents that can prove who sent them, and a phone line that still has to cope with the ones that cannot.

What changes in selection and planning

If you are choosing an IVA this year, agent callers mostly change what you check and what you plan for.

They add a question to every demo: what does the platform do during the call? They spread the work across the stack. Depending on the platform and configuration, the device check, the rule for each request, the combined fraud decision and the split reporting may be native features, partner integrations or services in your identity system, CRM, fraud tools and data platform. Evaluate the complete call flow to see what is available and what still needs implementation. And they make ownership the hard part. The detector may come from one vendor, the IVA from another, the identity check from a third, and the rule about address changes from your own fraud team. Each vendor will answer honestly for its own part. Even when a platform covers much of the workflow, enterprises still need to establish how the complete call is handled across their systems and who owns each decision.

That is where an independent view earns its place, whether it comes from your own architects or from outside. Someone has to trace the dispute call from the first keypress to the line in the report and mark which system does each step, which step nothing does yet, and who decides the rules. Choosing the platform gets easier once that map exists, and my comparison of voice AI and IVA platforms for contact centers covers who owns the conversation logic on each.

Eight questions to ask before you sign

These are written so that a reflexive yes does not count as an answer. Ask the first seven of the platform vendor, and the last of whoever will implement it.

1. Show me a recorded test call where the caller is an AI agent. Which signal fires, where does it appear, and what does the flow do next?

2. Can my call flow act on that signal during the call, or does it only appear in reporting afterwards?

3. How does the flow trigger a check on the customer’s own device in the middle of a call and wait for the result? Which system owns that check: yours, our identity system or our app?

4. Where do I write the rule that an agent caller may raise a dispute but may not change an address, and who on my team can change that rule without a release?

5. When an AI caller is transferred, what does the person’s screen say about who is calling, for whom, what was verified and what was approved?

6. Can I report containment, handle time and repeat contacts separately for agent callers, and how does that split reach the reports we already use?

7. Which agent protocols do you support today, and at what status: generally available, preview or draft? Does any of it apply to a phone call rather than an API?

8. For each answer above, which part does the platform do out of the box, which part will you build, and which system will own it in production? Put it in writing.

I would not expect clean answers to all eight yet. A detector and a roadmap is an honest answer in October 2026. The open part is the one our dispute call turns on. In the material I reviewed, I did not find a documented, generally available standard for an agent on an ordinary phone line to prove who sent it and what it was allowed to do. For now, enterprises need to establish how customer identity and delegated permissions will be verified for each sensitive request, using the capabilities available across their platforms, partners and existing systems. I do not know how long that will last.

The principles behind that decision run through Designing Enterprise Agentic AI Systems, and the same question asked of your own agents is the subject of On Whose Authority?

If you want an outside read on where your contact center stands, the Agentic AI Readiness Review can cover exactly this: a working session on your call flows, identity checks and reporting, then a short memo on what your platform covers and what you would need to build. Implementation work beyond that is part of the voice AI development work I do.

Share this post LinkedIn · X · Email ·

Frequently asked

Quick answers

Can personal AI agents call a contact center today?
Yes, in the US, though availability is limited and changing quickly. Google's Gemini can place calls for eligible users with a Pixel 11 and a paid Google AI plan, and Google's help page says each call opens by saying it is an AI assistant from Google calling on the user's behalf. Meta has been testing outbound calls to businesses from its Muse assistant. Check each product's own pages for current status.
Is AI caller detection enough to make a contact center ready?
No. Detection tells you the caller is probably a machine. It does not tell you who the agent is acting for or what it is allowed to do, and Pindrop says so itself. Cresta says a likely AI caller still has to show it represents the customer. Being ready also takes a way to verify the customer behind the agent, a rule for what an agent may do, a handoff that tells the person picking up what is calling, and reporting that keeps agent calls separate.
Should a contact center block AI agent callers?
Blocking by default is risky, because agents acting for real customers are already calling. Pindrop reports that some of its customers flag Muse calls as fraud while others classify them as legitimate, and its CEO has said legitimate agents should be welcomed. A safer start is to detect, tag and measure agent calls, require a check on the customer's own device before anything sensitive, and hold changes to where mail or money goes until the customer confirms them directly.
End · 18 min read ← All posts

Keep reading

Related posts