Vapi vs Deepgram Voice Agent

Agent ops

1. ai-native userMy coding agent can provision a complete voice agent end to end — create the agent, attach a number, and place a call — through the API, CLI, or MCP without touching the dashboard

   weight 3 · round to Vapi
   Vapi✓fullprobed8/10

   Vapi documents API/SDK-based assistant creation, phone number attachment, and call placement (vapi-docs-1, vapi-docs-18, vapi-docs-19), a CLI for managing assistants, phone numbers, and calls entirely from the terminal (vapi-docs-2, vapi-docs-31, vapi-probe-rt-1 confirming keyless install/version), and an official MCP server exposing these same operations to any MCP-compatible agent, verified live and auth-gated in a runtime probe (vapi-docs-33, vapi-probe-rt-2). Together these three surfaces (API, CLI, MCP) cover the full agent-provision-number-call workflow without dashboard use. missing for 10: no single end-to-end hands-on trace showing one agent chaining create→attach→call purely via CLI/MCP/API in one session, and no independent (non-vendor) confirmation of the full workflow succeeding.

   • [claimed-docs] “const assistant = await vapi.assistant”
   • [claimed-docs] “Manage assistants, phone numbers, and calls from your terminal”
   • [claimed-docs] “Create a voice assistant, connect it to a phone number, and make your first calls.”
   • [claimed-docs] “In under 5 minutes, you'll create a voice assistant and start talking to it over the phone.”
   • [claimed-docs] “Build, test, and deploy voice AI applications without leaving your development environment.”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [probe] “official MCP server documented at https://docs.vapi.ai/sdk/mcp-server”
   • [probe] “official CLI documented at https://docs.vapi.ai/cli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vapi CLI installed via the vendor's one-liner (`curl -sSL https://vapi.ai/install.sh | bas…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialprobed5/10

   Deepgram documents agent creation via reusable agent configs (UUID-based), telephony connectivity for inbound/outbound calls, and a CLI with a built-in MCP server giving AI coding tools API access — the building blocks for programmatic provisioning exist. However, the evidence shows phone-call handling is done via a Twilio bridge (server code required) rather than a native Deepgram 'attach number/place call' API, and no doc shows the CLI or MCP server actually exposing agent-create + number-attach + call-place as a single end-to-end flow. Missing for 10: explicit CLI/MCP commands for provisioning a phone number and placing a call, and confirmation that this full workflow avoids external glue code/dashboard steps.

   • [claimed-docs] “Reusable Agent Configurations allow you to define and persist the agent block of your Settings message using the Deepgram API. Once created,…”
   • [claimed-docs] “Telephony: connect voice agents to phone networks for inbound and outbound calls.”
   • [claimed-docs] “The dg CLI includes a built-in MCP (Model Context Protocol) server that gives AI coding tools direct access to Deepgram APIs.”
   • [claimed-docs] “Twilio streams the call audio to your server, and your server bridges that audio to the Deepgram Voice Agent API, a single WebSocket that ru…”
   • [probe] “official MCP server documented at https://developers.deepgram.com/developer-tools/agentic-tools”
   • [probe] “official CLI documented at https://developers.deepgram.com/developer-tools/cli/getting-started”

   proof ↗⚑ flag

2. ai-native userThe platform's own AI helps me author agents — generating or improving prompts, flows, and test cases from a description

   weight 1 · round drawn
   Vapi—none0/10

   Evidence shows Vapi provides CLI, MCP server, tool/webhook infrastructure, and testing frameworks (Evals, Voice Test Suites), plus a Customer Support template, but nothing indicates the platform itself uses AI to generate or improve prompts, conversation flows, or test cases from a natural-language description — testing tools require manually defined mock conversations/scripts rather than AI-authored ones.

   • [claimed-docs] “Voice Test Suites enable you to test your AI voice agents through simulated phone conversations.”
   • [claimed-docs] “Evals is Vapi's AI agent testing framework that enables you to systematically test assistants and squads using mock conversations with autom…”
   • [claimed-docs] “Our AI tester calls your voice agent and follows a script that simulates real customer behavior.”
   • [claimed-docs] “you'll create mock conversations, define expected behaviors, and validate your agents work correctly before production”
   • [claimed-docs] “Select the down arrow next to Create Assistant, then choose Customer Support.”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Evidence covers building agents manually (prompting, function calling, reusable configs, MCP server for coding tools) but there is no mention of the platform's own AI generating or improving prompts, flows, or test cases from a description; the MCP server exposes Deepgram APIs to external coding assistants rather than being an AI author within the platform itself.

   • [claimed-docs] “Prompting: write system prompts that shape live-call behavior.”
   • [claimed-docs] “Reusable Agent Configurations allow you to define and persist the agent block of your Settings message using the Deepgram API. Once created,…”
   • [claimed-docs] “The dg CLI includes a built-in MCP (Model Context Protocol) server that gives AI coding tools direct access to Deepgram APIs.”
   • [probe] “official MCP server documented at https://developers.deepgram.com/developer-tools/agentic-tools”

   proof ↗⚑ flag

Build

1. developerBuild a working phone voice agent — prompt, voice, and phone number — and take my first live call within an hour

   weight 3 · round to Vapi
   Vapi✓fullcommunity9/10

   Docs explicitly walk through creating a voice assistant, connecting a phone number, and making a first call in under 5 minutes (vapi-docs-18, vapi-docs-19), with voice selection via the Voice Library (vapi-docs-8, vapi-docs-24) and dashboard-driven assistant creation with templates (vapi-docs-16); community evidence corroborates a working live-call demo (vapi-comm-1). Missing for 10: independent third-party benchmarking of the full 'within an hour' timing claim beyond vendor docs and a single anecdotal community comment.

   • [claimed-docs] “Create a voice assistant, connect it to a phone number, and make your first calls.”
   • [claimed-docs] “In under 5 minutes, you'll create a voice assistant and start talking to it over the phone.”
   • [claimed-docs] “Select the down arrow next to Create Assistant, then choose Customer Support.”
   • [claimed-docs] “The Voice Library in the Vapi Dashboard lists every voice available to your organization. Browse and preview voices there”
   • [claimed-docs] “Browse and preview voices there, then copy a voice's ID to use on an assistant.”
   • [community] “Called the demo number, sounds smooth! Good luck.”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialclaimed6/10

   Deepgram provides all core building blocks — prompting, voice/LLM selection, telephony via Twilio bridging, and a single WebSocket API — that together could plausibly get a developer to a first live call quickly. However, the telephony path requires standing up your own server to bridge Twilio audio to the Voice Agent WebSocket, which is nontrivial integration work rather than a turnkey 'phone number in one hour' flow, and there's no first-party quickstart or time-to-first-call benchmark cited. missing for 10: an end-to-end quickstart/tutorial demonstrating full setup within an hour, evidence of a managed/no-code telephony number provisioning path, and independent hands-on confirmation of setup speed.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “Telephony: connect voice agents to phone networks for inbound and outbound calls.”
   • [claimed-docs] “Prompting: write system prompts that shape live-call behavior.”
   • [claimed-docs] “Supported LLM providers | Parameter | open_ai | anthropic | aws_bedrock | google | groq | nvidia”
   • [claimed-docs] “Twilio streams the call audio to your server, and your server bridges that audio to the Deepgram Voice Agent API, a single WebSocket that ru…”
   • [claimed-docs] “That includes barge-in, the ability to talk over the agent and have it stop instantly.”

   proof ↗⚑ flag

2. developerRun conversations in multiple languages, including detecting and switching language mid-call

   weight 2 · round to Deepgram Voice Agent
   Vapi—none0/10

   The evidence pack covers CLI, MCP server, tools, voices, compliance, and testing, but contains no mention of multi-language support, language detection, or mid-call language switching capabilities. Absence of evidence for this applicable axis (multilingual voice agents are a fair capability to expect from a voice AI platform) means it must be judged 'none'. missing for 10: any mention of multi-language conversation support, language auto-detection, or mid-call language switching features.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed5/10

   Deepgram's docs confirm multilingual voice agent support, noting that STT and TTS model choices must be configured for the target language (deepgram-docs-10), but the evidence pack does not explicitly document automatic language detection or dynamic switching mid-call — only static multilingual configuration is described. Missing for 10: explicit documentation of automatic language detection, mid-call language switching mechanics, and independent/hands-on confirmation of this behavior in production.

   • [claimed-docs] “A multilingual voice agent has two model decisions: which STT model transcribes the user, and which TTS model speaks the agent.”

   proof ↗⚑ flag

3. founderDesign multi-step conversation flows in a visual builder with branching, states, and handoffs without writing code

   weight 2 · round drawn
   Vapi—none0/10

   Evidence covers Vapi's assistant configuration, tools, CLI, MCP server, voices, and testing, but there is no mention of a visual flow builder with branching, states, or handoffs — Vapi appears configuration/code-driven (assistant config, function tools, webhooks) rather than a no-code visual conversation designer.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   All evidence describes a code/API-first architecture (WebSocket connections, JSON Settings messages, system prompts, function calling, CLI/SDK) rather than a visual no-code builder; there is no mention of a drag-and-drop flow designer, branching UI, or state-machine editor. missing for 10: any visual builder UI, no-code branching/state design, or drag-and-drop handoff configuration.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “Multi-Agent Architecture: orchestrate multiple specialized agents that hand off based on context, intent, or domain.”
   • [claimed-docs] “Reusable Agent Configurations allow you to define and persist the agent block of your Settings message using the Deepgram API. Once created,…”
   • [claimed-docs] “Prompting: write system prompts that shape live-call behavior.”
   • [claimed-docs] “Supported LLM providers | Parameter | open_ai | anthropic | aws_bedrock | google | groq | nvidia”

   proof ↗⚑ flag

