Build // Voice agents that do the work, not just read an answer out loud.

Real-time voice agents

Conversational voice agents built on your own backend: they verify who is speaking, read real data from your database and write back to the same systems your team uses. Our hotel agent runs 11 to 12 server tools against the same database functions as the app. Published as a pilot: no live phone line yet, and turn based, not full duplex.

An operator with a headset round her neck works late at a desk, her monitor showing an audio waveform above a long table of entries

In short

Polargate builds voice agents that execute instead of only informing. The agent we run in our own hospitality product signs the guest in by voice, reads the real restaurant menu from the database, takes room service orders, books, changes and cancels restaurant and spa reservations, and opens a classified ticket in the same system the app uses, through 11 to 12 server tools wired to the same database functions. Identity is verified inside the call and the PIN never reaches the voice provider or the logs. The system prompt is compiled deterministically from each property's configuration and survived an adversarial red team, 0 of 6 vectors after hardening. It is a pilot and we say so: there is no live phone number taking calls from real customers, no room availability or prices against the PMS, and no full duplex.

What it is

A voice agent that answers your customer by voice and then does the work. It verifies who is speaking, reads real data from your database and writes back to the same systems your team already uses. Polargate builds it, hardens it and stays on it afterwards.

This page is written as a pilot, because that is what it is. What follows separates what already runs from what does not.

What our agent already does

The hotel agent inside our own product signs the guest in by voice, answers questions about the hotel, reads the real menu of each restaurant from the database, takes room service orders, creates, changes and cancels restaurant and spa bookings, triages an incident by opening a classified ticket in the same system the app uses, leaves messages for reception and hands over to reception when the property enables it.

That is 11 to 12 server tools wired to the same database functions the app calls. Not a parallel integration, the same source of truth.

It does not make things up

The menu is read from the database. If a restaurant has no menu loaded, the agent says so instead of inventing one, and it refuses dishes that do not exist. It respects real opening days and booking windows, and when it cannot book it gives the actual schedule instead of a generic error.

Verified on 18 of 18 spoken scenarios in a July 2026 QA run against the running agent in a demo property, with audio, transcript, interface and database as evidence. An earlier preview QA in June 2026 came out at 21 of 24 perfect, with no critical failures.

Identity is checked inside the call

Room number or name plus a PIN, hashed and with lockout after failed attempts, asked once per conversation. The PIN never reaches the voice provider and never reaches the logs. The tenant is always resolved on the server, never taken from the model or from the payload.

The same agent supports two session modes: inside the app, already authenticated through a server side link, where nothing is asked of the guest; and a call mode with the full spoken verification flow.

The prompt is engineering, not a text box

The pilot agent's system prompt is around 31,000 characters, and it is compiled from the property configuration by a deterministic compiler with no language model in it. Before go live it went through an adversarial red team of twelve agents: 4 of 6 attack vectors broke the draft, and 0 of 6 got through after hardening. A separate audit went over the tool schemas and left 12 of 12 healthy.

One agent per tenant, provisioned on its own

Given a property with voice enabled, an edge function creates its agent, compiles its prompt from that property's configuration and assigns the tools its capabilities allow. That path was tested end to end in production and cleaned up afterwards. The client team edits level and capabilities from the platform itself, and the voice backend only reads that configuration through a function that fails closed and returns no guest data and no PIN.

Isolation is checked by machine, not by hand: row level security on the tables that carry a tenant id, and a guardian that discovers tenants and tables instead of listing them, running in continuous integration. As of August 2026 it watches 81 tables carrying a hotel id, and that run, across two real hotels, found no cross tenant leakage.

What it does not do yet

No live phone number taking calls from real customers. The call leg is designed, the number is pending regulatory paperwork, and no real inbound guest call has been validated.
No room availability and no room prices against the PMS. That layer is not open, and the availability tool covers restaurants only.
No full duplex. The APIs available today work by turns, and no provider publishes official end to end latency figures, so we do not quote one. We have a measured synthesis latency for reading a written answer out loud, but that is text to speech, not conversation, and mixing the two numbers would be dishonest.
Every agent we have built so far is a hotel agent. The mechanism is not hotel specific. The production evidence is.

Reading an answer out loud is not a conversation

Text to speech reads back something already written. A voice agent listens, decides and calls tools against your data. They are different products, they cost different money, and we keep their numbers apart.

The stack

The ElevenLabs conversational engine for the agent, the voice and the transcription, with the language model inside it. Our own backend on Supabase, with edge functions and database functions with controlled privilege. Secrets in a vault, never in the repository.

The platform this agent runs on is in production with real guests in two hotels, one of them since August 2026. Those are the platform's numbers, not the voice channel's, and we do not present them as voice results.

What you get

