Voice & Agent Capabilities
Voice-engine roster verified against backend/internal/voices/routes.go. Function-tool list verified by grep against agent/agent_worker.py on origin/main, 2026-08-24. Multi-agent routing and latency figures are from the team's own internal driver-battery testing (see PROJECT-DOCS/ session logs), not independently re-verified in this pass — called out explicitly below.
Voice providers
Configurable per agent, exposed through the dashboard's voice picker (backing routes under /voices):
| Provider | What it gives you |
|---|---|
| Azure Neural (+ "full" variant) | Broad language coverage, low-latency neural TTS |
| ElevenLabs (+ library search, + add-from-library) | High-expressiveness voices; searchable public voice library |
| Cartesia | Low-latency streaming TTS |
| Inworld | Character/persona-style voices |
| Google Chirp | Google's neural TTS |
| Azure Realtime | Speech-to-speech, low-latency |
| OpenAI Realtime | Speech-to-speech, low-latency |
| Gemini Native | Speech-to-speech, low-latency |
Eight distinct engines behind one agent-configuration surface, spanning both traditional cascaded TTS and native speech-to-speech models — most competitors in this space commit to one or two TTS vendors as their "voice" story. For a Hebrew-first product specifically, this matters more than it would elsewhere: Hebrew TTS quality varies sharply by provider and having several to choose from (and fall back between) is a real, not cosmetic, difference.
Speech-to-text
Deepgram is the default STT engine across the platform, per internal policy — not gpt-4o-transcribe, which remains available but is not the default (there's an internal correction on record for a period when the phone lane defaulted to it and produced a measurably higher garbled-transcription rate on Hebrew calls). If you're integrating and can choose, prefer whatever the dashboard has set as default rather than pinning a specific STT engine yourself.
Multi-agent handoff
The agent runtime supports agent-to-agent handoff via a transfer_to_agent function tool — functionally the same category of feature as Vapi's "Squads" or Retell's "Agent Transfer" node: a call can move from one specialized agent to another mid-conversation rather than staying with a single monolithic prompt. Per the team's internal driver-battery results (not independently re-verified in this documentation pass), recent measurements on the production routing graph showed 16/16 successful routing decisions with 0 denials in the latest A/B round. Treat that figure as an internal test result, not an externally-audited benchmark.
Real-time barge-in (the caller interrupting the agent mid-sentence) is implemented and has been validated against live audio in internal testing — again, per internal test logs rather than independent verification here.
Agent function tools
agent/agent_worker.py carries exactly 15 methods decorated @function_tool — the callable surface an agent can invoke mid-call. (A naive grep -c "@function_tool" returns 17; two of those hits are prose, not decorators — one docstring reading "NOT a @function_tool, on purpose" and one comment. Counting only lines that actually begin with the decorator gives 15, which matches the figure in PROJECT-DOCS/DEVELOPER_PLATFORM.md.) All 15:
| Tool | Purpose |
|---|---|
check_availability | Calendar availability check |
schedule_appointment | Book an appointment |
reschedule_appointment | Move an existing appointment |
cancel_appointment | Cancel an appointment |
end_call | End the call cleanly |
leave_voicemail | Detected voicemail — leave a message and end |
detected_answering_machine | Voicemail/answering-machine detection signal |
send_sms | Send an SMS mid-call or as follow-up |
transfer_to_human | Cold transfer to a human |
warm_transfer_to_human | Warm transfer (context passed along) |
transfer_to_agent | Hand off to another AI agent |
search_knowledge | RAG lookup against the agent's knowledge base |
capture_lead | Record a lead from the conversation |
create_agent_from_conversation | Bootstrap a new agent configuration from a conversation |
analyze_campaign_call | Post-call campaign analysis |
Unlike Vapi's and Retell's tool systems, none of this is currently customer-programmable — there is no agent_tools table and no way for a customer to register their own custom function against an agent. Every tool above is hardcoded in the worker. Building that — a customer-defined tool surface — is a materially different and larger feature than anything else on this page: it combines customer-controlled outbound networking, SSRF exposure, live-call latency budgets, and untrusted model input in a way none of the existing hardcoded tools do. See the comparison document for how this stacks up against Vapi's Custom Tools / Retell's Custom Function / MCP node.
CRM function-tool integrations
Distinct from the platform-level Salesforce/HubSpot/Google integrations covered in Integrations, the agent itself can look up and write CRM data mid-call as part of a conversation, backed by the same OAuth connections.
Next
- Integrations
- Agents — configuring
voice,model,languagevia the API