Voice quality is no longer the blocker. Synthesis and turn-taking have improved to the point where most callers stop thinking about them after the first exchange. What is not automatic is everything around the voice, and that is where voice projects stall between a convincing demo and something a contact center can actually run.
Four questions decide it, and none of them are about speech quality:
What is the agent allowed to do?
An agent that looks up an order is useful. An agent that can change an account detail is a liability unless it is structurally incapable of doing so before the caller has been verified.
How does it reach your business systems?
The agent calls your APIs from outside your network. That is a new internet-facing path to your order and customer data.
What happens when it cannot help?
A voice agent is judged less on the calls it resolves than on how it fails: whether the caller reaches a person with their context intact, or has to start again.
Where does the conversation data land?
Every call produces a transcript full of personal data that someone will eventually want to analyze.
Lingaro's AI call center accelerator on Google Cloud addresses all four questions in the architecture rather than deferring them to a roadmap. It uses ElevenLabs for the voice agent and Twilio for telephony. Every durable component, including integration, security, data, and the human console, stays native to Google Cloud.
The accelerator is a reference implementation rather than a slide deck: a working voice agent, the Google Cloud platform underneath it, and the guardrails, evaluation, and governance that a production deployment requires and is built and designed to be pointed at a client's systems. It is a reference build rather than a client deployment, so the numbers that matter, such as containment, handover rate, and cost per call, come from your traffic rather than ours.
It targets a customer-support line where most calls are questions about products, orders, and accounts, and a minority ask for a change to account data. It provides:
Natural conversation over the phone, with live data pulled from business systems during the call.
Identity verification enforced by the architecture before any account change, rather than by asking the model nicely.
Context-preserving handover to a human specialist, with the conversation so far already on their screen.
Every transcript captured, with a de-identified copy that is queryable, dashboards for the business, and quality scores for the operation.
Because those pieces already exist, an engagement can start at integration and iteration rather than at foundations.
Architecture of the AI call center accelerator: Three kinds of requests cross one protected edge into Google Cloud: tool calls, escalations, and signed post-call webhooks.
Architecture of the AI call center accelerator. Three kinds of requests cross one protected edge into Google Cloud: tool calls, escalations, and signed post-call webhooks.
Twilio owns the phone number and the call. ElevenAgents, ElevenLabs' agent platform, runs the conversation: speech recognition, the language model, speech synthesis, and the turn-taking that decides when the caller has finished speaking. The language model is a choice rather than a given. It can be Google Gemini, OpenAI, Anthropic, or your own, and the accelerator defaults to Gemini.
Everything the agent needs from the business lives on Google Cloud, and every request from the agent enters through a single protected edge. Behind it sit services for lookups, escalation, and post-call data; Firestore for live operational data; and a transcript pipeline into BigQuery, where raw transcripts stay in a restricted dataset and only a de-identified copy is opened up for analysis. A specialist console, protected by Identity-Aware Proxy, is where a person picks up the calls the agent cannot finish.
The two sections that follow are the engineering detail behind that picture. For the commercial comparison of Google's own options, skip ahead to “Where Google Cloud's conversational stack fits.”
Permission is a question of topology, not prompting
The control requirement that matters most is that no tool capable of changing account data can run before identity verification has succeeded. A prompt instruction cannot guarantee that: an instruction is guidance the model weighs, not a boundary it cannot cross. So, the accelerator enforces it structurally, following the pattern ElevenLabs itself recommends for caller authentication.
The conversation is built as a graph, and the account-change tool is registered on exactly one node, reachable only through the success path of the verification step. Nowhere else in the graph does that tool exist, so the model cannot call what is not in scope. Branching on the verification result is mechanical, with no model judgment in the loop, and repeated failures escalate on a fixed count rather than on a hunch. The same reasoning sets the autonomy dial. Read-only intents run with wide latitude, because a wrong answer is correctable in the next turn. The one irreversible action runs under full structural control.
Say less than you know
Tool responses carry more than a caller should hear. In our build, telling the agent what not to read back was unreliable, because a language model's instinct is to summarize everything it is given. Naming the handful of fields it may mention proved far more dependable. The tool itself returns only those fields, so the control does not rest on the model's restraint.
Handoff is a designed flow, not an exit
When verification fails repeatedly, the caller asks for a person, or the request falls outside scope, the agent calls an escalation service. That service moves the live call into a Twilio queue with a summary of the conversation attached and files a work item through Cloud Tasks for the specialist console, extending the handoff pattern Twilio publishes for ElevenLabs agents. The specialist answers the queued call from the console itself and can check live account data there without switching tools mid-call.
Evaluation is part of the build
The platform evaluates every conversation against criteria written as observable outcomes rather than opinions: identity verified before any account change, nothing invented when a lookup returns no record, and escalation after repeated verification failures. Simulated callers, including ones that try to talk their way past the identity gate, run from the command line on every change, so a regression surfaces before a customer finds it.
Treat the agent as an external client
The voice platform calls your services from the public internet, and the accelerator treats that traffic accordingly: a single protected edge with always-on DDoS mitigation, a web application firewall tuned to the OWASP Top 10 risks, and rate limiting, with the services behind it configured so they cannot be reached any other way.
Two different jobs, two different queues
An escalation has exactly one destination, so it goes through Cloud Tasks, which gives explicit control over when and how often it is delivered and refuses a duplicate task created under the same name. Both services deliver at least once, so the handler is written to be idempotent.
A transcript has several consumers and no single owner, so it goes through Pub/Sub, which streams it straight into BigQuery and, in parallel, to an analysis service that applies the client's own intent taxonomy and quality rubric with Gemini. Choosing correctly between those two services is cheap on day one and expensive to reverse in year two.
Governance before anyone queries the data
Transcripts are unstructured personal data by default. They land first in a restricted dataset; Sensitive Data Protection profiles it to find the personal data, and its de-identification service masks or tokenizes those fields as a de-identified mart is built.
That mart, not the raw transcripts, feeds Looker dashboards for the business and post-call scores for the specialist console. The console sits behind Identity-Aware Proxy enabled directly on the service. A scheduled job keeps operational data in step with BigQuery, so call outcomes can be analyzed alongside orders.
Stateless services, version-pinned secrets, least-privilege service accounts, and a capacity plan that spans both the voice platform's concurrency limits and the cloud's autoscaling round it out. None of it is glamorous, and all of it is part of what the word "production" actually means.
We are a Google Cloud partner, and Google offers a native option at every level of this design. The choice is about where you want the control point to sit, and it is worth being able to advise on all five, not only the one an accelerator happens to use.
In short: you can put Google's technology at the model layer, the conversation layer, the audio layer, or across the whole contact center. Each choice moves the control point and operating burden somewhere different.
The accelerator takes the managed route, with Gemini selectable as the reasoning model, queue handoff built on the pattern Twilio publishes, and enterprise data residency available in the EU, India, or Singapore.
Every durable component remains native to Google Cloud, with each serving a specific purpose. Cloud Armor provides DDoS mitigation, OWASP Top 10-aligned WAF protections, and rate limiting before traffic reaches your order data. Cloud Tasks ensures each escalated call is routed to a single destination, with controlled retries and an idempotent handler so specialists see only one work item. Sensitive Data Protection enables analysts to work from a de-identified data mart rather than raw transcripts.
Cloud Run, Firestore, Pub/Sub, BigQuery, and Secret Manager support the rest of the platform.
Tool descriptions are the prompt.
The wording of a tool's parameters determines whether the agent asks a clarifying question or guesses. It is written for the model, not for the developer.
Deterministic where it matters, autonomous where it does not.
Over-structuring a FAQ flow slows everything down; under-structuring the one irreversible action is a compliance incident.
Decide data residency before you choose vendors.
Three parties handle every call. Their regional controls have to be reconciled on paper first, not discovered during a security review.
As a data and AI services company and a Google Cloud partner, Lingaro helps enterprises take voice AI from demo to production on various cloud platforms. The accelerator is where we start: the platform, guardrails, and governance are already built on patterns the vendors themselves publish, so an engagement begins with your systems and your customers rather than with foundations.
We work with organizations to:
Choose the voice architecture that fits where they want control: a managed platform, a Google-native stack, or a hybrid.
Design agents with structural guardrails, deterministic routing, and evaluation built in from the first sprint.
Integrate securely with the business systems a call actually depends on, and stand up the escalation path that keeps people in the loop.
Put transcript analytics, personal data governance, and data residency controls in place before the first real call.
To start, we typically need read access to the order, customer, and case systems a call depends on; a test phone number; a slot in your security review; a named specialist to sit behind the console; and an early decision on which region the data must stay in.
If you are weighing whether to put a voice agent on a customer line, or build one, our certified experts can walk you through the live call path, the identity gate, and the transcript pipeline in an hour.
The accelerator runs today as a reference build. We can walk your team through the live call path, the identity gate, and the transcript pipeline in an hour.
Note: Voice AI platforms evolve quickly. Details above reflect ElevenLabs, Twilio, and Google Cloud documentation as of September 2026. Google renamed Vertex AI to Gemini Enterprise Agent Platform and Conversational Insights to Customer Experience Insights in 2026; the aiplatform.googleapis.com API endpoints are unchanged. Verify current names, feature availability, and launch stages before committing to an architecture.
The timeline depends mainly on how quickly we can integrate with your existing systems.
Do we have to replace our contact center to use this?
No, the accelerator works alongside your existing contact center and escalates complex cases to your team.
We prevent unauthorized actions through identity verification and built-in guardrails, not model instructions alone.
Yes, but the architecture must be designed around regional data residency and compliance requirements from the start.