TL;DR: The agent is the fastest part. With the build and test pipeline I use, I can hand you a number to call within a day. A live agent answering a real business line is usually two to four weeks, and almost none of that time is spent building the agent. It goes on access to other people's systems, on knowledge nobody has written down, on the automation behind the call, on whoever has to approve the words, and on a deliberately slow ramp onto the main number. Six to eight weeks means one of five specific things went wrong, and you can usually see all five on the first call.
This is the question every discovery call arrives at, usually in the last five minutes, and the honest answer annoys people in both directions. It is faster than agencies quoting three month engagements imply, and slower than a demo video suggests.
I have built production voice and chat agents for UK hospitals, vet clinics, estate agents and car garages at Fortell AI, and for a US product at Tested Media where calls land in GoHighLevel and clients watch them arrive in a dashboard. The variance between those projects was never the agent. It was everything the agent had to be plugged into.
The short answer, split three ways
A demo you can phone: a day. One call type, the real greeting, real questions, no integrations behind it. This is a sales artefact and a scoping tool, not a product.
A simple agent answering real calls: two to three weeks. One business, one number, one or two call types, booking into a calendar, leads landing in a CRM, a working transfer to a human. This covers most single location businesses.
Anything touching a system that is not a mainstream SaaS: four to eight weeks. Legacy practice management software, a bespoke booking system, several locations with different rules, or a regulated vertical where somebody has to sign off every sentence before it goes live.
Those numbers assume the client is available roughly twice a week. They are not engineering estimates. They are estimates of how fast two organisations can make decisions together, which is a different thing and the actual constraint.
Why the agent is the fastest part
At Fortell AI I put together a pipeline that builds and tests agents in minutes, using Claude Code to scaffold the agent and Comet browser automation to drive it through messy call scenarios. Before that, a first version of an agent was an afternoon. After it, a first version was closer to a coffee.
That sounds like it should collapse project timelines. It does not, and understanding why is the whole point of this article.
Making the agent fast to build changes the shape of the work rather than the length of it. What it bought me was iterations: I can rebuild an agent from a changed spec cheaply enough that I stop defending the previous version, and I can run it against thirty awkward calls before a human hears it. The project still moves at the speed of the slowest thing it depends on, and that is never the prompt.
This is also why demo speed misleads everybody. A demo skips the five things that take the time. Nobody is lying to you when they build an agent live on a call in twenty minutes. They are showing you the part that was never the problem.
Where the weeks actually go
Access to systems you do not own
Almost every build needs a calendar, a CRM, and whoever administers the phone system. Each of those is a person who has to find a login, decide you can be trusted with it, and remember to do it.
I now settle this during the scoping call: not "do you use a CRM" but "who can grant access to it, and are they in this conversation". A build that is waiting on a login is stopped, not slow, and a week can disappear to somebody's annual leave.
The knowledge nobody has written down
This is reliably the single biggest item, and clients never expect it.
An agent needs to answer what a business actually gets asked, which is a different set of facts to what is on the website. Prices with conditions attached. Which of the five things the business does it would rather not talk about on the phone. What happens on a bank holiday. The vet who does not work Wednesdays. None of it exists as a document, because it lives in the heads of two people at a front desk who have never had to say it out loud in a complete sentence.
Extracting it, writing it in the shape an agent can use, and getting somebody to confirm it is true takes days of elapsed time even when the work is hours. Asking for the last twenty calls rather than a description of a typical call is what shortens it most.
The back half
The conversation is the visible part. The part that actually decides whether the project is a success is what happens after the caller hangs up: the booking write, the CRM record, the confirmation message, the notification, and every failure path underneath them.
I run that layer in n8n behind a webhook rather than in platform workflows, and it routinely takes longer to build than the agent. Not because it is hard, but because that is where the real business rules turn up. Which calendar, whose calendar, what if two people book the same slot, what if the CRM already has this contact, what if the text fails to send. Those failure paths are the whole job, and you cannot discover them from a happy path conversation.
Somebody has to own the words
An agent speaks on behalf of a business, so a human on the client side has to read the refusals, the escalation lines and the greeting, and say yes.
In a garage or an estate agency that is the owner and it takes an afternoon. In healthcare it is a committee and it takes two weeks. This is not wasted time and I do not try to shortcut it, because an agent that says something the business does not stand behind is a worse outcome than an agent that launched a fortnight later.
Telephony has lead times you cannot compress
Phone numbers, forwarding rules and messaging registration run on other people's clocks. I forward rather than port on day one precisely because porting a number is a multi week process with a risk attached, while a forwarding rule is a thirty second change the client can reverse themselves.
If the build includes SMS to US numbers, A2P registration is days of waiting on carriers regardless of how organised everyone is. Start it in week one, not the week before launch.
Testing the calls nobody wants to imagine
The last stretch is running the agent against callers who mumble, change their mind, give a mobile number in three chunks, or ring about something entirely outside its scope. That work produces a frozen scenario set you keep forever, and it is the difference between an agent that demos well and one that survives a Monday morning.
A realistic calendar for a straightforward build
- Day 0: discovery call. Numbers, the last twenty calls, refusals, who owns access and who owns the words. Output is one page.
- Days 1 to 2: first agent, on a test number, answering the main call type. The client phones it and reacts to something real rather than to a document.
- Days 3 to 7: the back half. Calendar, CRM, messages, failure handling. In parallel, chasing access and the knowledge that is still missing.
- Week 2: messy call testing, refusals, transfer destinations, the scenario set. Client listens to recordings and approves the words.
- Week 2 or 3: go live on after hours and overflow only, through a forwarding rule. Real callers, nothing at risk that was previously being handled.
- Week 3 or 4: listen, batch the fixes, then widen to the main line once nothing structural is landing.
The go live date most people care about is the middle of that list, not the end of it. The agent is taking real calls in week two or three. It is taking all of them a week or two later.
What turns two weeks into six
Five things, in the order I see them:
- Multiple decision makers and no named owner of the words. Every round of feedback contradicts the last one.
- No existing process. If three staff handle the same call three different ways, the build has to encode one of them, and that is a business decision the client has not made yet.
- A dependency on a third party. A legacy system with no usable API, or a vendor whose support queue is two weeks long.
- Scope that starts at five call types. Start with one and add the second once the first is boring.
- Porting the number up front instead of forwarding, which puts a carrier process on the critical path for no benefit on day one.
What the client can do to halve it
Have the last twenty calls ready. Name one person who can approve wording without a meeting. Grant access before the kickoff rather than after it. Pick one call type. Confirm you can change a forwarding rule yourself, or who can.
Do those five and the elapsed time collapses towards the working time, which is where my estimates come from in the first place.
The short version
- A demo agent is a day. A live agent on a real line is two to four weeks for most businesses.
- Building the agent is the smallest item in that budget, and making it faster does not shorten the project.
- The time goes on access, undocumented knowledge, the automation behind the call, approval of the words, and telephony lead times.
- Go live is a ramp starting in week two or three, not a switch flipped at the end.
- Six weeks and up nearly always means scope, a missing decision maker, or a dependency on someone outside the project.
If somebody quotes you three months for a single location phone agent, ask what is in the other ten weeks. If somebody quotes you three days, ask what happens after the caller hangs up. The honest number sits between those two, and what it costs follows the same logic.
I build production AI voice agents and the automation, CRM and telephony layer behind them for founders across the US, UK and Europe. More about my work here, or book a call.