Personalization

1. developerInject dynamic variables and per-caller context at call time so each conversation is personalized

   weight 2 · round to Deepgram Voice Agent
   Vapi—none0/10

   The evidence pack covers assistant creation, tools/webhooks, CLI, MCP server, voices, and testing, but contains no documentation of variable injection, assistantOverrides, or per-caller context personalization at call time. Missing for 10: docs on dynamic variable substitution (e.g., {{variableName}} templating), call-time overrides/metadata injection, and any example showing per-caller personalization.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed6/10

   Deepgram supports prompting, reusable agent configs (passed at call time via UUID), function calling, and mid-call message injection, which together allow injecting per-call context/variables into agent behavior; A/B testing of configs also implies runtime parameterization. However there is no explicit documented mechanism for templated dynamic variables (e.g., {{caller_name}}) or a dedicated per-caller context API akin to other platforms. missing for 10: explicit dynamic variable templating syntax, dedicated per-caller metadata injection API, hands-on example of personalizing a call with caller-specific data.

   • [claimed-docs] “Reusable Agent Configurations allow you to define and persist the agent block of your Settings message using the Deepgram API. Once created,…”
   • [claimed-docs] “Prompting: write system prompts that shape live-call behavior.”
   • [claimed-docs] “Inject agent message | Mid-call | InjectAgentMessage | Makes the agent speak a specific line”
   • [claimed-docs] “A/B testing voices or prompts — Run two configurations in parallel and measure conversion, CSAT, or containment rate to pick a winner—no cod…”
   • [claimed-docs] “In the context of Deepgram Voice Agents, function calling enables your agent to perform tasks during a live conversation.”

   proof ↗⚑ flag

