# Operavo: what a voice agent must get right > Our own product is where the operating decisions in these notes get tested: what the system is allowed to finish, where it stops, and what every call leaves behind. Published: 2026-09-01 Updated: 2026-09-01 Category: Applied AI Most of what we write here is drawn from work we do for other organisations. [Operavo](https://operavo.ai) is the exception: it is our own product, an AI voice agent that answers the inbound line for real estate teams, and it is the place where the operating decisions in these notes have to survive contact with a stranger who dialled a number and expects a person. A phone call is an unforgiving surface for automation. There is no back button, no place to hide a loading state, and no second attempt at a first impression. Whatever the system does, it does out loud, in real time, in front of someone who can hang up. ## The work chose the boundary, not the technology Operavo does not try to be a general assistant for a brokerage. It handles inbound calls, and within those calls it does four things: answer, qualify, book, and summarise. Everything else is either handed to a person or left to the systems that already do it. That scope came out of the same assessment we would run for a client. Inbound calls were a good candidate because [the work itself pointed there](/journal/the-work-should-decide-where-ai-belongs): the volume is real, the outcome is defined, the information needed to reach it is knowable during the call, and the cost of a missed one is immediate and measurable. A call that rings out at 8pm is not a degraded experience. It is a lead that went to whoever picked up instead. ## An outcome on the call, or an honest handoff The design constraint we set was that a call should end in a result rather than a promise. When a caller asks what times are available, the agent checks the live calendar and reads back open slots during the conversation. If the time they wanted is taken, they hear the next available options instead of an offer to call them back. When a booking confirms, a text with the appointment details and a one-tap calendar link goes out while the caller is still on the line. None of this is difficult to describe and all of it is easy to get wrong. Reading a calendar out loud means the agent must never offer a slot that is already gone, must interpret “Tuesday” and “next week” the way a person would, and must do it fast enough that the caller does not start wondering whether the line has dropped. > A voice agent is not judged on the calls it completes. It is judged on what it does at the edge of what it is allowed to do. ## The stop conditions are part of the product The moment a caller asks for a person, the call bridges to the team with a short hold message. The same thing happens when the conversation moves somewhere the agent should not be handling. Routing follows the intent of the call rather than whoever is free, and when nobody picks up, the caller is told a person will call them back rather than being quietly dropped. We built this before we expanded what the agent could do, because [escalation is a product feature rather than a fallback](/journal/escalation-is-a-product-feature). A handoff is not the system failing. It is responsibility moving to the right place with the context already attached. ## Failure needs a script too Audio is unreliable in ways that text never is. Callers drive through tunnels, stand in wind, and share a line with a television. Operavo answers that with a fixed ladder rather than improvisation. A first mishearing gets a plain apology and a request to repeat. A second one names the likely cause and offers to connect a person. A third transfers the call. The caller never hears an error code and never gets stuck in a loop with a system that keeps trying the same thing. This is worth stating as a rule because the failure path is the part of a voice product that almost never gets rehearsed before launch. It should be tested deliberately, with real bad audio, not demonstrated on a clean line in a quiet room. ## What every call leaves behind An automated call that leaves no record has moved the work rather than done it. Every Operavo call produces a transcript, a Hot, Warm, or Cold tag, a short summary, and a suggested next action, all of it landing in a dashboard alongside the call log, the appointments, and an export the team can open in whatever they already use. That record is the point. It is what lets a team see [whether the system is becoming more reliable after launch](/journal/what-to-measure-after-launch) rather than simply busier: which calls are being handed off and why, where qualification is thin, and whether the boundary is set in the right place. Handoff patterns in particular tend to say more about the operating design than completion rates do. ## Running it ourselves is the point Building our own product means we carry the operating burden we describe to clients. We do the number porting, the calendar connection, and a live test call before anything goes on a real line, and we hear the failure modes on our own line first. That is the argument for Operavo existing at all. It is a working answer to the question we get asked most often, which is what accountable automation looks like when it is running rather than when it is being described. You can [hear it on a live call](https://operavo.ai) or read the rest of these notes for the reasoning underneath it.