Your voice agent finished the call. What was it allowed to promise?
Live voice models can now run tool calls while the customer is still talking. That moves the interesting decision from the transcript to the call itself: what the agent may read, what it may say, and what has to stop and wait for a person.
Until this year, the voice part of a customer call ended at a transcript. Whatever needed to happen next happened later, in another system, with a person in between. Every tool built around calls inherited that shape, which is why the standard question has been who updates the CRM afterwards.
That question is now the second one. On 15 September 2026 Google released Gemini 3.8 Live and 3.8 Live Extended Thinking, native speech-to-speech models whose headline capability is asynchronous function calling: tool and API calls execute in the background while audio keeps streaming to the person on the line. (Google)
So the agent no longer hands you something to act on. It acts, mid-sentence, while the customer is still talking.
What shipped, specifically
Worth reading the capability list closely, because each line is really a question about authority rather than about speech.
| Capability | What it means on a live call |
|---|---|
| Asynchronous function calling | The agent can hit your APIs without going silent, so a lookup or a write happens inside the conversation (Google) |
| Alphanumeric precision | Confirmation codes, claim numbers and technical strings are parsed accurately, which is what makes acting on them plausible (Google) |
| Visual context | Dialogue can be grounded in live visual input, so the agent can be looking at what the customer is looking at (Google) |
| 97+ languages | The same policy has to hold in languages nobody on your team reviews (Google) |
Pricing is $0.005 per minute of audio in and $0.018 per minute of audio out, and the models reach production through Live API partners including LiveKit, Pipecat and Vercel. (Google)
At that price, the constraint on putting an agent on live calls stops being cost and stops being quality. What is left is a policy question most teams have not written down.
The question a transcript never raised
A recording is inert. It can be wrong, incomplete or misfiled, and none of that changes a customer record until someone decides it should. The review step was free, because it was structural.
A live tool call removes the structure. At second 40 of a conversation, two different things become possible at once:
- The agent looks something up and answers accurately instead of guessing. This is the reason to do it at all.
- The agent changes something, or says a sentence that commits you to changing something, with nobody watching.
Those arrive together in the same feature. Teams that only plan for the first one end up discovering the second in a support queue.
Draw the line at reversibility, not at risk
"High risk" is not a workable test, because everyone scores it differently and nobody scores it during a call. Reversibility is testable, and an engineer can implement it.
| During the call, the agent wants to | Reversible by one person in a minute | Where it should land |
|---|---|---|
| Read order status, entitlements, delivery exceptions | Nothing changed | Run it live |
| Correct a spelling, log a call reason, set a follow-up date | Yes | Run it live, record what changed |
| Move a delivery date already promised to the customer | Usually | Run it live only if the customer is told, otherwise hold |
| Issue a refund or goodwill credit | No | Hold as an approval |
| Confirm a price, discount or renewal term | No | Hold as an approval |
| Send anything to a third party | No | Hold as a draft |
| Cancel, close or delete a record | No | Hold as an approval |
The test is not whether the model can do it reliably. It is whether you would be comfortable undoing it by hand at 6pm on a Friday.
One more line that belongs in the same policy: what the agent is allowed to say is part of this table. An agent that cannot issue a credit but tells the customer a credit is coming has committed you just as firmly, and has done it in a channel where the record is an audio file. The safe sentence is the one that names the next step and the person, not the outcome.
Four things to settle before a voice agent takes live calls
- What it can read while the call is running. Scope this to the accounts and records the call type needs, not to everything the integration can reach.
- What it may state as a commitment. Write the sentences. This is copy, not configuration, and it is the part that gets skipped.
- What it may write live, and what stops. Use the reversibility table above, and make the hold visible to a person while the context is fresh rather than in a nightly queue.
- What you can reconstruct afterwards. The call, what the agent read, the fields it changed and anything still open should be findable together, by the person who has to answer for it.
The general version of this argument, for agents that are not on a phone, is on our AI agent governance page. The workflow side, where the same work runs on a schedule or a trigger instead of a call, is on AI workflow automation.
Where the call should land
This is the part we have opinions about, because it is the part we built.
A call result is not a special kind of artifact in Kylon. It arrives the way a scheduled workflow result, a follow-up or a sub-agent result arrives: as an activation carrying the same contract as any other piece of work, which we wrote about in more than a message. Voice calls are part of every plan alongside rooms, threads, workflows and apps (pricing), and they run on Vapi as a subprocessor (subprocessors).
What that buys you is unglamorous and specific: the thing the agent did during the call and the thing it held back show up in the same conversation, in the room that owns the account, in front of the people who would have had to chase both.
NHCall 4812 closed, one item waiting
Renewal call moved to Thursday
Delivery exceptions, 3 open
Refund log posted
The voice agent just finished call 4812. What did it do while the customer was on the line, and what is still open?
It looked up the order and read the delivery exception during the call, and told the customer someone would confirm the credit. It did not issue the credit. Here is the call record, the fields it changed, and the one thing waiting for you.
The agent stopped here during the call. Nothing is applied and nothing is sent.
Notice what the agent did not do. It read the order and the delivery exception while the customer was on the line, because those are reads. It updated a date, because that is reversible and the customer was told. It did not issue the credit, and it did not promise one. It said someone would confirm, which is true, and then made confirming take one click in the room where the account lives.
The part that is genuinely new
None of the controls above are new ideas. What is new is that they now have to hold in real time, in 97 languages, at half a cent a minute, in a channel where the only record of what was promised is audio.
The teams who will be fine are not the ones with the best voice model. They are the ones who wrote down what the agent may finish before they turned it on.
If your calls today are recorded rather than answered by an agent, the post-call version of this is meeting notes to finished work. Same argument, slower clock.
Your first company harness. Where humans and agents run your business together.