2. developerGround the agent on my documents with a built-in knowledge base or RAG so it answers from my content

   weight 2 · round drawn
   Vapi—none0/10

   Vapi is a voice-agent platform focused on assistants, phone numbers, custom webhook tools, and telephony/testing; the evidence pack shows no built-in knowledge base or RAG feature for grounding assistants on uploaded documents. Custom tools/webhooks could be used to build a workaround, but no document ingestion or retrieval capability is documented.

   • [claimed-docs] “Create your own webhook-based tools to extend assistant capabilities”
   • [claimed-docs] “This guide shows you how to create custom tools, including Function Tools, for your Vapi assistants.”
   • [claimed-docs] “Custom tools that you create... interact with your systems via webhooks”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence pack covers architecture, function calling, multi-agent handoff, telephony, prompting, and LLM providers, but nowhere documents a built-in knowledge base or RAG feature for grounding the agent on user documents. Function calling ([deepgram-docs-2]) could theoretically be wired to an external retrieval system, but that is not the same as a built-in KB/RAG capability, and no such feature is described.

   • [claimed-docs] “In the context of Deepgram Voice Agents, function calling enables your agent to perform tasks during a live conversation.”
   • [claimed-docs] “Multi-Agent Architecture: orchestrate multiple specialized agents that hand off based on context, intent, or domain.”
   • [claimed-docs] “Prompting: write system prompts that shape live-call behavior.”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Deepgram Voice Agent
   Vapi✓fullprobed8/10

   Vapi confirms an llms.txt file exists and is served at docs.vapi.ai/llms.txt (HTTP 200), explicitly instructing agents on how to fetch clean Markdown per page, which directly satisfies the story. missing for 10: no independent/community corroboration of agents actually consuming llms.txt in practice, only first-party probe evidence.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.vapi.ai/llms.txt # Vapi ## Instructions for AI Agents - For clean Markdown of any page, append `.…”

   proof ↗⚑ flag

   Deepgram Voice Agent✓fullprobed9/10

   Direct probe confirms llms.txt exists at developers.deepgram.com/llms.txt (HTTP 200) with explicit AI-agent instructions, and docs pages support .md suffix for clean markdown retrieval, both verified by live probes. missing for 10: no independent third-party confirmation of an agent actually consuming this in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.deepgram.com/llms.txt # Deepgram's Docs ## Instructions for AI Agents - For clean Markdown …”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.deepgram.com/docs/voice-agent.md > For clean Markdown of any page, append .md to the page URL.…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Vapi~partialprobed6/10

   Vapi ships an official CLI (vapi-docs-2/31/32, confirmed working keylessly in vapi-probe-rt-1) that can manage assistants, calls, and forward webhooks, which supports scripted/CI-style usage, and SDKs/REST APIs imply headless programmatic calls. However there is no explicit CI/automation documentation, no examples of running in a pipeline, and the MCP server requires bearer-key auth (vapi-probe-rt-2) which is unaddressed for CI contexts. missing for 10: explicit CI/automation examples or docs, non-interactive auth/service-account flow for CI, evidence of headless voice-testing/evals running in a pipeline.

   • [claimed-docs] “Manage assistants, phone numbers, and calls from your terminal”
   • [claimed-docs] “Build, test, and deploy voice AI applications without leaving your development environment.”
   • [claimed-docs] “The CLI auto-detects your tech stack and sets up everything you need.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vapi CLI installed via the vendor's one-liner (`curl -sSL https://vapi.ai/install.sh | bas…”
   • [claimed-docs] “Evals is Vapi's AI agent testing framework that enables you to systematically test assistants and squads using mock conversations with autom…”
   • [claimed-docs] “you'll create mock conversations, define expected behaviors, and validate your agents work correctly before production”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialprobed6/10

   The Voice Agent is a WebSocket API (no GUI dependency) and Deepgram ships a terminal-based `dg` CLI for scripting Deepgram operations (transcribe, synthesize, manage account) which is inherently automatable/CI-friendly, and temporary tokens support secure automated auth. However, there is no explicit documentation of running the Voice Agent itself headlessly in CI pipelines, no CI/CD examples, and the CLI's primary use-cases described are transcription/synthesis rather than orchestrating full voice-agent sessions programmatically. Missing for 10: dedicated CI/headless automation guide for Voice Agent sessions, example CI pipeline configs, and confirmation the CLI can drive the Agent API end-to-end rather than just STT/TTS.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “The dg CLI lets you transcribe files, stream live audio, synthesize speech, analyze text, and manage your Deepgram account from the terminal…”
   • [claimed-docs] “Unlike traditional API keys, temporary tokens are ideal for real-time applications requiring secure, temporary access to Deepgram's services…”
   • [probe] “official CLI documented at https://developers.deepgram.com/developer-tools/cli/getting-started”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Vapi—none0/10

   The evidence shows Vapi exposes its own APIs as an MCP server (so external MCP clients like Claude Desktop can control Vapi), but this is the opposite direction from the story — there's no evidence that Vapi assistants can consume/plug-in external MCP servers to use their tools within a conversation. Vapi's tool docs describe webhook-based custom tools and OpenAI-style function calling only, with no mention of MCP-server ingestion.

   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [claimed-docs] “Create your own webhook-based tools to extend assistant capabilities”
   • [claimed-docs] “Custom tools that you create... interact with your systems via webhooks”
   • [probe] “official MCP server documented at https://docs.vapi.ai/sdk/mcp-server”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Deepgram Voice Agent supports function calling for custom tool use, but there is no evidence the Voice Agent can act as an MCP client to consume external MCP servers' tools. The only MCP-related evidence is a built-in MCP *server* in the `dg` CLI that lets coding tools access Deepgram's APIs — the opposite direction of the story.

   • [claimed-docs] “In the context of Deepgram Voice Agents, function calling enables your agent to perform tasks during a live conversation.”
   • [claimed-docs] “The dg CLI includes a built-in MCP (Model Context Protocol) server that gives AI coding tools direct access to Deepgram APIs.”
   • [probe] “official MCP server documented at https://developers.deepgram.com/developer-tools/agentic-tools”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Vapi
   Vapi✓fullprobed9/10

   Vapi ships an official hosted MCP server (mcp.vapi.ai) exposing its assistant/phone/call APIs as MCP tools for any MCP-compatible agent (Claude Desktop, agent frameworks), documented in first-party docs and confirmed live via a runtime probe (401 bearer-key gate exactly as documented). Missing for 10: independent/community hands-on testimonials specifically about using the MCP server (community evidence only covers general demo/founder trivia, not MCP usage).

   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [probe] “official MCP server documented at https://docs.vapi.ai/sdk/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”

   proof ↗⚑ flag

   Deepgram Voice Agent✓fullprobed7/10

   Deepgram ships an official MCP server (bundled in the dg CLI) that lets AI coding tools/agents connect directly to Deepgram's APIs, confirmed both in docs and via a dedicated agentic-tools page. This directly satisfies the story of connecting an agent to Deepgram via an official MCP server. Missing for 10: independent/hands-on verification that the MCP server works reliably in practice, and more detail on which Voice Agent capabilities specifically are exposed through it.

   • [claimed-docs] “The dg CLI includes a built-in MCP (Model Context Protocol) server that gives AI coding tools direct access to Deepgram APIs.”
   • [probe] “official MCP server documented at https://developers.deepgram.com/developer-tools/agentic-tools”
   • [claimed-docs] “The dg CLI lets you transcribe files, stream live audio, synthesize speech, analyze text, and manage your Deepgram account from the terminal…”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Vapi
   Vapi✓fullprobed9/10

   Vapi ships a documented official CLI for managing assistants, phone numbers, and calls from the terminal, with webhook forwarding, org/environment switching, and tech-stack auto-detection, and this was independently verified in a runtime probe (successful install and `--version` output). missing for 10: no independent third-party review or community discussion of the CLI's day-to-day usage beyond the vendor docs and single install probe.

   • [claimed-docs] “Manage assistants, phone numbers, and calls from your terminal”
   • [claimed-docs] “vapi listen --forward-to localhost:3000/webhook”
   • [claimed-docs] “Switch between organizations and environments seamlessly”
   • [claimed-docs] “Forward webhooks to your local server for debugging”
   • [claimed-docs] “Build, test, and deploy voice AI applications without leaving your development environment.”
   • [claimed-docs] “The CLI auto-detects your tech stack and sets up everything you need.”
   • [probe] “official CLI documented at https://docs.vapi.ai/cli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vapi CLI installed via the vendor's one-liner (`curl -sSL https://vapi.ai/install.sh | bas…”

   proof ↗⚑ flag

   Deepgram Voice Agent✓fullprobed8/10

   Deepgram ships an official 'dg' CLI for transcribing files, streaming audio, synthesizing speech, and managing accounts from the terminal, and it even embeds an MCP server for AI coding tools, directly supporting agentic/AI-native workflows. Missing for 10: independent/hands-on corroboration beyond first-party docs and more detail on CLI coverage of Voice Agent-specific features.

   • [claimed-docs] “The dg CLI lets you transcribe files, stream live audio, synthesize speech, analyze text, and manage your Deepgram account from the terminal…”
   • [claimed-docs] “The dg CLI includes a built-in MCP (Model Context Protocol) server that gives AI coding tools direct access to Deepgram APIs.”
   • [probe] “official CLI documented at https://developers.deepgram.com/developer-tools/cli/getting-started”
   • [probe] “official MCP server documented at https://developers.deepgram.com/developer-tools/agentic-tools”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Vapi✓fullprobed9/10

   Vapi ships a documented public API/SDK (assistant management, calls, tools), a CLI for terminal-driven workflows, and a hosted MCP server exposing the API as tools, all confirmed by runtime probes (CLI installs and runs, MCP endpoint live and auth-gated as documented). This directly satisfies programmatic/AI-native control via a documented public interface. Missing for 10: no independent third-party developer report deeply exercising the API beyond docs/probes.

   • [claimed-docs] “const assistant = await vapi.assistant”
   • [claimed-docs] “Manage assistants, phone numbers, and calls from your terminal”
   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.vapi.ai/llms.txt # Vapi ## Instructions for AI Agents - For clean Markdown of any page, append `.…”
   • [probe] “official MCP server documented at https://docs.vapi.ai/sdk/mcp-server”
   • [probe] “official CLI documented at https://docs.vapi.ai/cli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vapi CLI installed via the vendor's one-liner (`curl -sSL https://vapi.ai/install.sh | bas…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”

   proof ↗⚑ flag

   Deepgram Voice Agent✓fullprobed9/10

   Deepgram publishes a documented public API (WebSocket-based Voice Agent API plus OpenAPI spec confirmed live), extensive docs covering endpoints, function calling, LLM providers, telephony, and auth, and even a CLI/MCP server for programmatic/agentic access, making it clearly drivable by an AI-native user. Missing for 10: independent third-party corroboration of API usage beyond vendor docs.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.deepgram.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “The dg CLI lets you transcribe files, stream live audio, synthesize speech, analyze text, and manage your Deepgram account from the terminal…”
   • [claimed-docs] “The dg CLI includes a built-in MCP (Model Context Protocol) server that gives AI coding tools direct access to Deepgram APIs.”
   • [probe] “official CLI documented at https://developers.deepgram.com/developer-tools/cli/getting-started”
   • [claimed-docs] “Unlike traditional API keys, temporary tokens are ideal for real-time applications requiring secure, temporary access to Deepgram's services…”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Deepgram Voice Agent
   Vapi~partialprobed3/10

   Vapi's enterprise docs mention Role Based Access Control (RBAC) and SSO, implying some access-scoping capability at the org level, and its MCP server/API require bearer API keys — but there is no documented mechanism for issuing per-agent, least-privilege scoped API keys or tokens tailored to a specific agent's permissions. missing for 10: explicit scoped API key creation/management UI or API, documentation of key-level permission granularity, and independent confirmation that RBAC restricts agent credentials rather than just human dashboard users.

   • [claimed-docs] “Single Sign On (SSO) supported for Okta, Azure AD, SAML, and OIDC * Role Based Access Control (RBAC)”
   • [claimed-docs] “Single Sign On (SSO) supported for Okta, Azure AD, SAML, and OIDC”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialclaimed4/10

   Deepgram documents temporary, short-lived tokens as an alternative to traditional API keys for secure, limited-duration access (deepgram-docs-14), which partially satisfies a least-privilege credential story, but there is no evidence of granular scopes/permissions (e.g., restricting a key to specific endpoints or agent capabilities) or role-based access control for agents. Missing for 10: documented scope/permission granularity, per-agent key restriction, and evidence of enforcement/verification of least-privilege in practice.

   • [claimed-docs] “Unlike traditional API keys, temporary tokens are ideal for real-time applications requiring secure, temporary access to Deepgram's services…”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Vapi
   Vapi✓fullprobed8/10

   Vapi documents an official JS/TS SDK usage pattern, official CLI (probe-confirmed installed and runnable), and official MCP server (probe-confirmed live and auth-gated), all clearly aimed at AI-native/agentic developer workflows including IDE assistant integration (Cursor/Windsurf/VSCode). missing for 10: independent third-party corroboration of SDK code quality and coverage across multiple languages beyond the docs snippets.

   • [claimed-docs] “const assistant = await vapi.assistant”
   • [claimed-docs] “Manage assistants, phone numbers, and calls from your terminal”
   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [claimed-docs] “Your IDE's AI assistant (Cursor, Windsurf, VSCode) gains complete, accurate knowledge of Vapi's APIs and best practices. No more hallucinate…”
   • [probe] “official MCP server documented at https://docs.vapi.ai/sdk/mcp-server”
   • [probe] “official CLI documented at https://docs.vapi.ai/cli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vapi CLI installed via the vendor's one-liner (`curl -sSL https://vapi.ai/install.sh | bas…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialprobed5/10

   Evidence shows an official 'Browser Agent SDK' with composable packages, plus an OpenAPI spec, CLI, and MCP server for developer tooling, indicating some official SDK/build tooling exists. However, evidence does not mention broader server-side/language SDKs (Python, Node, Go, etc.) commonly expected for building agentic applications, nor independent corroboration of SDK quality. Missing for 10: multi-language SDK documentation, independent/hands-on developer reports, broader agentic build examples beyond browser.

   • [claimed-docs] “Browser Agent SDK: add voice AI to any web application via four composable packages.”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.deepgram.com/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://developers.deepgram.com/developer-tools/cli/getting-started”
   • [probe] “official MCP server documented at https://developers.deepgram.com/developer-tools/agentic-tools”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Vapi
   Vapi✓fullclaimed7/10

   Vapi supports webhook-based events via Server URL (tool-calls messages), custom webhook tools, and CLI webhook forwarding for local debugging, giving AI-native users a documented event subscription mechanism. missing for 10: independent/hands-on confirmation of webhook delivery reliability, a full event-type catalog/schema, and signature/verification documentation.

   • [claimed-docs] “Create your own webhook-based tools to extend assistant capabilities”
   • [claimed-docs] “When tools are triggered, your Server URL receives a `tool-calls` message”
   • [claimed-docs] “Vapi supports OpenAI-style tool/function calling. Assistants can ping your server to perform actions.”
   • [claimed-docs] “Forward webhooks to your local server for debugging”
   • [claimed-docs] “Custom tools that you create... interact with your systems via webhooks”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence pack shows Deepgram Voice Agent operates via a persistent WebSocket connection for real-time audio streaming, not webhook-based event subscription; no documentation mentions webhooks for event notifications (e.g., call completion, transcript ready, errors). Absence of evidence for an applicable capability yields 'none'.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Vapi—none0/10

   Evidence covers building/testing assistants (Evals, Voice Test Suites), CLI/MCP management tools, and tool-calling, but nothing describes the product itself surfacing AI-generated insights or suggestions derived from a user's own call/usage data (e.g., analytics dashboards with AI-generated recommendations).

   ⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence pack covers Deepgram Voice Agent's API capabilities (function calling, multi-agent orchestration, telephony, LLM providers, prompting) but contains no mention of an in-product analytics dashboard, conversation insights, or AI-generated suggestions derived from a user's own data. While such a feature (e.g., call analytics/insights) is plausible for a voice AI platform, no evidence shows Deepgram surfaces this.

   ⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Vapi
   Vapi~partialclaimed4/10

   Vapi assistants operate autonomously once a call starts—handling conversation flow, invoking custom tools via webhooks, and triggering server-side automations without further human input (vapi-docs-6, vapi-docs-17, vapi-docs-23, vapi-docs-34). However, this autonomy is scoped to an active call session; there is no evidence of scheduled/cron-style background jobs or agent loops that run independently of a triggered call or user interaction. Missing for 10: evidence of scheduled/background triggers outside live calls, persistent autonomous task queues, or proactive (non-call-triggered) automation runs.

   • [claimed-docs] “Create your own webhook-based tools to extend assistant capabilities”
   • [claimed-docs] “When tools are triggered, your Server URL receives a `tool-calls` message”
   • [claimed-docs] “Vapi supports OpenAI-style tool/function calling. Assistants can ping your server to perform actions.”
   • [claimed-docs] “Custom tools that you create... interact with your systems via webhooks”
   • [claimed-docs] “This guide shows you how to create custom tools, including Function Tools, for your Vapi assistants.”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Vapi—none0/10

   Vapi's docs describe building and configuring voice AI assistants for end-users (phone/web calls, tools, testing) and even an MCP server/CLI for managing those assistants, but there is no evidence of a built-in AI assistant/copilot inside the Vapi product itself that the AI-native user can delegate platform tasks to (e.g., an in-dashboard copilot that configures assistants or writes tools for you). The CLI mentions external IDE assistants (Cursor/Windsurf) gaining API knowledge, but that's a third-party tool, not a built-in in-product assistant.

   • [claimed-docs] “Your IDE's AI assistant (Cursor, Windsurf, VSCode) gains complete, accurate knowledge of Vapi's APIs and best practices. No more hallucinate…”
   • [claimed-docs] “Manage assistants, phone numbers, and calls from your terminal”
   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Deepgram Voice Agent
   Vapi✓fullprobed7/10

   Vapi exposes an official MCP server that lets any MCP-compatible AI assistant (e.g. Claude Desktop) manage assistants, phone numbers, and calls via natural-language tool calls, and this endpoint is confirmed live and auth-gated in a runtime probe. It also ships a CLI and llms.txt docs optimized for AI agents to operate it. Missing for 10: no first-party evidence of a built-in chat/NL command console inside the Vapi product itself (beyond MCP/CLI proxies), and no independent hands-on report of an agent successfully performing multi-step tasks via MCP.

   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [claimed-docs] “Your IDE's AI assistant (Cursor, Windsurf, VSCode) gains complete, accurate knowledge of Vapi's APIs and best practices. No more hallucinate…”
   • [probe] “official MCP server documented at https://docs.vapi.ai/sdk/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vapi CLI installed via the vendor's one-liner (`curl -sSL https://vapi.ai/install.sh | bas…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.vapi.ai/llms.txt # Vapi ## Instructions for AI Agents - For clean Markdown of any page, append `.…”

   proof ↗⚑ flag

   Deepgram Voice Agent✓fullclaimed8/10

   Deepgram Voice Agent is fundamentally a conversational system: users interact via natural spoken language, and the agent supports function calling to perform tasks, live prompting to shape behavior, and mid-call message injection—all driven by natural-language conversation rather than rigid commands. This is core, well-documented functionality (docs-2, docs-7, docs-11) directly matching the story's intent for an ai-native/agentic persona. Missing for 10: independent/hands-on validation of natural-language command accuracy and no evidence of complex multi-turn command chaining reliability from third-party sources.

   • [claimed-docs] “In the context of Deepgram Voice Agents, function calling enables your agent to perform tasks during a live conversation.”
   • [claimed-docs] “Prompting: write system prompts that shape live-call behavior.”
   • [claimed-docs] “Inject agent message | Mid-call | InjectAgentMessage | Makes the agent speak a specific line”
   • [claimed-docs] “Multi-Agent Architecture: orchestrate multiple specialized agents that hand off based on context, intent, or domain.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Vapi—none0/10

   The evidence pack shows static markdown documentation, code snippets, a CLI, and an MCP server, but no interactive API reference or runnable/try-it-out examples are described anywhere in the docs pages cited.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   Evidence shows an OpenAPI spec exists and docs pages are available as clean Markdown, but there is no evidence of an interactive API reference with runnable/try-it-now examples (e.g., embedded playground, live code execution, or Swagger/Postman-style explorer). Missing for 10: interactive explorer UI, runnable/executable code snippets, live request/response testing.

   • [probe] “PROBE openapi: HTTP 200 at https://developers.deepgram.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.deepgram.com/llms.txt # Deepgram's Docs ## Instructions for AI Agents - For clean Markdown …”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.deepgram.com/docs/voice-agent.md > For clean Markdown of any page, append .md to the page URL.…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Deepgram Voice Agent
   Vapi—none0/10

   The evidence pack covers Vapi's CLI, MCP server, docs, and SDKs, but no citation mentions an OpenAPI spec, API reference schema, or any machine-readable spec file available for download. This is a fair axis for an API-first product, but no supporting evidence exists in the pack.

   ⚑ flag

   Deepgram Voice Agent✓fullprobed9/10

   A probe confirms Deepgram publishes a machine-readable OpenAPI spec at openapi.json containing the 'openapi' key, directly satisfying the story. Missing for 10: no first-party docs page explicitly announcing/describing the OpenAPI spec's coverage or versioning.

   • [probe] “PROBE openapi: HTTP 200 at https://developers.deepgram.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Vapi
   Vapi✓fullclaimed7/10

   Vapi offers dedicated Voice Test Suites (AI tester simulating conversations) and an Evals framework explicitly for creating mock conversations to 'validate your agents work correctly before production,' plus CLI webhook forwarding to localhost for local development/debugging — all separate from live production calls. Missing for 10: explicit vendor use of the term 'sandbox environment' and independent/hands-on verification that test runs are fully isolated from production data.

   • [claimed-docs] “Voice Test Suites enable you to test your AI voice agents through simulated phone conversations.”
   • [claimed-docs] “Evals is Vapi's AI agent testing framework that enables you to systematically test assistants and squads using mock conversations with autom…”
   • [claimed-docs] “Our AI tester calls your voice agent and follows a script that simulates real customer behavior.”
   • [claimed-docs] “you'll create mock conversations, define expected behaviors, and validate your agents work correctly before production”
   • [claimed-docs] “Forward webhooks to your local server for debugging”
   • [claimed-docs] “Build, test, and deploy voice AI applications without leaving your development environment.”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   No evidence pack item mentions a sandbox environment, test/dev API keys, or a way to test without touching production data or usage; only production endpoints, EU endpoint, and opt-out flags are documented. Missing for 10: sandbox/test-mode environment, documentation of non-production keys or test credits, any guidance on isolating test traffic from production data.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Vapi—none0/10

   No evidence pack item mentions API versioning scheme, version numbers in endpoints, or any documented deprecation/sunset policy for Vapi's APIs; the docs cover features (CLI, MCP, tools, voices) but not API lifecycle governance.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence pack shows extensive Voice Agent API documentation, an OpenAPI spec, CLI, and MCP server, but contains no mention of API versioning scheme or a documented deprecation policy for the Voice Agent API.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Vapi—none0/10

   The evidence pack documents CLI/SDK/MCP management of individual assistants, phone numbers, and calls, but nowhere shows bulk/batch endpoints or commands (e.g., batch-create, bulk-update, mass-delete) for operating across many items at once.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Vapi~partialclaimed5/10

   Vapi supports event-driven server-side tools/webhooks that fire on call events (tool-calls messages, server-url events) which act as a rule-trigger mechanism, but this is scoped to voice-call events only rather than a general-purpose automation/rules engine for arbitrary triggers. missing for 10: a documented general condition/trigger-action rules engine spanning non-call events, cross-system automation, or independent hands-on evidence of complex conditional automation chains.

   • [claimed-docs] “When tools are triggered, your Server URL receives a `tool-calls` message”
   • [claimed-docs] “Vapi supports OpenAI-style tool/function calling. Assistants can ping your server to perform actions.”
   • [claimed-docs] “Custom tools that you create... interact with your systems via webhooks”
   • [claimed-docs] “Create your own webhook-based tools to extend assistant capabilities”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialclaimed5/10

   Deepgram Voice Agent supports function calling that lets the agent trigger actions during a live conversation, and features like InjectAgentMessage and multi-agent handoff suggest some event-driven behavior, but this is developer-defined logic (via function calling code) rather than a declarative rules engine for automatically triggering actions on arbitrary events. missing for 10: a documented rules/trigger engine (if-this-then-that style), event subscription system, or automation workflow builder distinct from manual function-calling code.

   • [claimed-docs] “In the context of Deepgram Voice Agents, function calling enables your agent to perform tasks during a live conversation.”
   • [claimed-docs] “Multi-Agent Architecture: orchestrate multiple specialized agents that hand off based on context, intent, or domain.”
   • [claimed-docs] “Inject agent message | Mid-call | InjectAgentMessage | Makes the agent speak a specific line”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Vapi—none0/10

   No evidence in the pack shows Vapi supports scheduling recurring jobs, workflows, or automated recurring calls/tasks — the docs cover assistants, tools, CLI, MCP server, testing, and voice customization but nothing about cron-like scheduling or recurring automation triggers.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Deepgram Voice Agent
   Vapi—none0/10

   Vapi's docs cover assistant creation, tools, CLI, MCP server, and testing/evals, but there is no mention of versioning assistant configurations, review/approval workflows, or rollback to prior versions of automations. No evidence pack item addresses version history or rollback capability.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed3/10

   Deepgram's Reusable Agent Configurations let you persist a named agent config and reference it by UUID, and support A/B testing two configs in parallel, which is adjacent to versioning, but there is no documented version history, diff/review workflow, or explicit rollback mechanism. missing for 10: version history tracking, review/approval workflow, explicit rollback capability, changelog or diffing between config versions.

   • [claimed-docs] “Reusable Agent Configurations allow you to define and persist the agent block of your Settings message using the Deepgram API. Once created,…”
   • [claimed-docs] “A/B testing voices or prompts — Run two configurations in parallel and measure conversion, CSAT, or containment rate to pick a winner—no cod…”

   proof ↗⚑ flag

