LiveKit’s Voice AI quickstart promises “a simple voice assistant in less than 10 minutes”. The same documentation set states 292 pages across Build Agents, Telephony and Manage & Deploy; deduplicated on 10 September 2026, that is 261 distinct pages, 260 of them after the quickstart. Our estimate: about 22 engineer-days for one inbound line, about 83 for outbound at volume.
This page is the timeline, not the argument. If what you want is whether to build at all, that case is made separately in our build vs buy comparison for AI agents. Here we give the complete method, price it in engineer-days, and leave the conclusion to you — including the profile where building it yourself is plainly the right answer.
What the quickstart covers, and what the other 260 pages cover
Two of the open-source voice agent frameworks teams actually build on publish the size of that gap themselves, in their own index files.
LiveKit’s master documentation index at docs.livekit.io/llms.txt states a page count for every section. Three of those sections describe the work of putting a voice agent on a phone line and keeping it there: Build Agents (223 pages), Telephony (41 pages) and Manage & Deploy (28 pages), the section the index describes as covering deployment, secrets, builds, logs, self-hosted deployments and “observability (insights, traces, data hooks, PII redaction)”. That is 292 in LiveKit’s own count.
Method, so you can repeat it — and where the vendor’s own number is soft: we fetched the three section indexes on 10 September 2026 and counted the entries ourselves rather than trusting the stated totals. Each stated total is exactly the number of entries in that index. The Build Agents index lists 225 bullet entries, two of which are cross-index pointers to other llms.txt files rather than pages, leaving 223. The Telephony index lists 41 and the Manage & Deploy index lists 28. So far the vendor’s arithmetic holds.
Entries are not pages, and that is where 292 overstates it. Deduplicating the 292 entries by URL: the Build Agents index re-lists 26 model-plugin pages a second time under a “Partner spotlight” heading, having already listed each of them under Models; the LiveKit CLI page and the agents events reference each appear in two of the three indexes; and a pointer to the Reference index appears in two of them as well. Strip the repeats and the two cross-section pointers and the 292 entries resolve to 261 distinct pages — one of which is the quickstart. We use the smaller number for the rest of this page, because it is the one that survives being checked. If you see 292 quoted elsewhere, that is an entry count, not a page count.
This is not a LiveKit quirk. Pipecat’s quickstart is described in its own index as “Build and run your first Pipecat voice AI bot in under 5 minutes: a simple conversational agent you can talk to in a browser”, and that same index carried 482 documentation entries when we counted it on 10 September 2026.
| Framework | What the quickstart promises | Documentation pages for the same job |
|---|---|---|
| LiveKit Agents | “Build and deploy a simple voice assistant in less than 10 minutes.” | 292 index entries across Build Agents, Telephony and Manage & Deploy (vendor-stated); 261 distinct pages after we deduplicated by URL (our count, 10 Sep 2026) |
| Pipecat | “Build and run your first Pipecat voice AI bot in under 5 minutes: a simple conversational agent you can talk to in a browser” | 482 entries in the full docs index (our count, 10 Sep 2026; Pipecat does not state a total) |
A quickstart measures the distance to your first sentence. A documentation index measures the distance to a phone number that answers strangers.
The production concerns a quickstart does not cover
Here is the useful version of that 260: each concern mapped to the specific framework page that documents it, the condition under which you can legitimately skip it, and our engineer-day estimate if you cannot. Read the “skip it if” column first — it is where your build gets shorter.
| Production concern | The page that exists because of it | Skip it if | Engineer-days (our estimate) |
|---|---|---|---|
| Prototype: clone starter, wire keys, talk in a browser | Voice AI quickstart | Never | 0.5 |
| Agent logic: instructions, workflows, function tools, CRM writes | Tool definition and use | Never | 5 – 10 |
| Turn-taking: endpointing, interruption thresholds, preemptive generation, noise handling | Turn-taking tuning | Never on a phone line | 3 – 8 |
| Telephony bring-up: SIP trunk, inbound trunk, dispatch rule, outbound trunk | SIP trunk setup | Never, if there is a phone number | 3 – 6 |
| DTMF and IVR navigation: keypad input, menu traversal | Handling DTMF | Inbound only, and no callee ever sits behind a menu | 2 – 5 |
| Answering machine detection: person, voicemail, IVR or dead mailbox | Answering machine detection | You never dial out | 4 – 10 |
| Warm transfer: hold the caller, dial a human, hand over context, recover if nobody answers | Agent-assisted warm transfer | A cold forward by SIP REFER is acceptable | 3 – 6 |
| Provider fallback: what happens when your STT, LLM or TTS vendor returns a 5xx mid-call | Fallback strategies | A dropped call during a provider incident is acceptable | 2 – 5 |
| Testing and evaluation: turn-level assertions plus multi-turn simulation | Testing and evaluation | You will never change the prompt or the model again | 5 – 12 |
| Agent server: registration, dispatch, job lifecycle, graceful drain, deployment, observability | Server lifecycle | One process on one box is your production plan | 3 – 8 |
| Consent state, revocation, do-not-call washing, calling-hours enforcement | 47 CFR 64.1200 | Inbound only and no marketing follow-up (still budget opt-out handling) | 2 – 12 |
| Region pinning and secure trunking: TLS signalling, SRTP media, regional call routing | Secure trunking | No regulatory or contractual requirement for either | 0 – 4 |
The bring-up row is the one that surprises browser-tested teams: a call that works perfectly over WebRTC can arrive over SIP and go silent after the greeting, which is a media negotiation problem rather than an agent problem. We cover the diagnostic side of that in why AI voice agent calls drop and what the ended-reason codes mean. The turn-taking row is the one that decides whether callers think they are talking to a machine; the latency budget behind it is broken down in our explainer on voice AI latency and sub-second responses.
The worked estimate: engineer-days for two real agent profiles
Two profiles, added up in the open. The day figures are our estimates, not measurements — what is verifiable is the scope, because every row above names the page that defines the work. Substitute your own numbers; the structure survives.
| Stage | Profile A: one inbound line, one language, business hours | Profile B: outbound at volume, transfers, follow-up |
|---|---|---|
| Prototype | 0.5 | 0.5 |
| Agent logic and integrations | 5 | 10 |
| Turn-taking tuning | 3 | 8 |
| Telephony bring-up | 3 (inbound only) | 6 (inbound and outbound) |
| DTMF and IVR navigation | 0 (skipped) | 5 |
| Answering machine detection | 0 (skipped) | 10 |
| Warm transfer | 0 (cold forward) | 6 |
| Provider fallback | 0 (accepted risk) | 5 |
| Testing and evaluation | 5 | 12 |
| Agent server, deployment, observability | 3 | 8 |
| Consent, revocation, DNC, calling hours | 2 (opt-out only) | 12 |
| Region pinning and secure trunking | 0 | 0 (add 4 if required) |
| Total engineer-days | 21.5, call it 22 | 82.5, call it 83 |
Turning engineer-days into calendar weeks. Nobody gets five focused days a week on one project. At four, Profile A is 22 ÷ 4 = 5.5 weeks and Profile B is 83 ÷ 4 = about 21 weeks, or roughly five months. At three focused days a week — a realistic figure for an engineer who also owns production for something else — Profile B is 83 ÷ 3 = about 28 weeks.
Turning it into money. Take your own fully loaded cost per engineer-day, call it D. Profile A costs 22D to build. Profile B costs 83D. Then add the run cost below, which is the number that actually decides this. We are deliberately not supplying D: your loaded cost is the only one that matters, and any figure we picked would be doing your arithmetic for you.
An estimate that stops at the build has priced the smaller half.
The 260-Page Rule
Give it a handle so it survives being summarised:
The 260-Page Rule. The quickstart is one page of 261. Budget your build against the other 260.
Two things make the rule concrete rather than rhetorical.
The docs contain asymmetries your estimate has to respect. LiveKit’s answering machine detection page states that IVR navigation starts automatically in Python when ivr_detection is enabled, and then that “The Node.js SDK doesn’t support IVR navigation, so the agent should handle machine-ivr the same as human and let the main agent respond” (read 10 September 2026). Choosing Node.js over Python therefore adds work to a row you had already estimated. Nothing in a quickstart tells you that.
The concerns are discovered, not designed. LiveKit issue #6125, opened 16 June 2026 and still open on 10 September 2026, is a working engineer explaining exactly why answering machine detection is a genuine workstream. The report states that “a carrier voicemail answers the call with a SIP 200 OK exactly like a human does”, so the agent “treats voicemail pickup as a successful human answer: it plays the welcome message, starts billing/recording” and then talks to the voicemail greeting. The author captured trunk-side SIP for both cases and reported them “structurally identical”, concluding that “there is no signaling-level way to distinguish them; the distinction only exists in the media”. That is one row of the table. Note what has and has not changed since: LiveKit now ships answering machine detection as a framework feature, documented with five result categories and six tunable timing thresholds, so nobody has to write a classifier from scratch any more — but it classifies from the media, exactly as the issue said it would have to, and the ten engineer-days in our table are for integrating it, tuning those thresholds against your own carrier mix and writing the branch logic for all five categories, not for inventing the detection.
When building it in-house is genuinely the right call
There is a profile where the honest answer is build it yourself, and it is not a small one.
Build it if all of these are true: one phone number; inbound only; one language; business hours; a human is always reachable, so a cold forward is a sufficient transfer; and you have no obligation to prove consent state for outbound contact. That profile legitimately skips answering machine detection, outbound trunking, IVR navigation, provider fallback and most of the revocation machinery. Our estimate for it is about 22 engineer-days, the result will be genuinely good, and buying a platform would mean paying for capability you will not use.
The line moves when any one of these becomes true: you dial out; you run more than one language; you need a warm transfer with context; you need to prove who consented to what and when; or the agent has to keep answering while a speech provider is having an incident. Each of those switches a skipped row back on, and they tend to arrive together rather than one at a time.
The trap is not building. The trap is estimating Profile A and then, two months later, being asked for Profile B.
What the estimate does not include: the carrier clock
Engineer-days and calendar days are different currencies, and the second one is not yours to spend.
In the United States, carrier and registry gates run on their own queues regardless of how fast your team writes code. Registration is where a launch date usually slips, and we set that out separately, gate by gate, in how long a US AI voice agent launch really takes. Read the two pages together: this one tells you how much work there is, that one tells you how long the waiting is. They overlap almost not at all, which is precisely why teams that plan one of them still miss.
The compliance rows also carry deadlines that belong to the regulator rather than to you. The FCC rule at 47 CFR 64.1200(a)(10) requires that “All requests to revoke prior express consent or prior express written consent made in any reasonable manner must be honored within a reasonable time not to exceed ten business days from receipt of such request”, and states that callers and text senders covered by those paragraphs “may not designate an exclusive means to request revocation of consent”. Building that means a suppression store shared across every channel you contact people on, plus a classifier that recognises a revocation phrased in words nobody put on a list. The consent side of purchased data is a related and separate problem, covered in purchased lead lists, AI voice agents and the TCPA.
What it costs to keep it running
The build number is the one people ask for. The run number is the one that changes the decision, and it never appears in a quickstart because nothing in a quickstart decays.
Four things reliably consume engineering time after go-live, and each one maps to a row you have already built:
- Model and plugin churn. Providers retire endpoints and frameworks move their plugin surface. Every such change is a migration, and every migration invalidates part of the evaluation suite you wrote in the testing row.
- Provider incidents. The fallback row is not a one-off: adding, testing and re-tuning a backup STT or TTS path is recurring work, because the backup provider is never quite the primary and the difference is audible. The mechanics of that row are set out in how to build failover into an AI voice agent.
- Regression re-runs. LiveKit’s own guidance is to run behavioural tests in
pytestorVitestand reserve audio runs for turn-taking and speech-specific issues. Somebody has to own that pipeline, look at the results and act on them; what belongs in it is covered in how to test an AI voice agent before go-live. - Number and caller-ID reputation. This is operational, not engineering, and it does not show up until connect rates start sliding weeks after launch.
Price it the way you priced the build: as a standing monthly engineer-day figure, re-estimated each quarter using the same stage table. Whether that number is smaller or larger than a platform subscription is arithmetic you can now do, and it is genuinely yours to do — the answer is different for a team with an in-house realtime-audio engineer than for a team without one.
For completeness on what the managed side of this layer looks like: Zian AI runs it as a platform, with SmartReach AI™ orchestrating message, channel and timing across phone, SMS, email and WhatsApp, PrecisionPitch AI™ split-testing scripts against real outcomes, 30+ languages, and private model deployment on customer infrastructure for teams that cannot let conversation data leave their perimeter. The outbound-appointments version of the same stack is described in our AI appointment setting page.
Who owns each figure on this page
Every number above belongs to somebody. This table says who, where it came from, and the date we read it — including the rows that are our own estimate rather than anyone’s published fact.
| Figure used here | Owner (organisation) | Source URL | Date checked |
|---|---|---|---|
| Stated section totals: 223 Build Agents, 41 Telephony, 28 Manage & Deploy (292 entries) | LiveKit | docs.livekit.io/llms.txt | 10 September 2026 |
| Independent recount and deduplication of those indexes: 292 entries, 29 of them repeats of a page already listed and 2 cross-section pointers, leaving 261 distinct pages | Zian AI | docs.livekit.io/agents/llms.txt | 10 September 2026 |
| Quickstart claim: a simple voice assistant in less than 10 minutes | LiveKit | Voice AI quickstart | 10 September 2026 |
| Quickstart claim: under 5 minutes, plus the 482-entry index count | Pipecat (claim); Zian AI (count) | docs.pipecat.ai/llms.txt | 10 September 2026 |
| AMD ships in the framework: five result categories, six tunable timing thresholds; the Node.js SDK does not support IVR navigation | LiveKit | Answering machine detection | 10 September 2026 |
| Carrier voicemail and a human both answer with SIP 200 OK | The reporter of livekit/agents issue #6125, not LiveKit | github.com/livekit/agents/issues/6125 | 10 September 2026 |
| Ten business days to honour a revocation of consent | US Federal Communications Commission, reproduced by Cornell Legal Information Institute | 47 CFR 64.1200 | 10 September 2026 |
| Every engineer-day figure, both totals, and the calendar-week conversions | Zian AI — an estimating model, not a measurement | This page | 10 September 2026 |
| 30+ languages, SmartReach AI™, PrecisionPitch AI™, private model deployment | Zian AI | zian.ai questions and answers hub | 10 September 2026 |
Frequently asked questions
More of what buyers and builders ask us is collected in the Zian AI questions and answers hub.
How long does it take to build a voice AI agent in-house?
Talking to a prototype in a browser takes minutes: the LiveKit Voice AI quickstart is titled Build and deploy a simple voice assistant in less than 10 minutes, and Pipecat says under 5 minutes for a simple conversational agent you can talk to in a browser. Getting to a phone number that answers strangers is a different job. Our estimating model, built stage by stage against the framework documentation and published in full on this page, comes to about 22 engineer-days for a single inbound line in one language, and about 83 engineer-days for outbound calling with voicemail detection, transfers and consent handling. Those are estimates, not measurements. The scope behind each row is verifiable; the day figures are ours to argue with.
What takes the longest when I build a voice agent myself?
Not the prompt. In our outbound profile the two largest line items are the test and evaluation harness and consent and revocation handling, at 12 engineer-days each, with agent logic and answering machine detection tied behind them at 10 each. Turn-taking tuning is next at 8, and it is the one teams most often discover only after real callers start interrupting the agent. Four of those five are invisible in a demo, which is why the demo is a poor basis for an estimate.
Do I need answering machine detection if my agent only takes inbound calls?
No. Answering machine detection is an outbound problem, and dropping it is one of the largest single savings available to an inbound-only build. If your agent never dials out, you can also skip outbound trunk configuration and IVR navigation. Those three rows together are 18 engineer-days of the 61-day gap between our 22-day and 83-day profiles.
If I build it myself, do I also have to build consent and opt-out handling?
In the United States, yes, and it is more work than most estimates allow. The FCC rule at 47 CFR 64.1200(a)(10) requires that all requests to revoke prior express consent or prior express written consent made in any reasonable manner must be honored within a reasonable time not to exceed ten business days from receipt of such request. The same paragraph says a caller covered by it may not designate an exclusive means to request revocation of consent, and that a text reply using words other than the seven listed stop words must still be treated as a valid revocation if a reasonable person would understand it that way. That is a semantic classifier, a cross-channel suppression store and an audit trail, not a checkbox.
Can two engineers build it in half the time?
Only partly. Agent logic, the evaluation harness and observability parallelise well. Telephony bring-up does not: trunk configuration, dispatch rules and the first successful inbound call are a serial dependency, and so is anything that needs a real phone number. Assume the parallelisable share is roughly the agent-side work and treat the telephony and registration path as fixed-length regardless of headcount.
Is a self-built voice agent ever finished?
No, and that is the number most build estimates omit. Model providers retire endpoints, framework plugins move, speech providers have incidents that your fallback path has to survive, and every one of those events invalidates part of your evaluation suite. Budget a standing monthly engineering commitment alongside the one-off build, and re-run the stage table each quarter rather than treating the original estimate as spent.
Apply For Partnership
Zian AI is in a partnership-application beta. There is no free trial and no self-serve signup — every deployment starts with a conversation about which rows of the table above you actually need. If you have run the arithmetic and want to compare it against a managed deployment, Apply For Partnership.