How long it takes to build an AI agent.
A working agent demo takes an afternoon. An agent you can put your name on in production takes weeks. The gap between the two is the whole job.
The honest answer to "how long does it take to build an AI agent" is two numbers, not one. A convincing demo lands in days. An agent you trust with real customers, real money, and an on-call rotation lands in weeks — and most of those weeks are spent on the work that has nothing to do with the model. We run that work in two-week cycles so the timeline stays legible: you see something real at the end of every one.
A demo and a production agent are different projects.
The reason estimates for AI agents range from "a weekend" to "a quarter" is that people are answering two different questions. A demo proves the idea is possible. A production agent proves the idea is safe, reliable, observable, and cheaper to run than the problem it replaces. The model gets you the first one almost for free. Everything around the model gets you the second one.
Frontier models — the current Claude family (Claude Opus 4.8, Claude Sonnet 4.6, Claude Haiku 4.5, Claude Fable 5) with a 1M-token context window — are good enough that the prompt is rarely the bottleneck. The bottleneck is tools, data access, failure handling, evaluation, and the operational scaffolding that keeps the thing honest at 3am. That is where the weeks go, and that is why we quote production timelines in cycles rather than hours.
A demo is days. A first production agent on a contained workflow is roughly two to three cycles. A multi-step agent wired into live systems with real SLAs is four to six. The variance is set by your data and your integrations — almost never by the model.
Five phases, mapped to two-week cycles.
We deliver in two-week cycles because the agent is only as good as its feedback loop, and a fortnight is short enough to keep that loop tight. Each phase ends with something you can run, read, and react to. The phases overlap at the seams — hardening starts before v1 is fully done — but the shape is consistent across engagements.
Discover — what is the agent actually for?
A few days, not weeks. We map the workflow the agent is meant to own end to end: the inputs, the decisions, the systems it must touch, and — critically — what a wrong answer costs. The output is a written scope, a definition of "done", and the first draft of the eval set: the concrete cases the agent has to get right before anyone trusts it. Skip this and you build a confident agent for the wrong job.
Architect — tools, data, and guardrails.
We decide how the agent reaches your systems. In practice that means the Messages API for the core loop, tool definitions for every action it can take, and — where the agent needs typed, governed access to your data and services — the Model Context Protocol (MCP). This phase produces the integration map and the trust boundary: what the agent may do autonomously versus what requires a human in the loop.
Ship v1 — the narrow agent that actually works.
The first production agent does one workflow well, not five workflows badly. We wire it to real (or realistically sandboxed) systems, instrument every tool call, and run it against the eval set from day one. By the end of this cycle there is a deployed agent doing useful work on a contained slice of the problem, with logs you can read.
Harden — make it boring.
This is the cycle most demos never reach, and the reason demos are not products. Retries, timeouts, rate-limit handling, fallbacks when a tool fails, prompt-injection defenses on untrusted inputs, cost ceilings, and the eval suite expanded with every failure mode found in v1. The agent gets less impressive and more dependable. That trade is the entire point.
Operate — the part most teams forget to budget.
An agent is a living system: models update, your data drifts, edge cases surface in production that no eval predicted. We run what we ship under an SLA with on-call, watch cost and latency, and feed real failures back into the eval set so the agent gets better instead of quietly worse. Operate is not a phase that ends — it is the steady state, and it is why the timeline question has no final answer.
A realistic table, in cycles.
These are working ranges, not promises — your integrations and your data set the real number. We commit to a specific timeline only after Discover, because that is the first point at which the estimate is honest. Each "cycle" is two weeks.
| Agent type | Example | To v1 | To operated |
|---|---|---|---|
| Single-step assistant | Drafts replies, summarizes a queue, classifies tickets | ~1 cycle | ~2 cycles |
| Contained workflow agent | Triages and routes, with one or two governed tool calls | ~2 cycles | ~3 cycles |
| Multi-step agent on live systems | Reads CRM, takes actions, escalates to a human | ~3 cycles | ~4–5 cycles |
| Multi-agent or high-stakes system | Money movement, regulated decisions, several cooperating agents | ~4 cycles | ~6+ cycles, then ongoing |
Note the gap between "to v1" and "to operated" widens as stakes rise. A single-step assistant is nearly done when it works. A money-moving agent is barely started when it works — the hardening and operating columns are where the trust is built. For the budget side of the same decision, see what it costs to build an AI agent, and our engagement shapes map cleanly onto these cycle counts.
The things that buy you weeks.
- Clean, reachable data. If the agent can already query the systems it needs through an API, you skip the slowest part of integration. A documented MCP server over your data turns weeks of glue code into days.
- A narrow first workflow. One job done well ships in a cycle; "an agent that does everything" never ships. Scope is the single biggest lever on speed.
- Eval cases ready on day one. If you can hand us 30 real examples with known-good answers, we start measuring immediately instead of guessing.
- A decisive owner. One person who can answer "is this output acceptable?" without a committee removes the longest hidden delay in every agent project.
- Building Claude-native from the start. Standardizing on the Messages API, MCP, and the Claude Agent SDK — and running it on Bedrock or Vertex AI where your governance requires — avoids the rebuilds that come from gluing together mismatched tools.
The things that quietly add cycles.
- Data that lives in five places, half of it in PDFs and screenshots. Access and extraction become the project, and the agent waits on them.
- Integrations with brittle, undocumented, or rate-limited internal systems — the agent is only as reliable as the worst API it depends on.
- No agreed definition of "good". If nobody can say what a correct answer looks like, the eval set never converges and the agent never finishes.
- High stakes with no human-in-the-loop appetite. Full autonomy on consequential actions demands far more hardening than a system that escalates the hard cases.
- Scope that grows mid-flight. Every "while you are in there, can it also…" resets part of the eval set and pushes the timeline right.
Notice that almost nothing on either list is about the model. Agents are slow to build for the same reason any production software is slow to build: integration, data quality, failure handling, and agreement on what "done" means. The model is the easy part.
Why measuring first makes everything faster.
The fastest way to a trustworthy agent is to build the way you measure it before you build the agent. An eval set — a collection of real inputs with known-good outputs — turns every prompt change, tool addition, and model swap from a debate into a number. Without it, every iteration is somebody arguing that the output "feels" better; with it, you ship when the score clears the bar you set in Discover.
# Run the agent across the eval set and gate on a pass threshold.cases = load_eval_cases("eval/triage.jsonl") # real inputs + known-good outputs results = []for case in cases: out = agent.run(case.input) # the agent under test results.append(grade(out, case.expected)) # rubric or model-graded check pass_rate = sum(r.passed for r in results) / len(results)print(f"pass_rate={pass_rate:.0%} over {len(cases)} cases") # Ship gate: agreed in Discover, enforced in CI on every change.assert pass_rate >= 0.95, "below ship threshold — do not deploy"Counterintuitively, the eval set is what makes the whole timeline shorter. It collapses argument into measurement, makes regressions visible the moment they appear, and lets us swap models or refactor tools with confidence instead of fear. Teams that skip it do not save the eval-building time — they pay it back, with interest, in the hardening phase.
You do not finish an agent when it works once. You finish it when it works on every case you agreed mattered — and you can prove it.
A short checklist before you start the clock.
Run through these in order. Each one you can answer crisply pulls your timeline toward the low end of the table; each one you cannot pushes it toward the high end.
- Name the single workflow. Write down the one job the agent owns end to end. If you list three, you have three projects.
- Cost a wrong answer. Decide what a mistake costs in money, time, or trust — this sets how much hardening the project needs.
- Locate the data. List every system the agent must read or write, and how it reaches each one. Anything not behind an API is a flag.
- Collect the eval cases. Gather 20–50 real inputs with the answers you would accept. This is your definition of done made concrete.
- Set the trust boundary. Decide what the agent does autonomously versus what a human approves. Be explicit; the default is too much trust.
- Pick the owner. Name the one person who can say "yes, ship it." Their availability is on the critical path whether you plan for it or not.
If you can answer all six today, a contained agent reaches a trustworthy v1 inside two or three cycles. If you cannot, that is fine — answering them is exactly what the Discover phase is for, and it is cheaper to spend a week there than a wasted month everywhere else. This is the work behind our AI workflow automation engagements, and the same scoping discipline carries into a custom SaaS build when the agent grows into a product.
So — how long, really?
A demo this afternoon. A first production agent in two to three cycles. A serious, operated, multi-step agent in four to six, then a steady state of operation that never fully ends. The model is fast; the trust is slow. Build the eval first, scope the workflow narrow, get the data reachable, and the timeline behaves. Skip those, and no amount of model quality saves you.
Questions, answered.
A working demo takes days. A production agent you can trust takes weeks: roughly two to three two-week cycles for a contained workflow, and four to six for a multi-step agent wired into live systems with real SLAs. The variance comes from your data and integrations, not the model.
A demo proves the idea is possible; a production agent proves it is safe, reliable, observable, and cheaper than the problem it replaces. Almost all the extra time goes to integration, data access, failure handling, evaluation, and the operational scaffolding around the model — not the model itself.
Clean data already reachable through an API, a narrow first workflow, real eval cases ready on day one, one decisive owner who can approve outputs, and building Claude-native from the start so you avoid mid-project rebuilds.
Data scattered across systems and locked in documents, brittle or undocumented internal APIs, no agreed definition of a good answer, demands for full autonomy on high-stakes actions, and scope that grows mid-flight. None of these are model problems.
An eval set is a collection of real inputs paired with the answers you would accept. It turns every change into a measured score instead of an argument, makes regressions visible immediately, and lets you swap models or tools with confidence. Building it first makes the whole project shorter, not longer.
It enters the Operate phase — the steady state. Models update, data drifts, and new edge cases appear in production, so we run what we ship under an SLA with on-call, watch cost and latency, and feed real failures back into the eval set so the agent improves instead of quietly degrading.