Compliance

1. founderMeet call-recording consent and disclosure obligations with per-call recording controls and configurable data retention

   weight 2 · round to Deepgram Voice Agent
   Vapi—none0/10

   The evidence pack covers HIPAA toggle, SSO/RBAC, testing/evals, and CLI/MCP tooling, but contains no mention of call-recording enable/disable controls, consent disclosure features, or configurable data retention policies for call recordings — a fair and applicable axis for a voice-calling platform.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed4/10

   Deepgram documents general data-privacy controls (per-request opt-out from retention via mip_opt_out, EU-region processing endpoint) that touch on data retention/residency, but there is no explicit documentation of per-call recording toggles, consent/disclosure workflows, or configurable retention windows tied to call recordings specifically. Missing for 10: explicit per-call recording enable/disable controls, documented retention period configuration for stored call audio/transcripts, and consent/disclosure feature support.

   • [claimed-docs] “Opt out per request with mip_opt_out=true. Opted-out requests are not retained”
   • [claimed-docs] “For customers requiring data processing within the European Union, Deepgram provides an EU-specific endpoint at api.eu.deepgram.com.”

   proof ↗⚑ flag

2. platform-engineerRun regulated workloads with HIPAA/BAA support, SOC 2, and data-residency options

   weight 2 · round to Vapi
   Vapi~partialclaimed5/10

   Vapi documents HIPAA compliance toggle in the dashboard and enterprise SSO/RBAC, indicating some regulated-workload support, but evidence lacks explicit SOC 2 certification details, BAA execution process, or data-residency region options. missing for 10: SOC 2 report/certification evidence, explicit BAA process details, data-residency/region selection options, independent audit confirmation.

   • [claimed-docs] “HIPAA compliance can be ensured by turning on HIPAA compliance in the Dashboard.”
   • [claimed-docs] “Single Sign On (SSO) supported for Okta, Azure AD, SAML, and OIDC * Role Based Access Control (RBAC)”
   • [claimed-docs] “Single Sign On (SSO) supported for Okta, Azure AD, SAML, and OIDC”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialclaimed4/10

   Evidence shows EU data-residency endpoint and an opt-out from data retention/training, indicating some compliance/trust infrastructure, but there is no mention of HIPAA/BAA support or SOC 2 certification anywhere in the pack. missing for 10: HIPAA/BAA documentation, SOC 2 attestation evidence, broader regional residency options beyond EU.

   • [claimed-docs] “Opt out per request with mip_opt_out=true. Opted-out requests are not retained”
   • [claimed-docs] “For customers requiring data processing within the European Union, Deepgram provides an EU-specific endpoint at api.eu.deepgram.com.”

   proof ↗⚑ flag

