# The VARTA engine ## No invented prices, dates, or IDs In a system where one process generates both the friendly reply and the number quoted to a customer, there's no boundary between conversational text and transactional fact. VARTA keeps that boundary explicit: logic, not the language model, owns anything that becomes a record -- a price, a date, an ID, an amount. When the AI layer does run, it can only choose from a shortlist built by the workflow itself; it never composes a number from scratch. A low-confidence choice, or one that fails validation against the current step, falls through to a re-ask rather than a guess. ## Answering without the pause A caller notices a brief silence, and assumes the line is dead well before most systems would even start speaking. VARTA attacks that pause structurally rather than by chasing a faster model: most turns are resolved by logic before a model is ever called, a natural-sounding filler plays instantly on the turns that do need one, and audio that has already been generated once is replayed rather than resynthesised live. Speech recognition, language-model reasoning and speech synthesis are each, on their own, a network call with real latency -- the fastest version of any one of them is still slower than not calling it at all. ## A cache that survives personalisation Most voice platforms cache the obvious way: hash the sentence, store the audio, replay it next time. That works for a fixed greeting and falls apart the moment a sentence contains a caller's name, an order number or an amount -- a large personalised campaign can produce nearly as many unique sentences as calls, from a single template, and a cache built for exact matches never gets reused. VARTA separates the stable skeleton of a sentence from the slot values stitched into it, so the skeleton is cached once and only the variable part is generated (or itself served from a small library of pre-built slot audio). Everything that can change the correct answer -- the stage of the conversation, the tenant, the language, the voice configuration -- is part of the cache's identity, not just the text, so a stale or wrong context becomes a cache miss instead of a confidently wrong answer played back with total conviction. Where a call flow is known in advance, its audio is generated before the first call is placed rather than the first time a caller reaches that line. This is written up on its own, in more depth, as an industry-facing whitepaper on intelligent caching on our [blog](/blog), describing a five-level maturity model most caching implementations never get past the first step of. ## Every call has an itemised bill Ask most voice platforms what a specific call cost and you get a single blended rate, not a breakdown. VARTA prices every model call, every synthesised character and every second of silence individually and attributes it to the call it happened on -- a real per-call ledger, not a blended average. The same discipline applies to building a workflow: every design-time AI call -- drafting a flow, generating rules, translating language variants -- is logged against that workflow's own build cost. See what that ledger actually looks like on the [cost calculator](/cost). ## Every language your callers actually speak The engine's own code contains no language-specific text -- not a translation layer bolted onto an English core, but an engine with no English default to fall back to when a caller's turn is hard to parse. Per-language content -- what the agent says, the rules it follows, the phrases it recognises -- lives in the workflow itself, drafted by the AI co-author or resolved through a runtime lookup with a per-workflow override, including grammar that agrees with the speaker's gender in Hinglish rather than defaulting to one form. The result is meant to hold up on a call that code-switches mid-sentence, not just one conducted entirely in a single language. ## Callers interrupt, backtrack, and change their mind A real caller says "wait, actually make it Thursday," or asks a question that has nothing to do with the current step, or asks the agent to repeat what it just said. VARTA recognises three distinct kinds of this mid-call drift and handles each with a deterministic handler rather than asking a language model to reason its way to a state change: repeating a captured value back without moving the flow, revisiting an earlier step and invalidating what depended on it, or answering a side question and returning to exactly where the conversation left off. ## Empathy your brand can govern An instruction to a language model to "be empathetic and understanding" gives it no boundary -- facing an upset customer asking for a discount, an unconstrained model will invent one, and that becomes a commitment your brand just made on a recorded line. VARTA's empathy handling is a set of named scenarios, each with an explicit policy for what the agent can do, cannot do, and must never do: on a price-negotiation call, for instance, the agent can explain the pricing and offer a callback, and cannot offer a discount or match a competitor. That boundary is data the workflow author can inspect and change, not a hope embedded in a prompt. ## An AI co-author for the flow itself Building a call flow doesn't require an engineer to stay involved forever. Describe the call in plain English and an AI co-author drafts the step-by-step flow, the business rules behind it, the FAQs, and every language variant -- and every AI-proposed change is itself validated against the current flow before it can be applied, so authoring speed doesn't trade away structural safety. ## No vendor lock-in Speech and language-model pricing has moved substantially in recent years, and VARTA doesn't fix you to one vendor's roadmap. Text-to-speech, speech-to-text and the language model are each behind their own provider abstraction, selectable per workflow and, for speech-to-text, overridable per call -- so moving to a different vendor is a configuration change, not a migration project. If a single text-to-speech call to your chosen provider fails mid-call, the platform falls back to a synthetic tone rather than the caller hearing nothing; automatic failover to a different vendor is not part of that today, for text-to-speech, speech-to-text or the language model, so a sustained outage at your chosen provider still needs a workflow-level change to move off it. ## A regression gate, not a prayer Editing a long prompt and listening to a handful of calls to see if it still sounds right doesn't scale, and it leaves no record of what actually changed. VARTA runs a benchmark harness where an AI plays the customer against the same engine that handles real calls, across a suite of scenarios, and diffs conversation quality, per-layer latency and per-call cost before a change against after -- so a workflow edit is reviewed the way a code change is, not taken on faith.