Most answers to this question describe the build. The prompt handling, the latency budget, the transfer logic, the CRM write-back.
That part is real work, and it is the part I do. It is also not the part that decides when your agent actually starts taking calls.
I am Ussama Assad. I build and debug production voice agents, and the most misleading sentence in this work is "build complete."
The status report that is true and useless
A voice build reaches a point where every feature is implemented, every outbound path is gated, and the test suite is green. On paper it is finished.
It still cannot place a call.
Not because something is broken. Because the remaining work is access and sign-off, and none of it is code. A status report that says build complete is technically accurate. The buyer reads it as we can start next week. Those are different claims, and the gap between them is where projects that are genuinely on schedule still miss their dates.
The four gates, none of which compress with effort
Platform review. An integration that touches someone else's production data needs their approval. That review takes as long as it takes. You cannot escalate it by working harder, and no amount of engineering readiness moves it forward.
Account provisioning. A production voice account, a live number, credentials that only you — the business — can issue. The build can be entirely finished while the account it is supposed to run on does not yet exist. This one surprises people most, because it feels administrative rather than technical, and it sits directly on the critical path.
Consent basis. Before an automated system calls a real person, the legal ground for that contact has to be verified against your own records. Not assumed, and not inherited from a form somebody filled in two years ago. This is a question your records answer, not one your builder can answer for you.
Sign-off on language. What the system is allowed to say in your name. Approved phrasing, the templates, the boundaries.
Each of these sits outside the codebase. Each is owned by someone who is not the engineer.
Why this belongs at the start of a project
Here is the part worth keeping, and it is the reason I put it in an article rather than a status email.
That list, delivered at the beginning of a project, is a project plan. The same list, delivered at the end, is an excuse. It is the same list. Only the timing changes what it is.
So the honest way to run one of these builds is to report two tracks separately: engineering progress, and launch readiness. They are different numbers. Engineering can be finished outright while launch readiness has barely moved, because a platform review has not come back. Conflating them produces a green status report attached to a date nobody can hit.
And the access path is not something to hand over at the end. It runs in parallel with the build from day one, because the gates are sequential and mostly waiting — every week of delay on a platform review pushes launch by exactly that week, and no engineering sprint recovers it.
What this means if you are the one hiring
If you are choosing someone to build a voice agent, the question that separates an experienced builder from an optimistic one is not when will it be done?
Every builder answers that question the same way, and the answer is about code.
The better question is: what has to happen that isn't code, and who owns each of those things?
A builder who has shipped these will answer immediately, name the gates, and tell you which ones you own. A builder who has not will treat it as a detail to sort out later — and later is precisely when it becomes an excuse rather than a plan.
What I will and will not tell you
I will not promise you a launch date on day one, because four of the things that set it are not mine to control.
What I will do is state which gates apply to your build before the work starts, tell you who owns each one, drive the access path alongside the engineering instead of after it, and report the two tracks separately so the number you are looking at means what you think it means.
The system gets built correctly and I stand behind it when it breaks. The calendar is a shared problem, and the honest version of this work says so at the beginning.
Written by Ussama Assad — I build cold email infrastructure, lead pipelines and production voice agents, and I fix the ones that break. More at my site.