Scale

1. platform-engineerSee documented concurrency limits and scale to many simultaneous calls without manual capacity begging

   weight 2 · round drawn
   Vapi—none0/10

   No evidence pack items document concurrency limits, per-org call caps, autoscaling behavior, or capacity-request processes; the docs cover CLI, MCP server, tools, voices, and enterprise SSO but nothing about simultaneous-call scaling limits or how to raise them.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   No evidence pack item mentions concurrency limits, rate limits, per-account call caps, scaling guidance, or capacity request processes for the Voice Agent API; the docs cover architecture, features, and integrations but nothing about scale/concurrency documentation.

   ⚑ flag

Self host

1. platform-engineerSelf-host the voice agent runtime from open-source code on my own infrastructure

   weight 3 · round drawn
   Vapi—none0/10

   Vapi is presented entirely as a hosted SaaS platform with a CLI, MCP server, and dashboard for managing cloud-hosted assistants; there is no evidence of open-source runtime code or any self-hosting option. One community note even references that a different product (pipecat by daily.co) is the open-source alternative, implicitly contrasting with Vapi's closed hosted model.

   • [community] “Vapi is also built on media framework by daily.co. They have an open source version of voice ai called pipecat.”
   • [claimed-docs] “Build, test, and deploy voice AI applications without leaving your development environment.”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Deepgram Voice Agent is a hosted, cloud-only API accessed via WebSocket; nothing in the evidence indicates open-source runtime code that can be self-hosted on customer infrastructure. All references point to Deepgram-hosted endpoints (api.deepgram.com, api.eu.deepgram.com) and a CLI/SDK for calling the cloud service, not deploying the runtime itself.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “For customers requiring data processing within the European Union, Deepgram provides an EU-specific endpoint at api.eu.deepgram.com.”
   • [claimed-docs] “Twilio streams the call audio to your server, and your server bridges that audio to the Deepgram Voice Agent API, a single WebSocket that ru…”

   proof ↗⚑ flag

Latency

1. platform-engineerSee documented end-to-end voice latency numbers or tuning guidance backing the platform's speed claims

   weight 3 · round to Vapi
   Vapi~partialclaimed3/10

   Vapi's docs mention that 'Ultra Fast' vs 'High Intelligence' model settings trade off latency, giving conceptual tuning guidance, but there are no documented end-to-end latency numbers (e.g., ms benchmarks) or detailed tuning playbooks in the evidence pack. Missing for 10: concrete latency benchmark figures, component-level latency breakdowns (STT/LLM/TTS), and independent verification of speed claims.

   • [claimed-docs] “Ultra Fast uses speed-optimized models for lower latency. High Intelligence accepts higher latency for greater capability.”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence pack covers architecture, features (barge-in, telephony, function calling, multi-agent), and CLI/SDK tooling, but contains no documented latency numbers (e.g., ms end-to-end) or tuning guidance for reducing turn-taking latency. missing for 10: quantified latency benchmarks, latency tuning/configuration guidance, any performance dashboard or whitepaper on speed claims.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “That includes barge-in, the ability to talk over the agent and have it stop instantly.”
   • [claimed-docs] “Twilio streams the call audio to your server, and your server bridges that audio to the Deepgram Voice Agent API, a single WebSocket that ru…”

   proof ↗⚑ flag

Turn taking

1. developerRely on the agent to handle interruptions (barge-in) gracefully — stopping speech, updating context, and recovering the turn

   weight 3 · round to Deepgram Voice Agent
   Vapi—none0/10

   The evidence pack covers CLI, MCP server, tools, voices, compliance, and testing, but contains no documentation or evidence about interruption handling, barge-in behavior, context updates during interruptions, or turn recovery mechanics. This is a core latency/turn-taking capability for voice agents, but nothing in the pack addresses it directly.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed6/10

   Docs explicitly claim barge-in support where users can talk over the agent and it stops instantly, plus mid-call context tools like InjectAgentMessage for updating conversation state. However, evidence lacks detail on how turn recovery/context updating works technically after interruption, and there's no independent/hands-on corroboration of graceful recovery in practice. missing for 10: technical details on context-state recovery post-interruption, independent verification of barge-in reliability, edge-case handling (e.g., rapid interruptions, latency of stop).

   • [claimed-docs] “That includes barge-in, the ability to talk over the agent and have it stop instantly.”
   • [claimed-docs] “Inject agent message | Mid-call | InjectAgentMessage | Makes the agent speak a specific line”
   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”

   proof ↗⚑ flag

2. developerEnable noise suppression or audio filtering so the agent stays coherent on noisy real-world calls

   weight 1 · round drawn
   Vapi—none0/10

   No evidence pack items mention noise suppression, background noise filtering, or audio denoising features for handling noisy real-world calls; the pack covers voices, tools, CLI, MCP, latency modes, and testing but nothing about audio filtering.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   No evidence pack item mentions noise suppression, background noise filtering, or audio denoising features for the Voice Agent; coverage focuses on barge-in, telephony, multi-agent orchestration, and LLM/TTS configuration instead.

   ⚑ flag

