The short answer

The honest answer to how long it takes to build an AI agent is that it depends on the definition of done, not on the model. A narrow automation, one workflow with a clear trigger and a clear output, can land inside a week or two. A production agent with tool access, guardrails and an eval suite typically runs the full fixed-scope window of two to four weeks. A multi-tenant product with roles, permissions and admin surfaces runs longer than that, and Estate360-class scope is the honest shape of that situation.

For calibration, look at GAP Miner: it went from a 10-day manual research workflow to roughly 15 seconds of automated analysis. It got there because the scope was cut to one narrow job before any code was written, not because the model was magic. The case study lives at kunjshah.in/projects/gap-miner.

The same math shows up everywhere in agent delivery. A proof of concept that reads a single inbox and drafts replies is an afternoon of wiring plus real time on evals, data cleaning and review until it is trustworthy. The model was never the bottleneck; the workflow around it is. When someone quotes you a quarter for "an AI agent", they are usually quoting the data plumbing, the permission model and the review loop, not the inference call.

Anyone who quotes you a single number for "an AI agent" is selling, not estimating. The real drivers are the size of the workflow, the state of your data and how fast decisions get made on your side. Two engagements with identical model stacks can differ by weeks based on those three things alone.

The four steps, in order

Every fixed-scope engagement I run follows the same sequence, and each step exists to remove a specific failure mode. Skip a step and you do not save time; you defer the cost to a worse week.

  1. A 15-minute intro call. We look at the workflow, the data, the systems involved and the cost of getting it wrong. If the fit is bad, I say so on the call. No pitch deck, no obligation.
  2. Written scope with a fixed INR price before work starts. You get the scope in writing with a fixed price, so there is no invoice surprise and no moving target. Fixed-scope work starts at ₹25,000 and is typically delivered in two to four weeks. Payment is 40% upfront and 60% on delivery. If you prefer hourly, the rate is ₹1,500 per hour. If you need ongoing coverage after delivery, the retainer runs ₹30,000 to ₹75,000 per month.
  3. Build in your repository, on your cloud. From the first commit, the code lives in your repo and deploys to your cloud account. When the project ends, you own the code, the prompts, the eval suite and the deployment scripts. Nothing is held hostage on my machine, and your team can audit every decision because the history is yours.
  4. Handover with two revision rounds. The agent ships deployed, tested and logged, with a handoff document that explains what it does, what it refuses to do, and how to operate and debug it. Two rounds of revision are included, so the last mile is not a negotiation.

What makes it fast

Four things compress a build more than any technical choice. If you do these well, the two to four week window is realistic rather than optimistic.

  • A written definition of done. Not "the agent works", but the exact inputs, outputs, edge cases and quality bar that count as done. If we disagree on what done means, we find out in week one instead of week four.
  • A small labeled eval set up front. Twenty to fifty real examples with known-good answers. This turns "it seems to work" into a number, and it lets every change be measured instead of vibes-tested.
  • Read-only access to real data early. Agents fail on the data you forgot to mention. Read-only access in the first days exposes the missing columns, the encoding issues and the duplicate records before they become rework.
  • One decision-maker on your side. One person who can say yes, one who can say no, ideally the same person. Committees add weeks; a single owner removes them.

What stretches it

These are the six failure modes I see most often, in rough order of how much damage they do to a timeline.

Auth and permissions. Every permission system is bespoke. SSO, role hierarchies, least-privilege tokens, audit logs: these are engineering problems, not configuration problems. If the agent must act on behalf of different users with different rights, expect the auth layer to rival the agent layer in effort. Do not let it be improvised at the end.

Messy or missing data. The demo data is clean. Your production data is not. Duplicates, stale rows, free-text fields that quietly contain three comma-separated values, PDFs scanned at a slight angle. Data cleanup is unglamorous and it is usually where the hidden weeks live.

Third-party API instability and rate limits. When your agent depends on an external API, their outage is your outage and their rate limit is your rate limit. Retries, backoff, caching and graceful degradation all have to be designed, not bolted on. A flaky upstream can double the test matrix and eat the buffer you thought you had.

Compliance and review loops. Legal, security and privacy review add real time, and they should. If the agent touches personal data or customer communications, plan for review cycles and make sure the reviewers see the guardrails and the eval results, not just the polished demo.

An unclear definition of done. "Make the support agent better" is not a deliverable. Without explicit acceptance criteria, every demo is a fresh negotiation and the project never closes. This is the most common and the most expensive stretch factor.

Scope creep. One more tool, one more integration, one more "while you are in there". Each addition is individually reasonable and collectively fatal to a fixed timeline. Fixed scope exists to protect both of us from this, and the written change-request path is not bureaucracy; it is the mechanism that keeps the date honest.

Why not just buy a SaaS agent?

Fair question, and the honest answer cuts both ways.

Build when the workflow is yours. If the process, the data or the definition of quality is specific to your business, off-the-shelf tools will approximate it badly. Building is right when your data is sensitive and cannot leave your cloud, when the workflow crosses three systems no single vendor covers, and when the quality bar is yours to define. That is the situation fixed-scope builds are for, and it is why the code lands in your repository from day one.

Buy when the workflow is generic. If your need is drafting replies to common support tickets or summarizing meeting notes, a SaaS tool probably does it well enough and far cheaper than a custom build. Do not pay for bespoke engineering to avoid reading a pricing page. If the tool fits, buy it and spend the savings on the workflow it does not cover.

The middle ground is common: buy the commodity layer, build the differentiating one. The eval set is the tiebreaker. If you cannot articulate how you would measure the bought option, you are not ready to buy or build either; start with the evaluation, then decide. A vendor that refuses to be measured against your data is telling you something.

A useful rule of thumb from the field: if a SaaS tool covers most of your workflow out of the box and the remaining edge cases are politically important, buy the tool and build around it. If that remaining slice is where all the value lives, the tool is a distraction and a custom build is the honest answer.

How to keep yours on schedule

Schedule discipline is not about working faster. It is about removing the decisions that stall.

  • Fixed scope and fixed price, agreed in writing before the first commit.
  • Definition of done in writing, with acceptance criteria you can point at.
  • A weekly demo: thirty minutes, real data, real screen. Short feedback loops beat perfect plans.
  • One owner on your side with authority to accept delivery.
  • The eval set reviewed and signed off in week one, so every later change has a scoreboard.

If any of these are impossible on your side, a longer or phased engagement is not a failure; it is the correct estimate. The wrong estimate is the one that pretends the constraint does not exist and then rediscovers it in week three.

The practical next step

If you have a workflow in mind, bring it to a 15-minute call. I will tell you honestly whether it is a week, a month or a rewrite, and if it is out of scope for what I do, I will say that too. Fixed quote in writing, no surprises. Reach me at kunjshah.in/contact or kunjkshah05@gmail.com.