vozo product shape
Product decision
vozo is the product and the customer workspace. getvozo.com is its domain, not a separate brand. Use plain descriptions for every capability; do not market the historical project names as products.
The interface should name the job a user wants done. Use Call cost and customer margin, Time spent waiting, Phone and route health, Real-world call checks, Call regression checks, Outbound call eligibility, Migration cost and plan, and Production readiness review.
Three ways to use vozo
1. Connect an existing agent. Connect a provider where a supported integration exists, import a configuration or export, or enter the agent details manually. Add call events and telephony data so vozo can calculate cost, latency, reliability, and phone health. Support for each provider and each data type should be explicit in the UI. 2. Build and operate in vozo. Create an agent in the platform, run it, and keep its configuration, calls, checks, and evidence in the same workspace. Imported and vozo-built agents use the same agent record and capability surfaces. 3. Use vozo through MCP. Connect an operator assistant, supported voice-agent host, or self-hosted client to vozo’s organization-scoped MCP endpoint. The tools inspect agents, call costs and margin, call timing, phone route health, configured real-call monitors, and regression run results. An authorized credential can also import agent configurations from a connected ElevenLabs, Vapi, or Retell account.
MCP is a tool interface, not a general agent-file upload mechanism. Use provider APIs or OAuth connections, explicit configuration imports, manual setup, and event ingestion for bringing agents and their data into vozo. ElevenLabs documents connecting external MCP servers to agents, while Vapi documents MCP tools for its assistants; available behavior varies by host and must be verified per integration (ElevenLabs MCP tools, Vapi MCP tools).
Shared workspace model
Use one organization, permission model, agent record, integration registry, and call history. Capabilities should read from the same evidence where possible and link their results back to the relevant agent, call, provider, or configuration change. A user should be able to connect an agent once, see which data is missing, and enable several capabilities without creating separate accounts or products.
| Capability area | User question |
|---|---|
| Call cost and customer margin | What does each call cost across speech, model, runtime, and telephony, and how does it affect customer margin? |
| Time spent waiting | Where does time pass between caller and agent turns? |
| Phone and route health | Which numbers, routes, or trunks are likely to fail? |
| Real-world call checks | Does the deployed agent answer promptly and produce usable audio over the phone network? |
| Call regression checks | Did a prompt, model, or configuration change break calls that used to work? |
| Outbound call eligibility | Is an outbound call allowed under the configured consent, list, hours, and disclosure rules? |
| Migration cost and plan | What are the cost and migration implications of moving between hosted and self-managed stacks? |
| Production readiness review | What evidence is missing or concerning across cost, latency, telephony, reliability, privacy, and operations? |
MCP boundaries
Treat the operator MCP and voice-agent runtime tools as distinct surfaces inside vozo:
- Operator MCP: tools are shipped at
<API_URL>/mcpwith expiring, revocable, organization-scoped credentials managed in organization settings. Read tools list connected and imported agents, costs, latency, phone-route health, real-call monitors, and regression runs. A credential created by a member with agent creation access can import agent configuration; no tool starts checks or calls. - Runtime MCP: expose only narrow actions needed during a call, such as checking outbound eligibility or retrieving a customer-specific fact. Use tenant and agent identity from trusted credentials, allowlists, timeouts, and audit records. Do not give a voice agent broad access to organization administration, billing, or all-call history by default.
- Provider compatibility: MCP clients connect to the shared endpoint using Streamable HTTP and a bearer credential. Host-specific setup still needs to be documented and confirmed for each provider. MCP imports supported agent configuration from connected providers; call history still needs to arrive through event ingestion or an integration.
Delivery order
1. Unify product identity, sign-up, navigation, and agent records. 2. Make connect/import and manual setup paths clear, with provider-specific coverage and missing-data states. 3. Surface capability results against shared call and agent evidence. 4. Add the operator MCP as a scoped inspection and external-agent import interface. 5. Add runtime tools individually after defining permission, privacy, latency, and failure behavior for each action. 6. Turn readiness into an in-product evidence report with findings and next steps, not a separate service offer.