3. developerUse model-based end-of-turn detection beyond simple VAD silence timeouts so the agent doesn't talk over slow speakers

   weight 2 · round drawn
   Vapi—none0/10

   The evidence pack lacks any mention of model-based end-of-turn detection, turn-taking models, or semantic VAD alternatives; only latency tuning between 'Ultra Fast' and 'High Intelligence' model modes is documented, which does not address end-of-turn detection beyond silence-based VAD. Missing for 10: any documentation of a model-based or semantic end-of-turn detector, comparison to VAD-only timeout behavior, or configuration options for turn-taking sensitivity.

   • [claimed-docs] “Ultra Fast uses speed-optimized models for lower latency. High Intelligence accepts higher latency for greater capability.”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Evidence only mentions barge-in (interrupting agent mid-speech) and generic prompting/architecture docs; there is no mention of model-based end-of-turn detection or endpointing that goes beyond VAD/silence timeouts to avoid cutting off slow speakers.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Vapi
   Vapi✓fullprobed8/10

   Vapi's API/SDK covers assistant, phone number, and call management, backed by a full CLI (vapi-docs-2 through 4, 27, 31-32, verified live in vapi-probe-rt-1) and an official MCP server exposing the same operations for external agents (vapi-docs-5,33, confirmed live and auth-gated in vapi-probe-rt-2). Dashboard-only conveniences like Voice Library browsing/preview remain UI-centric, though voice IDs and custom voices can be set via API (vapi-docs-9,24,26,35). Missing for 10: explicit confirmation that every dashboard-only feature (e.g., visual Voice Library browsing, HIPAA toggle) has a full API equivalent, and independent (non-vendor) verification of full UI/API parity.

   • [claimed-docs] “Manage assistants, phone numbers, and calls from your terminal”
   • [claimed-docs] “vapi listen --forward-to localhost:3000/webhook”
   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [claimed-docs] “Build, test, and deploy voice AI applications without leaving your development environment.”
   • [claimed-docs] “The CLI auto-detects your tech stack and sets up everything you need.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vapi CLI installed via the vendor's one-liner (`curl -sSL https://vapi.ai/install.sh | bas…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”
   • [claimed-docs] “You can use your own custom voice with any supported provider by setting the `voice` property in your assistant configuration”
   • [claimed-docs] “Browse and preview voices there, then copy a voice's ID to use on an assistant.”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialprobed6/10

   Deepgram is fundamentally API-first — the Voice Agent is a WebSocket API with full configuration (prompting, function calling, multi-agent, telephony, reusable configs) exposed programmatically, and even the CLI/MCP server let AI-native users manage things from the terminal or via agentic tools rather than a GUI. However, evidence doesn't show a full-featured UI to compare against (e.g., a dashboard/console) nor confirm that every console feature (like A/B testing dashboards, analytics views) has a documented API equivalent. missing for 10: explicit mapping of console/UI-only features (analytics dashboards, A/B test result views) to API endpoints, and confirmation no UI-exclusive functionality exists.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “Reusable Agent Configurations allow you to define and persist the agent block of your Settings message using the Deepgram API. Once created,…”
   • [claimed-docs] “The dg CLI lets you transcribe files, stream live audio, synthesize speech, analyze text, and manage your Deepgram account from the terminal…”
   • [claimed-docs] “The dg CLI includes a built-in MCP (Model Context Protocol) server that gives AI coding tools direct access to Deepgram APIs.”
   • [claimed-docs] “A/B testing voices or prompts — Run two configurations in parallel and measure conversion, CSAT, or containment rate to pick a winner—no cod…”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.deepgram.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://developers.deepgram.com/developer-tools/agentic-tools”
   • [probe] “official CLI documented at https://developers.deepgram.com/developer-tools/cli/getting-started”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Vapi—none0/10

   No evidence of a data export feature, open-format data dumps, or account portability/deletion tooling; the docs cover CLI, MCP server, tools, and voice features but nothing about exporting assistants/call data/transcripts in open formats for user exit. Missing for 10: documented export functionality, open data formats supported, and any account/data portability guarantees.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   No evidence describes any data export, account data portability, or open-format export/deletion workflow letting a user take their data and leave; docs cover retention opt-out and EU processing but not export tooling. missing for 10: data export mechanism, open-format export documentation, account closure/data portability guarantees.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Vapi—none0/10

   Vapi is a closed, commercial SaaS platform; nothing in the evidence indicates its core source (server, dashboard, or model runtime) is published under an open license—only SDKs/CLI tooling and docs are mentioned, and the one open-source reference (pipecat) is a third-party project, not Vapi itself.

   • [community] “Vapi is also built on media framework by daily.co. They have an open source version of voice ai called pipecat.”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Deepgram Voice Agent is a proprietary cloud API/SDK product; no evidence anywhere in the pack points to an open-source license or public source repository for the core Voice Agent service. Only API docs, CLI, and SDK usage are documented, none of which imply open-licensed source availability.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Vapi—none0/10

   Vapi is presented exclusively as a hosted cloud platform (dashboard, hosted MCP server, hosted API/CLI against cloud endpoints); nothing in the evidence pack mentions a self-hostable core engine, open-source repo for the core product, or on-prem deployment option (the mentioned pipecat is a different open-source project, not Vapi itself). This is a fair axis for a voice-AI platform, but no evidence supports self-hosting.

   • [community] “Vapi is also built on media framework by daily.co. They have an open source version of voice ai called pipecat.”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Deepgram Voice Agent is a cloud API/SaaS product; all evidence points to hosted WebSocket endpoints, EU regional endpoints, and cloud-based configuration — there is no mention of a self-hostable or on-premises deployment package for the core voice agent model/inference stack. missing for 10: any self-hosting/on-prem deployment option, downloadable model weights or container, docs on running the core service outside Deepgram's cloud.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “For customers requiring data processing within the European Union, Deepgram provides an EU-specific endpoint at api.eu.deepgram.com.”

   proof ↗⚑ flag

Pricing

1. founderSee published per-minute or usage pricing and estimate cost per call before committing

   weight 2 · round drawn
   Vapi—none0/10

   The evidence pack contains no mention of pricing pages, per-minute rates, usage-based cost breakdowns, or any pricing calculator/estimator; all evidence is about docs, CLI, MCP server, tools, and testing features. Absence of evidence for this applicable axis yields none.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   No evidence pack item mentions pricing, per-minute rates, usage-based cost, or any pricing page/calculator for the Voice Agent product; all citations focus on architecture, features, and developer tools.

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Deepgram Voice Agent
   Vapi—none0/10

   The evidence pack contains no mention of data residency, regional storage options, or geographic data controls anywhere in Vapi's docs (only HIPAA toggle and SSO/RBAC are mentioned as compliance features). Missing for 10: any documentation of region selection, data residency guarantees, or storage location controls.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed6/10

   Deepgram documents an EU-specific endpoint (api.eu.deepgram.com) for customers requiring EU data processing, and a per-request opt-out for model improvement data retention, showing some regional/data-handling control. However, this is limited to EU vs. default (US) with no evidence of broader region selection (e.g., APAC, other jurisdictions) or a general residency configuration option across the platform. Missing for 10: documented list of all available regions, self-serve region selection in dashboard/API config, and independent confirmation of residency guarantees beyond docs.

   • [claimed-docs] “For customers requiring data processing within the European Union, Deepgram provides an EU-specific endpoint at api.eu.deepgram.com.”
   • [claimed-docs] “Opt out per request with mip_opt_out=true. Opted-out requests are not retained”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round to Deepgram Voice Agent
   Vapi—none0/10

   No evidence in the pack addresses data-training opt-out, model-training data policies, or privacy controls preventing AI training use; only HIPAA and SSO/RBAC enterprise features are mentioned, which are unrelated to this specific claim. missing for 10: explicit data-training opt-out policy, DPA/ToS language on training use, dashboard/API setting to exclude data from model training.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed6/10

   Deepgram documents a per-request opt-out (mip_opt_out=true) from its Model Improvement Program, with opted-out requests not retained, directly addressing training-data use. However, the evidence only shows a per-request flag rather than an account-wide default-off setting, and there's no independent verification that opt-out requests are truly excluded from training. Missing for 10: account/org-level opt-out default, third-party audit or independent confirmation of non-training use, and clarity on default behavior when the flag is omitted.

   • [claimed-docs] “Opt out per request with mip_opt_out=true. Opted-out requests are not retained”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Deepgram Voice Agent
   Vapi—none0/10

   The evidence pack covers HIPAA, SSO/RBAC, tooling, CLI, and MCP server features but contains no documentation about data retention policies, call/recording deletion controls, or user-initiated data export/erasure mechanisms. Missing for 10: retention period settings, deletion/erasure APIs or dashboard controls, data export tools, and any policy documentation on how long call data/transcripts are stored.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed5/10

   Deepgram documents a per-request opt-out (mip_opt_out=true) that prevents retention, and references data-privacy compliance including an EU-specific endpoint, giving users some retention control. However, there is no documented self-service deletion mechanism for already-retained data, no stated retention periods, and no dashboard/API for managing or purging stored voice data. Missing for 10: explicit data deletion API/console, documented retention duration policy, and confirmation of deletion for non-opted-out data.

   • [claimed-docs] “Opt out per request with mip_opt_out=true. Opted-out requests are not retained”
   • [claimed-docs] “For customers requiring data processing within the European Union, Deepgram provides an EU-specific endpoint at api.eu.deepgram.com.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round to Deepgram Voice Agent
   Vapi—none0/10

   No evidence pack item addresses telemetry opt-out or usage tracking controls; Vapi's docs cover HIPAA/SSO/RBAC compliance but not a telemetry toggle.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed4/10

   Deepgram documents an opt-out mechanism (mip_opt_out=true) for model improvement/data retention on a per-request basis, which is a form of telemetry/usage-data opt-out, but this is narrowly scoped to training data retention rather than general telemetry/usage tracking (e.g., analytics, product usage metrics). Missing for 10: documentation of a broader telemetry/usage-tracking opt-out setting, confirmation this covers all usage data beyond model-improvement retention, and independent verification that opting out has no side effects.

   • [claimed-docs] “Opt out per request with mip_opt_out=true. Opted-out requests are not retained”

   proof ↗⚑ flag

Call control

1. developerEscalate a live call to a human with warm or blind transfer, passing context along

   weight 2 · round drawn
   Vapi—none0/10

   No evidence in the pack mentions call transfer, warm/blind transfer, or passing context to a human agent; the evidence covers assistants, CLI, MCP server, tools/webhooks, voices, and compliance, but nothing about live-call escalation/transfer capabilities.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   Evidence covers telephony connectivity, function calling, multi-agent handoff between AI agents, and mid-call message injection, but nothing documents a warm/blind transfer to a human agent (e.g., SIP REFER, call transfer function, or context handoff to a live operator).

   ⚑ flag

2. developerMy agent can send DTMF keypresses, navigate IVR menus, and detect or leave voicemail

   weight 1 · round drawn
   Vapi—none0/10

   The evidence pack contains no mention of DTMF keypress sending, IVR menu navigation, or voicemail detection/leaving functionality anywhere in the docs or community items — these telephony-specific capabilities are entirely unevidenced despite being a plausible axis for a voice AI telephony product.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence covers telephony connectivity, function calling, barge-in, and multi-agent orchestration, but nothing documents DTMF keypress sending, IVR menu navigation, or voicemail detection/leaving capabilities.

   ⚑ flag

Campaigns

1. founderRun batch outbound call campaigns with scheduling and throughput controls

   weight 2 · round drawn
   Vapi—none0/10

   Evidence covers assistant creation, tools, CLI, MCP server, testing, and voice customization, but nothing addresses batch/outbound campaign management, call scheduling, or throughput/concurrency controls for bulk dialing. No mention of a campaigns API, CSV/list upload, dialer pacing, or rate-limiting controls for outbound calling at scale.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   Deepgram's docs confirm outbound telephony connectivity (docs-5, docs-18) and per-call features like barge-in and prompting, but there is no mention of campaign-level batch dialing, call scheduling, or throughput/rate controls for outbound campaigns — this is a real-time conversation API, not a dialer/campaign manager.

   • [claimed-docs] “Telephony: connect voice agents to phone networks for inbound and outbound calls.”
   • [claimed-docs] “Twilio streams the call audio to your server, and your server bridges that audio to the Deepgram Voice Agent API, a single WebSocket that ru…”

   proof ↗⚑ flag