Server tools wired to the same database functions your app or portal already calls, so voice writes to one source of truth
Identity verified inside the call, hashed and rate limited, with the secret never reaching the voice provider or the logs
A system prompt compiled from your configuration by a deterministic compiler, with no language model in the compiler
Adversarial red team against the prompt before go live, plus an audit of every tool schema
Per tenant isolation with row level security and an automated guardian that discovers tables instead of listing them, running in CI
Self service provisioning, so a new property gets its agent, its prompt and its tools in one operation
Spoken QA against the running agent, with audio, transcript, interface and database kept as evidence

Timeline: The schedule follows the actions, not the voice. Wiring the voice engine is the short part; each thing the agent is allowed to do is a server tool against your database, with its own rules and its own tests. A fixed scope Discovery Sprint settles which actions go in the first version before anything is built. Our own hotel agent went through spoken QA rounds in June and July 2026 before we would put it in front of a guest, and we plan the same for yours. If answering a real phone line is part of what you need, say so at the start: that is the leg we have not validated, and it has regulatory paperwork of its own.
Team: Two people, and neither of them sells. Pedro Ciordia, founder and CTO of Polargate, does the architecture, the tools, the prompt engineering and the reviews; Andrés Ciordia, Chief AI Officer, leads the voice agents. Specialists from the studio's network join when a project needs them. The adversarial work is part of the method: the prompt and the tool schemas are attacked before a customer ever talks to the agent.
Price: Scoped and priced in a fixed price Discovery Sprint, from 4,900 EUR, which ends with a closed price for the build itself. What moves that price is the number of actions the agent has to execute, not the voice. The voice provider's own usage is billed separately. Running it afterwards goes under Care, from 850 EUR per month.

Stack

Supabase
PostgreSQL
Deno

Proof

Estevano
Estevano: the guest app and staff console that runs a hotel's day
Estevano is Polargate's own hotel product: a guest app, an AI assistant and a staff console that turn a request into a routed ticket with an owner and a clock. It has been in production at Santo Domingo Bay for months, where it handled around 2,500 real guest requests in four months with a median resolution time of sixteen minutes.
2026Read the case

FAQ

Questions, answered

Can a voice agent answer our phone?

Not yet, and we would rather say it here than in the kickoff. The agent has a call mode with the full spoken verification flow, but the phone leg is designed and not executed: the number is pending regulatory paperwork and no real inbound customer call has been validated. What we have tested is voice inside the app, where the guest arrives already authenticated through a server side link and is never asked for a room number or a PIN. If a live phone line is your actual requirement, that is the first thing to plan, budget and validate.

How do you stop it from making things up?

By not letting it answer from memory. Facts come from your database through server tools, so the menu is the menu that is loaded, and if a restaurant has no menu the agent says so instead of producing one. It refuses items that do not exist and respects real opening days and booking windows. The system prompt was attacked by an adversarial red team of twelve agents before go live: 4 of 6 vectors broke the draft, 0 of 6 got through after hardening. A July 2026 QA run passed 18 of 18 spoken scenarios against the running agent in a demo property, with audio, transcript, interface and database kept as evidence. Those are dated test results, not a permanent guarantee, and we re-run them.

Does this only work for hotels?

The mechanism is not hotel specific: an agent, a set of server tools against your database, a prompt compiled from your configuration, and isolation per tenant. But we will be straight about the evidence. Every voice agent Polargate has built so far is a hospitality agent, and that is where the production testing was done. If your case is a different sector, you are the first of its kind with us, and the Discovery Sprint exists precisely to price and de risk that instead of pretending otherwise.

How is this different from a chatbot that speaks?

A chatbot that speaks reads a written answer out loud. That is text to speech, and it informs. A voice agent listens, verifies who is speaking, decides and calls tools that change real records: an order, a booking, a ticket in the same system your staff work in. They are different products and their numbers do not transfer, which is why we do not quote our synthesis latency as if it were conversational latency. The APIs available today also work by turns, not full duplex, and no provider publishes official end to end latency, so we do not promise a number we cannot measure.

Is our data safe if the voice provider sits in the middle?

The design assumes the voice provider is an outside party. Verification happens inside the call and the PIN is hashed, rate limited and never sent to the provider or written to the logs. The tenant is resolved on our server, never taken from the model or from the payload, so a prompt cannot talk its way into another customer's data. The configuration endpoint fails closed and returns no guest data. Isolation is enforced with row level security and checked in continuous integration by a guardian that discovers tables instead of listing them: as of August 2026 it covers 81 tables carrying a hotel id, and that run, across two real hotels, found no cross tenant leakage. That is a dated verification, not a permanent property, and it runs again on every change.

INITIATE

Start the engine

Tell us what you are building in a few short questions. A senior engineer answers in writing within 48 business hours, with a first take on scope, timeline and price.

Start your project Talk to us