Hi Vapi Team, We are currently using your platform to design and operate two types of assistants: Inbound and Outbound. Our goal is to clarify the best architectural approach to manage concurrency limits, ensuring that inbound calls are always available, even while large outbound campaigns are running. Context Inbound calls must be available at all times (we are using Redis to manage a queue on our side). Outbound campaigns may involve a high volume of calls (e.g. 1,000–2,000 calls). The main concern is that outbound campaigns can fully consume the available concurrency, making inbound lines temporarily unavailable. Increasing the total number of concurrency lines alone does not fully solve the problem. For example, even with 1,000 concurrency lines, a sufficiently large outbound campaign could still saturate all available channels and block inbound calls. Proposed Approach Our current idea is to logically separate inbound and outbound traffic by using two different Vapi organizations: Inbound Org Dedicated to inbound assistants Allocated with X concurrency lines Ensures inbound availability at all times Outbound Org Dedicated exclusively to outbound campaigns Allocated with Y concurrency lines Used only for outbound execution This way, outbound campaigns would never compromise inbound availability, as each flow would have its own isolated concurrency pool. Questions If we create a new organization using “Switch organization → New organization” within our existing account: Will this new org automatically receive its own set of concurrency lines (e.g. +10)? Or does it share the same concurrency pool as the parent organization? If concurrency is shared, should the outbound org be created entirely outside the current organization (with a separate account / email) to guarantee isolation? Is there any native or technical mechanism in Vapi to: Reserve or cap concurrency for outbound campaigns (e.g. “use only X lines for outbound”)

Suggestion: To ensure inbound and outbound calls do not compete for concurrency, create a separate Vapi organization for each flow. Each organization has its own concurrency pool (e.g., 10 lines per org), so this approach will isolate capacity and prevent outbound campaigns from impacting inbound availability. Example:

Inbound Org: Handles only inbound calls (X concurrency)
Outbound Org: Handles only outbound campaigns (Y concurrency)

According to the documentation, "concurrency limits are on the Vapi side" and are set per organization, not globally shared. See: [Vapi Outbound Campaigns Overview](https://docs.vapi.ai/outbound-campaigns/overview) Source: - [Vapi Outbound Campaigns Overview](https://docs.vapi.ai/outbound-campaigns/overview)