Numbers

1. developerProvision phone numbers and run both inbound and outbound calls through the platform's API

   weight 3 · round to Vapi
   Vapi✓fullprobed8/10

   Docs explicitly cover creating an assistant, connecting it to a phone number, and making inbound/outbound calls via the quickstart, plus CLI/MCP support for managing phone numbers and calls, and SIP for advanced telephony integration, with runtime probes confirming the CLI and MCP endpoints work as documented. Missing for 10: independent hands-on confirmation of actual outbound call placement via raw API (only demo/inbound anecdote in community evidence) and explicit multi-number provisioning workflow details.

   • [claimed-docs] “const assistant = await vapi.assistant”
   • [claimed-docs] “Create a voice assistant, connect it to a phone number, and make your first calls.”
   • [claimed-docs] “In under 5 minutes, you'll create a voice assistant and start talking to it over the phone.”
   • [claimed-docs] “Manage assistants, phone numbers, and calls from your terminal”
   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [claimed-docs] “Use any SIP softphone (e.g., Zoiper, Linphone) to dial your SIP URI”
   • [claimed-docs] “This guide shows you how to set up and test SIP calls to your Vapi assistant using any SIP client or softphone.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vapi CLI installed via the vendor's one-liner (`curl -sSL https://vapi.ai/install.sh | bas…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”
   • [community] “Called the demo number, sounds smooth! Good luck.”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialclaimed6/10

   Docs confirm Deepgram Voice Agent supports inbound/outbound calls and telephony integration (e.g., via Twilio bridging audio to a single WebSocket), but there is no evidence Deepgram itself provisions or manages phone numbers—developers must bring their own Twilio account/number and build a bridging server. Missing for 10: native phone-number provisioning API, first-party telephony number management, and evidence of outbound call initiation directly through Deepgram's API without a third-party carrier.

   • [claimed-docs] “Telephony: connect voice agents to phone networks for inbound and outbound calls.”
   • [claimed-docs] “Twilio streams the call audio to your server, and your server bridges that audio to the Deepgram Voice Agent API, a single WebSocket that ru…”
   • [claimed-docs] “That includes barge-in, the ability to talk over the agent and have it stop instantly.”

   proof ↗⚑ flag

Sip

1. platform-engineerConnect my own carrier or PBX via SIP trunking (or import Twilio/Telnyx numbers) instead of being locked to bundled telephony

   weight 2 · round to Vapi
   Vapi~partialclaimed5/10

   Docs confirm SIP connectivity: platform engineers can point any SIP client/softphone at a Vapi SIP URI to make/receive calls (vapi-docs-14, vapi-docs-22), which supports self-hosted/carrier SIP trunking use cases. However, the evidence never explicitly documents PBX/carrier trunk configuration options or a number-import workflow for Twilio/Telnyx accounts. missing for 10: explicit documentation of BYO-carrier/PBX trunk setup steps, and evidence of importing existing Twilio/Telnyx phone numbers into Vapi.

   • [claimed-docs] “Use any SIP softphone (e.g., Zoiper, Linphone) to dial your SIP URI”
   • [claimed-docs] “This guide shows you how to set up and test SIP calls to your Vapi assistant using any SIP client or softphone.”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Evidence only documents a generic WebSocket bridge pattern for Twilio (docs-18, docs-8) and a general 'Telephony' feature bullet (docs-5), but there is no mention of SIP trunking, PBX connectivity, or Telnyx number import — the specific mechanisms a platform engineer would need to bring their own carrier.

   • [claimed-docs] “Telephony: connect voice agents to phone networks for inbound and outbound calls.”
   • [claimed-docs] “Twilio streams the call audio to your server, and your server bridges that audio to the Deepgram Voice Agent API, a single WebSocket that ru…”
   • [claimed-docs] “That includes barge-in, the ability to talk over the agent and have it stop instantly.”

   proof ↗⚑ flag

Analytics

1. ai-native userThe platform's AI reviews my calls for me — scoring quality, flagging failures, and analyzing resolution automatically

   weight 2 · round to Vapi
   Vapi~partialclaimed4/10

   Vapi's Evals framework provides automated validation of assistant behavior via mock conversations and its Voice Test Suites use an AI tester to simulate calls and check outcomes, which is adjacent to automated call review, but neither is documented as automatically scoring, flagging failures in, or analyzing resolution of real production calls after the fact. Missing for 10: evidence of automatic post-call quality scoring on live/production transcripts, explicit failure-flagging analytics, and resolution-outcome analysis dashboards distinct from pre-production test suites.

   • [claimed-docs] “Evals is Vapi's AI agent testing framework that enables you to systematically test assistants and squads using mock conversations with autom…”
   • [claimed-docs] “you'll create mock conversations, define expected behaviors, and validate your agents work correctly before production”
   • [claimed-docs] “Voice Test Suites enable you to test your AI voice agents through simulated phone conversations.”
   • [claimed-docs] “Our AI tester calls your voice agent and follows a script that simulates real customer behavior.”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence pack covers Deepgram Voice Agent's real-time conversation infrastructure (STT/TTS, function calling, telephony, prompting, A/B testing of voices/prompts) but contains no mention of post-call AI review, automated quality scoring, failure flagging, or resolution analysis of completed calls.

   ⚑ flag

2. founderSee call analytics — success rates, durations, outcomes, sentiment — in dashboards without building my own

   weight 2 · round drawn
   Vapi—none0/10

   The evidence pack documents assistant creation, tools, testing (Evals, Voice Test Suites), CLI/MCP management, and voice library features, but contains no mention of a dashboard showing call success rates, durations, outcomes, or sentiment analytics — the core of this story.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   Deepgram is a developer API/infrastructure product; evidence shows mentions of A/B testing metrics (conversion, CSAT, containment rate) as data points but no evidence of an actual built-in dashboard for call analytics, success rates, durations, sentiment, or outcomes that founders can view without building their own.

   • [claimed-docs] “A/B testing voices or prompts — Run two configurations in parallel and measure conversion, CSAT, or containment rate to pick a winner—no cod…”

   proof ↗⚑ flag

Monitoring

1. platform-engineerMonitor live calls in production and get alerts when agents misbehave or error rates spike

   weight 1 · round drawn
   Vapi—none0/10

   The evidence pack covers pre-production testing (Voice Test Suites, Evals) and webhook debugging via the CLI, but contains no mention of live call monitoring dashboards, real-time alerting, or error-rate-spike detection for production traffic. This is a fair axis for a voice AI platform, but nothing in the pack demonstrates it.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   No evidence of live monitoring dashboards, error-rate alerting, or observability/analytics tooling for production calls; docs cover agent architecture, function calling, telephony, and configuration but nothing about monitoring or alerting on agent misbehavior.

   ⚑ flag

Testing

1. developerTest agents with simulated conversations or evals before putting them on real phone calls

   weight 2 · round to Vapi
   Vapi✓fullclaimed9/10

   Vapi documents two dedicated testing features directly matching the story: Voice Test Suites for simulated phone conversations via an AI tester following scripted customer behavior, and Evals, a testing framework for mock conversations with automated validation before production. Missing for 10: independent/hands-on developer corroboration of these specific testing features beyond vendor docs.

   • [claimed-docs] “Voice Test Suites enable you to test your AI voice agents through simulated phone conversations.”
   • [claimed-docs] “Our AI tester calls your voice agent and follows a script that simulates real customer behavior.”
   • [claimed-docs] “Evals is Vapi's AI agent testing framework that enables you to systematically test assistants and squads using mock conversations with autom…”
   • [claimed-docs] “you'll create mock conversations, define expected behaviors, and validate your agents work correctly before production”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence covers live-call features (function calling, prompting, telephony, A/B testing of live configs) but nothing describes a simulated-conversation or eval framework for pre-production testing of agents before real phone calls. Missing for 10: any documentation of a test/sandbox mode, conversation simulation tool, or eval harness for agents.

   • [claimed-docs] “A/B testing voices or prompts — Run two configurations in parallel and measure conversion, CSAT, or containment rate to pick a winner—no cod…”
   • [claimed-docs] “Reusable Agent Configurations allow you to define and persist the agent block of your Settings message using the Deepgram API. Once created,…”

   proof ↗⚑ flag

Post call

1. developerExtract structured data from every call — outcomes, entities, dispositions — delivered via API or webhook after the call

   weight 2 · round drawn
   Vapi—none0/10

   The evidence pack shows Vapi's webhook/tool-calling system for live in-call actions (tool-calls messages, custom webhook tools, function calling) but contains no mention of a post-call structured-data/analysis feature (outcomes, entities, dispositions) delivered via API or webhook after the call ends. Missing for 10: any docs on end-of-call reports, structured data extraction schemas, call analysis/summary webhooks, or an API endpoint returning call outcome/entity data.

   • [claimed-docs] “When tools are triggered, your Server URL receives a `tool-calls` message”
   • [claimed-docs] “Vapi supports OpenAI-style tool/function calling. Assistants can ping your server to perform actions.”
   • [claimed-docs] “Custom tools that you create... interact with your systems via webhooks”
   • [claimed-docs] “Create your own webhook-based tools to extend assistant capabilities”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence pack covers live function calling during a call and various agent configuration/telephony features, but there is no mention of post-call structured data extraction (summaries, entities, dispositions) or webhook delivery of such analytics after a call ends.

   ⚑ flag

Tools

