8 Concurrent AI Agents: Supabase Edge Functions and VAPI in Practice

Why Voice Multi-Agent Systems Need a Different Architectural Approach

Building a production system that can handle 8 AI voice agents simultaneously is completely different from putting together a demo. The Quiet Hours Valet Command Center team recently disclosed their architecture: the frontend is deployed on Vercel, the backend uses Supabase Edge Functions to host 8 automated workflows, and the voice layer integrates with VAPI through Asterisk PBX for orchestration. The entire system runs on serverless functions with no dedicated servers.

Behind this choice is a key judgment: voice agent workloads are bursty and concurrent. Traditional always-on servers waste resources when idle and tend to become bottlenecks at peak times. The on-demand execution model of Edge Functions matches this pattern perfectly—each webhook event triggers one function execution, which is released once the response is complete. But to let 8 agents share state within the same project without interfering with each other, functions alone aren't enough. They use a Postgres schema with 8 tables to manage agent state.

Practical Constraints of Running Voice Orchestration on Edge Functions

The benefits of Edge Functions are fast cold starts, inherent distribution, and seamless integration with Supabase's Postgres and auth system. But putting voice orchestration on them means the team must handle several real-world problems.

First is webhook idempotency. During a voice call, VAPI pushes a large number of events—call start, transcript segments, tool calls, hangup—and the same event may arrive multiple times due to network retries. Edge Functions have no persistent process to deduplicate, so the handling logic for each event must carry its own idempotency key, typically enforced through a unique constraint in Postgres.

Second is state isolation between agents. Each of the 8 agents maintains its own conversation context, current task, and tool call history. The division of the 8 tables is designed exactly for this: one manages session lifecycle, one manages transcript records, one manages tool call results, and so on. This split makes each function's read/write scope clear and reduces concurrent write conflicts.

According to the original article, the team also placed routing logic at the Edge Function layer: based on the incoming phone number or webhook metadata, it decides which agent's processing flow the event should be dispatched to. This amounts to a lightweight message routing layer inside serverless functions.

Webhook idempotency refers to the ability of a system to process an event only once and reach a consistent final state when the same event arrives multiple times due to network retries or duplicate pushes. In serverless architectures, function instances are created and destroyed with events, with no persistent memory available for a deduplication cache, so teams typically write idempotency keys (such as event IDs or business primary keys) into database unique constraints, letting Postgres reject duplicate records on insert. Voice platforms like VAPI push events densely throughout the call lifecycle; inadequate idempotency design can lead to production incidents such as duplicate billing and repeated tool call execution, which is why this is a must-verify area when moving voice agents to the cloud.

The Division of Labor Between Asterisk and VAPI

The composition of the voice stack itself is worth breaking down. Asterisk PBX handles access and signaling for traditional telephone networks, while VAPI handles voice AI orchestration—speech recognition, LLM inference, speech synthesis, and interruption handling. The boundary between the two is: Asterisk manages "how the call comes in," and VAPI manages "how the conversation proceeds."

The benefit of this layering is that telephony-side capabilities (numbers, call forwarding, IVR) don't need to be reimplemented at the AI layer, and iterations at the AI layer won't affect the stability of telephone access. For voice products that need to connect to real PSTN calls, this is a pragmatic combination. The trade-off is that the cumulative latency between the two systems needs to be validated in the end-to-end experience; the original article does not provide specific latency data.

Asterisk is open-source PBX (Private Branch Exchange) software responsible for traditional telephony capabilities such as SIP signaling, PSTN gateway integration, number management, call routing, and IVR. VAPI is an orchestration platform for voice AI that encapsulates ASR (speech recognition), LLM inference, TTS (speech synthesis), and barge-in handling. The typical pattern for combining the two is: Asterisk converts incoming calls into media streams and bridges them to VAPI's session interface, and VAPI returns synthesized speech that is sent back to the user through Asterisk. Understanding this layering helps identify sources of latency—signaling setup, media transcoding, and AI inference each account for a portion, and the end-to-end experience needs to be measured segment by segment.

Lessons for Building Voice AI Products

The most valuable takeaway from this architecture isn't any specific tool, but the combined idea of "serverless + external state storage." Voice agent sessions are stateful, but functions are stateless; externalizing state to Postgres lets the two work together. 8 concurrent agents may not sound like much, but in voice scenarios each session involves a continuous stream of events, so actual event throughput is far higher than the number of agents itself.

If you're building a similar vertically integrated voice product, prioritize validating three things: whether the webhook idempotency mechanism is reliable, whether the division of agent state tables is clear, and whether the latency between the PBX and the voice orchestration layer is acceptable. These three points determine whether the system can move from demo to production.

The original article does not disclose cost data, specific latency metrics, or the business scenarios of each of the 8 agents—information that is missing when assessing the completeness of this architecture.

Stateless functions + external state storage is a common paradigm for handling stateful business logic in serverless architectures. The function itself doesn't store the session; all context (conversation history, task progress, tool call results) is persisted to external storage such as Postgres, and the function reads and writes back on demand with each execution. The advantage of this pattern is that horizontal scaling isn't limited by instance stickiness; the downside is an extra database round trip for every interaction, and concurrent writes to the same session require row locks or optimistic concurrency control. In voice scenarios with dense event streams, read/write hotspots and conflict handling strategies for state tables directly affect system stability and latency.