Reference
Voice AI infrastructure glossary
Definitions for terms used in the design and operation of voice AI infrastructure. Entries cover routing, multi-tenancy, evaluation, and control plane architecture.
- Call evaluation
- A process that scores a completed voice AI conversation against a defined set of criteria. Criteria typically include goal completion, tone adherence, handling of specific topics, and factual accuracy. Call evaluation runs after the call ends, using the transcript and metadata produced by the voice provider.
- Client 8 plateau
- The point at which a voice AI agency with manually managed infrastructure starts to break down. Around the eighth client, the volume of custom scripts, duplicate webhook handlers, and per-client debugging work exceeds what a small team can maintain reliably. The number is approximate; the pattern is consistent. Agencies who do not move to a shared infrastructure layer before this point typically stop growing or start losing clients.
- Control plane
- In voice AI infrastructure, the control plane is the system that manages routing, tenant context, access policies, and operational state across all clients and providers. It sits between the voice provider and the automation layer. The control plane does not handle the voice conversation itself; it handles the operational context around every conversation.
- Integration tax
- The cumulative cost of maintaining a custom integration for each voice AI provider, client, or workflow a team manages. Integration tax compounds over time because every new provider or client adds another surface that needs updating when APIs change, schemas shift, or incidents occur. Teams pay the tax in engineering hours, reliability incidents, and delayed feature work.
- Metadata envelope
- A structured block of operational context attached to every forwarded webhook event. A metadata envelope typically contains the organization ID, client ID, provider name, slug, request timestamp, and ingest ID. Downstream automation systems use the envelope to route events, apply business logic, and write to the correct data store without relying on the raw provider payload structure.
- Multi-tenant architecture
- A system design where a single instance of the infrastructure serves multiple customers (tenants), with data and operations isolated between them. In voice AI, multi-tenancy means that call events, transcripts, evaluations, and settings for one client are inaccessible to other clients even when they share the same underlying database and application layer. Isolation is enforced by row-level security policies, not by application code alone.
- Post-call webhook
- An HTTP request sent by a voice provider to a preconfigured endpoint when a call ends. The payload typically includes the call ID, duration, transcript, recording URL, and any extracted entities. Different providers structure this payload differently; standardizing it across providers is one of the core functions of a control plane.
- Prompt evaluation
- A process that tests a voice AI prompt or system configuration against a set of scenarios to measure how well it performs before or after deployment. Prompt evaluation differs from call evaluation in that it is run against test inputs rather than live calls. Teams use it to validate prompt changes before pushing them to production clients.
- Row-level security (RLS)
- A database feature that restricts which rows a query can return based on the identity of the user or service making the request. In multi-tenant voice AI infrastructure, RLS ensures that a query made in the context of one tenant cannot return data belonging to another, even if the underlying table contains data for all tenants. PostgreSQL RLS policies are the most common implementation.
- Slug-based routing
- A routing approach where each webhook endpoint URL contains a short identifier (slug) that maps to a specific organization and client. When a voice provider sends a post-call event to an endpoint like /webhook/vapi/acme-motors, the system resolves the slug "acme-motors" to the correct tenant context before any processing occurs. This makes routing deterministic and auditable without requiring authentication tokens in the URL.
- Tenant-safe ingestion
- A webhook ingestion pattern where every incoming event is resolved to a specific tenant context before any processing, storage, or forwarding occurs. The resolution step validates the slug, confirms the provider, enforces access policies, and writes to an audit log. Only then does the event proceed downstream. Tenant-safe ingestion prevents cross-tenant data leakage, simplifies debugging, and provides a durable record of every event received.
Further reading
These concepts in practice.
The blog covers how these concepts apply to real agency and operator deployments, including failure patterns, readiness scoring, and architectural decisions at scale.