If you are planning an AI agent project, the honest starting point is this: an agent is not a model with a prompt. It is a small software system with tools, state, verification and a handover plan, wrapped around a model that will sometimes be wrong. The projects that ship treat the model as one component among several. The projects that stall treat it as the whole product.
I am Kunj Shah, an AI engineer in Ahmedabad. I have shipped 17+ systems and merged 60+ PRs across 24 external repositories. This guide is how I scope, build and verify agent work for clients and for my own products. It is written for a founder or engineering lead deciding whether to commission an agent, and for the engineer who will have to maintain it afterwards.
What an agent project actually consists of
Every agent engagement I have taken on decomposes into five parts. If a proposal skips one of them, the proposal is incomplete, not lean.
- Scope. One narrow task with a written definition of done. "Handle customer support" is not scope. "Draft a first response to billing disputes using our policy docs, escalate anything with a refund over the limit" is scope.
- Tools. Typed contracts for every action the agent may take: search, read, write, call API, send message. Each tool needs an input schema, an error model and a permission boundary.
- State. What the agent remembers between steps and between sessions, and where that lives. For anything multi-step, this usually means a checkpointed graph, not a growing string in a prompt.
- Verification. An independent check that the agent's claimed output is actually correct. This is the part most projects skip, and the part that decides whether you can trust the system.
- Handover. Code in your repo, your cloud, a short handoff doc, and a rollback story. An agent you cannot inspect is an agent you cannot operate.
The build order that works
I build in this order, and I push back on clients who want to reorder it. Each step produces an artifact the next step depends on.
1. Narrow the task until it is boring
The first milestone of any agent project should be unglamorous. Pick the single highest-frequency, lowest-risk slice of the workflow. If the workflow is reviewing pull requests, start with dependency-bump PRs, not architecture changes. Breadth comes later; correctness comes first.
2. Write tool contracts before prompts
For each tool: name, purpose, parameters, return shape, failure modes, and what the agent must do when the tool fails. Contracts written first expose the impossible parts of the task early. They also make the agent testable without the model in the loop, because you can fake the tools and check the wiring.
3. Model the flow as an explicit state machine
Implicit control flow is where agent projects rot. Make the states and transitions explicit: plan, act, verify, retry, escalate. Graph-first orchestration (I use LangGraph in every production system I ship) forces you to name every edge, including the failure edges, and gives you checkpointing and human-in-the-loop interrupts for free. More on that in the EngineerOS case study.
4. Build the eval set before the agent is finished
Collect real inputs and the correct outputs, then fix them as a regression suite. Twenty questions is enough to start. EngineerOS runs a 20-question retrieval test in CI that fails the build if recall drops below its floor. That single gate has caught regressions that manual spot-checking missed, because people get tired and CI does not.
5. Add a verification gate the agent cannot talk its way past
This is the rule I learned the hard way. In OnRamp, a 9-step pipeline ingests a shallow clone, builds an AST graph across 20+ languages (Python ast plus tree-sitter), renders a D3 visualization, routes analysis to models, classifies issues by difficulty and assigns them by role, assigns tasks load-aware (fewest active non-terminal tasks, round-robin tie-break), opens one PR per issue, then validates and reviews. Validation re-parses the PR head and diffs the graph against base for broken edges and cycles, with bounded retries and a structured SENIOR_REVIEW.md. The lesson generalizes: a generated PR only counts once the validator re-parses it and diffs the graph, because the agent's own summary is the thing you cannot trust. Verification must read the world's state, not the agent's claims about the world.
6. Deploy behind a human-in-the-loop checkpoint
Ship the agent in propose-then-approve mode first. Log every decision, measure acceptance rates, and only then consider auto-approving the slices where the human never overrode the agent. This is also your onboarding path for the team that will operate it.
Cost and latency control are architecture, not tuning
Agents amplify model costs by making many calls per task, so cost control belongs in the design, not in a spreadsheet after launch. Two levers do most of the work.
The first is routing. Not every step in a pipeline needs a frontier model. OnRamp routes free-tier models first (OpenRouter, Gemini, Groq, NVIDIA) and keeps DeepSeek, Qwen, Zhipu, Moonshot, Mistral, OpenAI, Anthropic, HuggingFace and Ollama behind that wall. The practical rule: classify the difficulty of each sub-task, send the easy 80% to cheap or free models, and reserve expensive models for the steps where quality measurably changes the outcome. Model routing is a cost-control problem before it is a capability problem.
The second is caching. Exact-hash caching catches repeated identical calls; semantic caching at 0.85 similarity catches near-duplicates with different wording. Both are cheap to add and they compound, because agent workloads revisit the same sub-problems constantly. If you do neither, your agent will quietly cost far more to run than it needs to. The exact multiple depends on your workload, so measure your own cache hit rate; what is knowable is that uncached agent loops are the most common silent budget leak in production.
Latency follows the same logic. EngineerOS, a LangGraph multi-agent system with checkpointing and semantic search (HNSW), holds p95 retrieval under 200ms, and the end-to-end experience survives because retrieval is not the bottleneck most teams assume it to be. Measure each span before optimizing it. Streaming partial results to the UI also matters more than raw model speed for perceived latency, since users tolerate a visibly working agent far better than a frozen one.
What an agent is not
Worth saying plainly, because it saves clients money: not every automation wants an agent. If the task is fully deterministic, a workflow with no model in it is cheaper, faster and more reliable. If the corpus fits in the context window, retrieval infrastructure is overkill. If the answer requires aggregating a million rows, that is a database query, not a language task. An agent earns its complexity when the task has unstructured inputs, judgment calls, or tool use that varies per case, and no fixed script covers the variation.
During the intro call I will tell you which of these buckets your problem falls into. Sometimes the honest answer is "buy a script, not an agent", and you will get that answer before you have spent anything.
Where agent projects fail
Four failure modes account for almost every agent project I have been called in to rescue.
No evals, or evals that test nothing real
If you cannot say "on last month's 50 real cases, the agent handled 41 correctly", you do not have an agent, you have a demo. Evals must use real historical inputs, not synthetic ones written by the person who built the prompt. Synthetic evals flatter the system.
Self-reported success
Walkcast made this failure visible. A published lab run had 3 of 4 agent success claims turn out to be false; the harness flagged all three by checking the application's real state instead of the agent's claim. Failed runs become reproducible regression fixtures that gate releases in CI (129 test cases there). Whenever I see an agent whose only source of truth is its own final message, I expect the success rate to be fiction.
Provider lock-in
OnRamp routes free-tier models first (OpenRouter, Gemini, Groq, NVIDIA) and keeps DeepSeek, Qwen, Zhipu, Moonshot, Mistral, OpenAI, Anthropic, HuggingFace and Ollama behind that, with Redis exact plus semantic caching. That routing is a cost-control problem before it is a capability problem. If your agent cannot swap providers, every price change and every outage becomes a re-architecture. Keep the model behind an interface, keep prompts provider-agnostic where possible, and cache aggressively.
Unbounded scope
Scope creep kills agents faster than bad models do. "While you are in there, can it also..." is how a 3-week pilot becomes a 9-month program. The fix is a written scope with an explicit not-included list, and a change-request process that re-prices rather than absorbs.
How to de-risk: the fixed-scope pilot
Every agent project I take on starts with a fixed-scope pilot, and I recommend you demand this from anyone you hire, not just from me.
- Written scope. A one to two page document: task, inputs, outputs, definition of done, explicit exclusions.
- Fixed price, fixed time. Typically 2 to 4 weeks. You know the cost before the first commit.
- Code in your repo and your cloud. You own the artifact from day one. If the engagement ends, you keep everything.
- A gate before scale-up. The pilot ends with an honest review against the eval set. Scale-up is a separate decision, made on evidence, not on enthusiasm.
Estate360 shows what the verification layer looks like in a tenant-facing system: an agentic answer loop with confidence 0.65 and faithfulness 0.8 gates, every query tenant-scoped and enforced by a CI guard. Below the gate, the system says it does not know instead of guessing. That behavior is a feature worth paying for, because the alternative is plausible wrong answers delivered with confidence.
Fixed pricing also aligns incentives. I take the risk on my own estimates, you get a known number, and the 40/60 payment split (40% upfront, 60% on delivery) keeps both sides honest.
A realistic definition of production
"Production" for an agent means all of the following are true: the eval suite runs in CI and passes its floor; the verification gate reads external state, not agent claims; failures degrade to a safe path (human handoff or "I don't know"); you have logs and metrics for latency, cost and acceptance rate; and a named human owns the runbook. If any of these is missing, you are piloting, which is fine, as long as everyone calls it that.
Frequently asked questions before you commission
Do I need a dedicated AI engineer on staff?
For a pilot, no. For a portfolio of agent systems, eventually yes, or a retainer with someone who maintains them. Either way, insist that documentation and code land with you, so the dependency is on knowledge transfer, not on a single vendor.
Which model should the agent use?
Whichever the eval set proves out, behind an interface so you can swap it. I use free-tier-first routing for cost and escalate to paid frontier models only where evals show a real quality delta. Anyone who names one model for every task has not run the evals.
What if the agent is wrong?
The verification gate catches what it can, and the safe fallback catches the rest: human escalation or an honest "I don't know". Estate360 degrades below its confidence 0.65 and faithfulness 0.8 gates rather than guess. Plan for wrongness; it is a design input, not an exception.
What should I prepare before the call?
Bring the workflow as it happens today: the inputs, the people, the current failure rate, and the cost of each failure. Twenty minutes of that conversation tells us both whether an agent is viable, and what the pilot would prove.
How to start
If you are deciding whether to commission an agent, start with a free 15-minute intro call. We will map your workflow, name the narrowest viable slice, and I will send a fixed quote in writing within a day of the call. No retainer is required to start, and there is no obligation to proceed. Pricing starts at ₹25,000 for fixed-scope work; details are on the pricing page. Reach out via the contact page or kunjkshah05@gmail.com, and we will tell you honestly whether an agent is even the right tool for your problem. Sometimes it is not, and I would rather say that on the call than after you have paid.