Let people take the hard calls
Chat and voice that answer the routine from your own knowledge, hand off what needs a person with the conversation attached, and stay inside a cap per conversation.
The first second decides the call
Hold music, then the same question as the last caller.
Your agents answer it forty times before lunch.
The customer explains it twice, to two people.
The handoff dropped the conversation.
A bot answered confidently. It was wrong.
Now the complaint is about the bot.
Most contacts are routine.The rest deserve a person.
The situations, and the guide that builds each
Every one is a build guide: the architecture, the policy, the code that was run, and what was measured.
Routine calls on a voice line
A turn-based voice assistant: transcribe, answer in a sentence, speak the reply, all on one key. Measured honestly at 7 to 13 seconds a turn today, which fits an IVR and not yet a conversation; the guide says what would close the gap.
Build guide: Voice agent
Chat that answers and hands off
A chat that answers from your own knowledge with a citation and hands off to a person when the customer asks or is upset, with the conversation emailed to your queue as one thread.
Build guide: Customer support assistant
Account changes with a person on every write
An agent that reads the account and acts through tools named in a policy. Reads run at once; changes wait for approval, and every run is one record.
Build guide: Agents with tools and MCP
Answers over your knowledge base
Retrieval over macros, policies and past resolutions, with each answer routed on how hard it is and cited to its source.
Build guide: RAG over a knowledge base
Forms and notes into your CRM
Call notes, forms and attachments into fields that match your schema, with a review queue for what validation rejects.
Build guide: Document extraction to JSONWhat changes for customer operations and contact centres
Calls and chats where the first second decides, handoffs that have to reach a person, and spend that has to stay inside a cap per conversation.
Handoff keeps the conversation
The model marks a handoff in the same call as its answer, and the conversation reaches a person whole, so nobody explains twice.
Wrong confidently is refused
Answers come from your own passages with a citation, and the prompt says so when they do not settle the question. An evaluation holds it to that after every change.
Every conversation has a ceiling
A spend cap per session in the policy and a daily cap on the key. A long conversation or a runaway client stops at a number you set.
Honest about voice
Every design states its measured latency. Voice is a turn-based assistant today, and the guide lists the four gaps to a real-time conversation.
Figures with a source
Every number here was measured by us and says when. Where nothing was measured, nothing is claimed.
| One voice turn, last word to first sound of the answer | 6.7 to 13 s | Measured 2026-10-14, three turns, client-side from India |
| Streamed answer, first token, latency objective | 1.5 to 3.5 s | Measured 2026-10-14, three runs, client-side from India |
| Support evaluation on our own documentation | 31 of 31 cases | The quickstart's own run, 2026-10-09 |
| Requests that returned HTTP 200 in the load test | 100% of 1,272 | Load test against the public API, 2026-10-12 |
Questions from customer operations and contact centres teams
As a turn-based assistant: it transcribes a question, answers in a sentence and speaks the reply on one key. Measured at 7 to 13 seconds a turn on 2026-10-14, which fits an IVR and a voicemail that answers, not yet a live conversation. The voice guide lists what would close the gap.
The model ends its answer with a marker when the customer asks for a person, is frustrated, or asks about their own account, decided in the same call at no extra cost. The conversation goes to your queue whole, with the customer as reply-to.
The design answers only from your passages, cites them, and says so when they do not settle the question. Off-topic requests are refused in one sentence, and an evaluation checks facts, refusals and handoffs after every change.
Through tools you define, under a policy that lists which tools a key may call. Reads run at once; writes wait for a person to approve, and every run is recorded with its tool calls.
Each response carries its cost in micro-dollars, the same figure Usage shows, so a conversation's cost is a sum of receipts. A spend cap per session stops one conversation at a number you choose.
To the models in your policy pool and nowhere else. Request content is kept for up to 30 days by default and not at all with zero retention; your own provider keys keep the call inside your existing contracts.
No. Telephony, the help desk and the CRM stay yours. The generation call goes to Inferbase with the model set to auto; the OpenAI SDK with the base URL changed is the whole integration.
The routing decision takes tens of milliseconds. A streamed answer's first token arrived in 1.5 to 3.5 seconds under the latency objective on 2026-10-14, after an embedding call of 0.6 to 2.5 seconds.
Whichever models in your policy pool win on the objective for each request: fast models for routine questions, strong ones for complaints. The response always names the model that served.
Put intelligence in the middle.
One gateway in front of every model, with your policies applied and every decision on record. Start on the free plan with 5,000 requests a month, no card required.