If you have looked at voice AI in the last twelve months, you have almost certainly come across Retell AI and Vapi. Both are excellent. They represent real engineering depth, their developer experience is well-considered, and they have pushed the whole category forward. We have built test agents on both, watched their release notes carefully, and measured ourselves against them. None of what follows is a takedown.
But there is a persistent confusion in the market about what these platforms actually are, and what they are for. It shows up whenever an MSP tells us "we were going to build on Retell" or when a potential tenant asks "why don't I just use Vapi myself?" The short answer is that Retell and Vapi solve a fundamentally different problem than the one a plumber, an electrician, or a property manager actually has. This article explains the architectural reason for that.
What Retell and Vapi actually are
Retell and Vapi are voice AI frameworks. You give them an agent configuration — a system prompt, a set of tools, a voice — and they handle the plumbing that turns that into a real-time phone call. They take care of the speech-to-text, the LLM orchestration, the TTS streaming, the barge-in detection, the telephony integration. The developer experience is genuinely slick: you can have a working agent answering calls inside an afternoon.
They are, in other words, building blocks. You bring the product; they bring the voice-call runtime.
Agent-centric versus tenant-centric
The clearest way to understand the gap between "framework" and "platform" is to look at how agents relate to customers.
Retell and Vapi are agent-centric. Each agent is its own artifact: its own prompt, its own tool list, its own voice, its own knowledge. You, the developer, create agents. If you have five customers, you probably have five agents — maybe more if different customers need different behaviours for after-hours versus business hours.
This is fine at five customers. It is manageable at twenty. It becomes the single biggest problem in your business at a hundred, and it becomes impossible at a thousand.
The prompt isolation problem
Say you have fifty customers live on Retell. Your agents are running well. Then you notice something: the AI is mis-pronouncing "Ponsonby." It keeps saying it like an American would. Your customers start hearing about it from their callers.
You fix the prompt. One line, takes two minutes. For one agent.
Now you have forty-nine other agents, each of which has its own prompt, each of which has been edited over time by you or your customer, each of which contains their specific business context, their greeting, their tone. You now have three options, all bad:
- Manually edit all forty-nine agents. A full day of work, error-prone, and half of them will drift out of sync again within a week as customers make their own changes.
- Only apply the fix to new agents. Existing customers never benefit from the improvement. Six months in, your early customers have the worst experience and your newest customers have the best.
- Build a templating and propagation system that lets you push prompt updates across all agents without breaking each one's customisations. Congratulations: you have started building a platform.
The Ponsonby example is trivial. The same pattern applies to every improvement you will ever want to make: compliance disclosures, safety guardrails, urgency-scoring logic, handling of silent callers, greeting tone, data-capture flow, transfer-confirmation phrasing, sentiment detection instructions, how the AI handles being told "wait, one moment." Each one is a prompt change that needs to reach all your customers — or it does not.
This is what people mean by prompt isolation. The agents are architecturally independent, and improvements do not travel between them without deliberate, expensive engineering work.
Agent-centric platforms require manual propagation of every improvement across isolated agents. Tenant-centric platforms push improvements through a shared layer that benefits all customers automatically.
What a tenant-centric platform looks like
dareena.ai is designed around the opposite premise. Tenants do not have their own full prompts. They have a business configuration — greeting, services, hours, knowledge base, connected tools — and the platform composes the full prompt at call time from two layers:
- Layer 1 (platform-wide) — compliance disclosures, NZ place-name pronunciation hints, tool-use conventions, safety guardrails, turn-taking logic, universal behaviours. Owned by us. Improved continuously.
- Layer 2 (tenant-specific) — the specific business: this plumber, this clinic, this property manager. Their knowledge base, their connected calendar, their skills.
When we fix Ponsonby, we fix it in Layer 1 once, and every tenant on the platform benefits on their very next call. No backfill. No drift. Tenants do not need to configure Layer 1 because it is not their job to know about it. Their job is to tell the platform about their business. The platform's job is everything else.
The other things platforms quietly do
Prompt composition is the most visible difference, but it is not the only one. A real multi-tenant platform also has to provide:
- Per-tenant billing and usage tracking, with rate cards that can differ by wholesaler, fraud protection, and reconciliation. Retell and Vapi bill you; you build the rest.
- White-label branding across portal, emails, and admin surfaces — with per-wholesaler logos, colours, domains, and email senders resolved at runtime.
- Tenant-scoped OAuth for every connected service (Google Calendar, HubSpot, Zoho, Trello, ServiceM8). Token refresh, error handling, and failure modes, all per tenant.
- Support tooling that understands multi-tenancy: masquerade, per-tenant audit logs, scoped API keys, ticket triage.
- Compliance infrastructure — recording disclosure toggles, AI disclosure, NZ Privacy Act handling, data-deletion workflows that respect billing retention.
- Operational tooling — reconciliation, call-quality monitoring, provider rate management, effective-dated pricing changes.
None of these are hard in isolation. They are hard collectively, and they are the work that separates "we built an agent" from "we run a platform."
When Retell and Vapi are exactly the right choice
To be clear: there is a real and legitimate use case for these tools.
- You are building a single specialised agent for internal use or one flagship customer.
- You have unique requirements that no platform will ever accommodate — deep custom integrations, novel conversation patterns, experimental tooling.
- You are a platform builder yourself, and you want to own the agent runtime while building the rest of the stack around it.
- You have a team of engineers with the appetite to own the entire surrounding infrastructure.
For those use cases, Retell and Vapi are, genuinely, excellent choices.
When they are the wrong choice
- You are an MSP serving many end customers who do not care what the runtime is.
- Your customers want the platform to get better over time without them having to do anything.
- You do not want to be in the business of manually backfilling prompt changes across your customer base every time the state of the art moves.
- You want compliance, branding, billing, and connections handled as first-class features, not as engineering projects you take on one by one.
Great tools and great products are not the same thing. Retell and Vapi are great tools. dareena.ai exists because most small businesses — and most of the people who sell to them — need a product.