VARTA
Log in

The engine, not a prompt

A VARTA call moves through seven explicit layers -- L1 through L7 -- each with a narrow, inspectable job, instead of one growing prompt handed to a model every turn. Call flows are authored as deterministic step graphs: the same input takes the same path, every time, which is what makes a call flow testable at all.

Because most of what a caller says has been said before, VARTA plays cached audio for repeated phrasing instead of re-synthesising it, and only escalates to an LLM call for the turns that genuinely require reasoning. That is the architecture the cost calculator models.

This isn't a lab demo of the idea: humanise.ai is a live, multi-tenant SaaS product running on this exact core today, in production, for real calls.

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, 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.

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.