A Draft Takes a Minute. Production Takes a Month.

Somewhere right now there is a VP of Customer Experience in month five of a deployment that was sold to them as taking minutes.

They’re not stupid. They didn’t misread the homepage. The homepage said “deploy in minutes,” and that claim was, in a narrow, technically defensible sense, true. Someone really can produce a working voice agent in minutes on most modern platforms, including ours. What the homepage didn’t say is that the thing you can produce in minutes and the thing your compliance team will let you point at real customers are separated by an ocean.

So they’re in month five. The agent works. It has worked for eleven weeks. It’s sitting behind a flag while security review, telephony provisioning, PII handling sign-off, penetration testing, and a change advisory board make their way through a queue. And every time they walk past the poster in the lobby that says “AI moves fast,” they feel a small, specific kind of anger.

We would rather not be the vendor that produces that feeling. So here are both of our numbers.

A first working draft takes about a minute.

On the eighteenth of August 2026, we timed a Lightning-mode build: from submitting the initial prompt to a finished draft, with tools, prompt and configuration all generated. One minute.

One important qualifier, because it’s the kind of thing vendors quietly drop: that was a single timed run, not an average across many builds. We’re describing it as “about a minute” rather than presenting it as a benchmark, because one run is an observation and a benchmark is a distribution. When we’ve run enough of them to publish a distribution, we will.

A production deployment takes weeks to about a month, depending on complexity.

That’s the real number for a regulated enterprise deployment, the kind with data integrations, compliance review, telephony provisioning, and a business that will notice if it goes wrong. Our most recent production migration, a live outbound collections deployment for a major Latin American telecom operator, took five weeks from first end-to-end call to full production volume. The whole calendar is published in We Migrated a Telecom Collections Deployment in Five Weeks, including the honest part about how much of that was us and how much was waiting.

There’s an obvious commercial argument for only publishing the first one. It’s a better headline. It wins the top-of-funnel comparison. Everyone else is doing it.

Here’s why we think it loses the deal that matters.

The buyer who is going to sign a meaningful enterprise contract has been through this before. They have a scar. When they read “deploy in minutes,” they don’t think excellent, minutes. They think this vendor is either naive about my environment or willing to mislead me about it, and I’ll find out which one in month three. The claim doesn’t build confidence with a sophisticated buyer. It actively erodes it.

Competitors blur these two numbers deliberately, and the blur is visible if you read carefully. One competitor’s homepage promises deployment in minutes, while a page deeper into the same site quietly concedes a few weeks. Across the wider category, published deployment timelines run from a couple of days to most of a year, and the fast end of that range almost never comes with a statement of what was in scope or whether anything was actually being replaced.

Volunteering the second number does three things at once. It makes the first number credible, because a vendor willing to tell you the slow number probably isn’t inflating the fast one. It signals that we understand what production actually costs you, the review cycles, the change windows, the internal dependencies that have nothing to do with our software. And it filters. If a one-minute draft is genuinely all someone needs, brilliant, our Lightning path is right there. If they need a regulated production deployment, they now have a real number to plan against instead of a disappointment scheduled for month three.

Buyers in banking, insurance and healthcare have been burned by the first claim. They will trust the vendor who states the second.

The two numbers aren’t in tension. They serve different jobs, and the platform offers three paths so the effort matches the complexity.

Lightning: the specialists run end to end and hand you a finished draft. Right for smaller use cases, internal tools, proof-of-concept work, and the case where you need something in front of a stakeholder this afternoon.

Guided: for large, high-accuracy deployments needing oversight. The specialists produce, humans review at each stage. This is the path for anything customer-facing in a regulated industry.

Manual: minimal AI involvement after the initial build, for teams who have specific opinions and would like to implement them personally.

The same ten specialist sub-agents sit behind all three paths, we’ve written about why that architecture matters in Ten Specialists, Not One Assistant. What changes between paths is how many checkpoints a human occupies.

If a draft takes a minute, where does a month go? Almost none of it is building.

Testing across transports, which is more work than it sounds. An agent that works over a microphone has told you very little about how it behaves over a carrier. The platform offers five testing modes, Voice for a fast sanity check, WS Voice for the WebSocket path an embedded client hits, SBC Sim for the simulated telco layer, Chat for pure conversation logic with no audio variables, and Live for the real thing inbound and outbound. Beneath those sit eight component-level harnesses covering call, flow, code execution, retrieval, transfer, DTMF, data store and portability.

Two of those deserve specific mention. SBC Sim simulates the session border controller, validating headers, transfer behaviour and UUI payloads without touching a carrier, which matters because in a regulated contact centre, the telecom team’s change window is frequently the slowest dependency in the entire deployment. Carrier-layer test tooling exists in this market as separate products you buy and integrate; the difference is that this is a mode inside the platform you’re already working in. And Chat mode isolates conversation logic from speech recognition, which turns “is this a prompt problem or an audio problem?” from a guess into a test. Not wasting a working session chasing the wrong layer is a meaningful fraction of why a five-week migration was five weeks.

A note on competitive framing, since we would rather be precise: one competitor leads on test breadth, publishing a large catalogue of pre-production scenarios. Ours is test depth across transports. Those are complementary claims and we are not going to imply we match their scenario count.

Integration reality. Six handler types, REST webhooks, custom Python functions, call transfer, DTMF capture, retrieval queries, native Firestore, plus around twenty built-in tools. The custom code tool runs sandboxed with a warm-pool executor and a stable egress address, which is specifically what lets it call a customer API sitting behind an IP allowlist. That last detail sounds like plumbing and is routinely the thing that decides whether a deployment is possible at all.

Everything that isn’t us. Security review. PII handling sign-off. Telephony provisioning. The change advisory board. This is usually the largest block, and it’s why we publish working sessions alongside calendar time.

We can get you a working draft in about a minute. We think that’s genuinely useful, and it changes how fast you can explore what’s possible.

We can get a real production deployment live in weeks to about a month, and we can show you a five-week migration calendar with the dates and call volumes on it.

Anyone who tells you those are the same number has either never deployed into a bank, or is hoping you haven’t.