1. ai-native userMy voice agent can plug in MCP servers as tool sources so one integration grants it whole toolsets mid-call

   weight 2 · round drawn
   Vapi—none0/10

   Evidence only shows Vapi exposing its own APIs as an MCP *server* for external AI assistants (e.g., Claude Desktop) to manage calls/assistants — the reverse direction of the story. There is no documentation or probe showing a Vapi voice assistant can itself act as an MCP *client*, plugging in external MCP servers as tool sources mid-call; tool integration is instead described only via webhook-based custom tools and OpenAI-style function calling.

   • [claimed-docs] “so you can manage assistants, phone numbers, and calls from any MCP-compatible AI assistant (like Claude Desktop) or agent framework”
   • [claimed-docs] “The Vapi MCP Server exposes Vapi APIs as tools via the Model Context Protocol (MCP), so you can manage assistants, phone numbers, and calls …”
   • [claimed-docs] “Create your own webhook-based tools to extend assistant capabilities”
   • [claimed-docs] “Vapi supports OpenAI-style tool/function calling. Assistants can ping your server to perform actions.”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.vapi.ai/mcp returned HTTP 401 — t…”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Evidence confirms mid-call function calling exists for the Voice Agent (deepgram-docs-2) but only documents an MCP *server* built into the CLI that lets coding tools access Deepgram APIs (deepgram-docs-13, deepgram-probe-4) — this is the reverse direction, not the Voice Agent acting as an MCP client to pull in external toolsets mid-call. No evidence shows the Voice Agent itself can connect to MCP servers as a tool source.

   • [claimed-docs] “In the context of Deepgram Voice Agents, function calling enables your agent to perform tasks during a live conversation.”
   • [claimed-docs] “The dg CLI includes a built-in MCP (Model Context Protocol) server that gives AI coding tools direct access to Deepgram APIs.”
   • [probe] “official MCP server documented at https://developers.deepgram.com/developer-tools/agentic-tools”

   proof ↗⚑ flag

2. developerMy agent can call external APIs and custom functions mid-conversation and speak the result without awkward dead air

   weight 3 · round drawn
   Vapi~partialclaimed6/10

   Vapi's docs clearly show mid-call function/tool calling via webhook Server URLs and OpenAI-style tool-calls messages, letting the assistant fetch external API results and use them in conversation (vapi-docs-6, vapi-docs-7, vapi-docs-17, vapi-docs-20, vapi-docs-23, vapi-docs-34). However, the pack lacks explicit evidence about mechanisms for avoiding 'dead air' during the API call latency (e.g., async tool config, filler phrases, or interim speech) — only general latency-tuning docs for model selection are present (vapi-docs-15). Missing for 10: explicit documentation/demo of filler/interim speech or async tool handling during function execution, and independent hands-on confirmation that the conversation flow feels seamless during a live tool call.

   • [claimed-docs] “Create your own webhook-based tools to extend assistant capabilities”
   • [claimed-docs] “Server URL: The endpoint where your function is hosted”
   • [claimed-docs] “When tools are triggered, your Server URL receives a `tool-calls` message”
   • [claimed-docs] “This guide shows you how to create custom tools, including Function Tools, for your Vapi assistants.”
   • [claimed-docs] “Vapi supports OpenAI-style tool/function calling. Assistants can ping your server to perform actions.”
   • [claimed-docs] “Custom tools that you create... interact with your systems via webhooks”
   • [claimed-docs] “Ultra Fast uses speed-optimized models for lower latency. High Intelligence accepts higher latency for greater capability.”

   proof ↗⚑ flag

   Deepgram Voice Agent~partialclaimed6/10

   Docs confirm function calling is a supported feature for performing tasks mid-conversation (deepgram-docs-2), and the agent architecture is a single low-latency WebSocket for audio in/out (deepgram-docs-1) with barge-in and inject-message features (deepgram-docs-8, deepgram-docs-11) suggesting attention to latency/dead-air. However there's no explicit documentation or example describing how function-call latency is masked (e.g., filler speech, streaming partial results) while awaiting an API response. Missing for 10: concrete guidance/examples on avoiding dead air during function execution, sample code showing async function calls with the agent speaking a holding phrase, and independent/hands-on verification of smooth latency handling.

   • [claimed-docs] “In the context of Deepgram Voice Agents, function calling enables your agent to perform tasks during a live conversation.”
   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “That includes barge-in, the ability to talk over the agent and have it stop instantly.”
   • [claimed-docs] “Inject agent message | Mid-call | InjectAgentMessage | Makes the agent speak a specific line”

   proof ↗⚑ flag

Recording

1. platform-engineerRetrieve full call recordings and transcripts programmatically for every call

   weight 2 · round drawn
   Vapi—none0/10

   The evidence pack contains no documentation, API reference, or example demonstrating retrieval of call recordings or transcripts, despite this being a natural, expected capability for a voice AI platform; only tangential tooling (CLI, MCP server, custom tools, testing/evals) is covered.

   ⚑ flag

   Deepgram Voice Agent—none0/10

   The evidence pack covers Voice Agent architecture, function calling, telephony bridging, LLM providers, and data privacy opt-outs, but nowhere describes an API or mechanism to retrieve full call recordings or persisted transcripts after a call ends. No endpoint, storage feature, or retrieval workflow is documented for this specific capability.

   ⚑ flag

Transcription

1. developerGet accurate real-time transcription with control over the STT provider, language models, or key terms

   weight 2 · round to Deepgram Voice Agent
   Vapi—none0/10

   The evidence pack contains no documentation about selecting/configuring an STT provider, choosing language models for transcription, or defining custom key terms/vocabulary for real-time transcription — topics like 'transcriber', 'Deepgram', or keyword boosting are absent. While Vapi is clearly a voice AI platform where such controls are a fair axis, none of the provided docs, community items, or probes address it.

   ⚑ flag

   Deepgram Voice Agent~partialclaimed6/10

   Docs confirm real-time transcription via the unified WebSocket API, selectable LLM providers (docs-9), and multilingual STT/TTS model choices (docs-10), giving developers meaningful control over STT and LLM models. However, there is no evidence of 'key terms' or keyword-boosting controls specific to the Voice Agent's transcription pipeline. Missing for 10: explicit key-term/keyword-boost configuration support, independent benchmarking of transcription accuracy.

   • [claimed-docs] “Deepgram's Voice Agent API collapses that stack into a single, unified API. You open one WebSocket connection, send audio in, and receive au…”
   • [claimed-docs] “Supported LLM providers | Parameter | open_ai | anthropic | aws_bedrock | google | groq | nvidia”
   • [claimed-docs] “A multilingual voice agent has two model decisions: which STT model transcribes the user, and which TTS model speaks the agent.”

   proof ↗⚑ flag

Voices

1. founderClone a custom brand voice and use it for my agents, with a documented consent process

   weight 2 · round drawn
   Vapi—none0/10

   Vapi docs show you can plug in a 'custom voice' by setting the voice property with a provider ID (vapi-docs-9, vapi-docs-26) and browse a Voice Library (vapi-docs-8, vapi-docs-35), but nothing describes an actual voice-cloning workflow or any documented consent/verification process required before cloning a brand voice. Missing for 10: a described voice-cloning feature/flow, a documented consent or identity-verification process, and any policy language governing voice cloning.

   • [claimed-docs] “You can use your own custom voice with any supported provider by setting the `voice` property in your assistant configuration”
   • [claimed-docs] “You can use your own custom voice with any supported provider by setting the voice property in your assistant configuration”
   • [claimed-docs] “The Voice Library in the Vapi Dashboard lists every voice available to your organization. Browse and preview voices there”
   • [claimed-docs] “The **Voice Library** in the [Vapi Dashboard] lists every voice available to your organization. Browse and preview voices there, then copy a…”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   No evidence of a voice cloning feature or consent process; docs cover STT/TTS model selection, multilingual voices, and agent configuration but never mention custom voice cloning or consent workflows.

   ⚑ flag

2. developerChoose from a broad voice library or plug in multiple TTS providers to get the voice I want

   weight 2 · round to Vapi
   Vapi~partialclaimed6/10

   Docs confirm a Voice Library with many previewable voices and support for custom voices with any supported provider, indicating multi-provider TTS flexibility, but the evidence never names or lists specific TTS providers (e.g., ElevenLabs, PlayHT, Azure) or details plugging in third-party/custom TTS engines beyond voice ID selection. missing for 10: explicit list of supported TTS providers, documentation of custom/BYO TTS provider integration mechanics, independent hands-on confirmation of voice quality/variety.

   • [claimed-docs] “The Voice Library in the Vapi Dashboard lists every voice available to your organization. Browse and preview voices there”
   • [claimed-docs] “You can use your own custom voice with any supported provider by setting the `voice` property in your assistant configuration”
   • [claimed-docs] “Browse and preview voices there, then copy a voice's ID to use on an assistant.”
   • [claimed-docs] “You can use your own custom voice with any supported provider by setting the voice property in your assistant configuration”
   • [claimed-docs] “The **Voice Library** in the [Vapi Dashboard] lists every voice available to your organization. Browse and preview voices there, then copy a…”

   proof ↗⚑ flag

   Deepgram Voice Agent—none0/10

   Evidence confirms TTS model selection exists (docs-10 references choosing a TTS model) but there is no documentation of a broad voice library or of plugging in multiple third-party TTS providers analogous to the multi-LLM-provider list (docs-9). Missing for 10: evidence of voice catalog/library breadth, evidence of multiple supported TTS providers/vendors, and any provider-switching mechanism for voice output.

   • [claimed-docs] “A multilingual voice agent has two model decisions: which STT model transcribes the user, and which TTS model speaks the agent.”

   proof ↗⚑ flag