AI agent development for agents that reach production

Workflow or agent? A decision table

Answer these honestly for the task you have in mind. Mostly left-hand answers mean a workflow. A mix usually means a workflow with one agentic step, which is the most common design we ship.

Why so many agent projects get cancelled

On 25 June 2025 Gartner predicted that over 40% of agentic AI projects will be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls. It also warned about “agent washing”, estimating that only about 130 of the thousands of vendors claiming agentic AI actually offer it. In our experience the causes are predictable: no clearly defined task, no eval set, no cost model and far too many permissions. Each has a fix you can put in place before the first line of agent code.

Estimating cost per task

We never quote model prices on this page because they change every few months. Use your provider’s current price list in this formula:

cost per task ≈ Σ over steps (input tokens × input price + output tokens × output price) + tool and infrastructure costs

For a first estimate, steps × average tokens per step × price is close enough. Four things make the real figure higher than the estimate:

• Context grows with each step. Most agents resend the conversation and tool results on every call, so later steps cost more than early ones. Prompt caching cuts the repeated part.
• Retries and dead ends. Failed tool calls, abandoned runs and loops all bill.
• The long tail. Measure the 95th percentile on your eval set, not just the median. A few runaway tasks can double the bill.
• People. Review time for approvals is a cost too.

Monthly cost is then tasks per month × cost per task + hosting + review hours × hourly cost. Routing simple steps to a smaller model, trimming tool output before it goes back into context, and hard caps on steps and spend per task are the usual levers.

What drives the cost of building one

Running cost is only half of it. The build is usually dominated by the parts around the model, not the model itself:

• Integrations. Each system the agent touches needs a scoped, tested tool. Old APIs, missing sandboxes and slow partner approvals add more time than prompt work.
• Permission and approval design. Approval screens, audit logs and role checks are ordinary software, and they are what makes an agent safe to switch on.
• The eval set. Collecting and labelling real cases takes effort from your team as well as ours. Skimping here is the most expensive saving you can make.
• Channels. Voice adds telephony and latency work; WhatsApp adds templates and consent rules.
• Compliance. Health, finance and children’s data bring BAAs, data-processing agreements, retention rules and reviews.

A narrow agent with two or three read-mostly tools is a small project. One that writes into several systems of record, in a regulated sector, is a much larger one, whoever builds it.

Evals and tracing

An agent without evals is a demo. We build an eval set from real cases: typical ones, awkward ones and the ones that went wrong. Each case has an expected outcome, checked three ways:

• Code checks: did it call the right tool, with valid arguments, in a sensible order?
• Outcome checks: is the booking actually in the database, with the right patient and time?
• Rubric checks: a model grades tone and completeness against written criteria, spot-checked by a person.

The suite runs on every change to prompts, models or tools, so a model upgrade becomes a measured decision instead of a hopeful one. Tracing records every step in production (input, output, tool call, latency and tokens) through OpenTelemetry or a tool such as Langfuse, with personal data redacted. When a customer complains, you can replay exactly what the agent saw and did.

Least-privilege tools and MCP

Most agent incidents are permission problems. Our rules:

• Separate read tools from write tools, and start with read-only.
• Scope every tool to the current user or tenant on the server side. Never trust an ID the model supplies.
• No raw SQL, shell or “call any URL” tools in production agents.
• Validate arguments in the tool, not in the prompt, and rate-limit each tool.
• Treat tool output as untrusted. An email or web page can contain instructions aimed at your agent, so content from outside never grants new permissions.
• Keep credentials server-side. Our MCP server development work exposes your systems through scoped, logged MCP servers that several agents can share.

Human-in-the-loop design

Decide, per action, how much the agent may do on its own:

Approval screens show what the agent wants to do and why, in one view. Escalations carry a summary so staff do not start from scratch, and every pending approval has a timeout and a fallback.

Common mistakes

• Starting with a multi-agent architecture before one agent works.
• Judging quality from demos instead of an eval set.
• Giving the agent an admin API key “for now”.
• Putting business rules and arithmetic in the prompt instead of in code.
• No step or spend caps, so one confused task runs for an hour.
• No plan for model deprecations, which force re-testing whether you want it or not.

How to choose an AI agent development partner

• Will they tell you when a workflow or a RAG app is enough?
• Can they show traces and eval results from an agent they run in production?
• Do they estimate cost per task before building, and measure it after?
• Can they show you the tool list and the permission model, in writing?
• Do you own the code, prompts, eval sets and traces?
• How do they handle model changes and provider outages?
• Will they sign the data-processing terms (and, for US health data, a BAA) your use case needs?

The same questions apply whether you are comparing an AI agent development company in India with one in the US or Europe. Working-hours overlap, data-residency terms and who will actually write the code matter more than the address on the proposal.

If you would rather hire AI agent developers into your own team, our staff augmentation service places senior engineers who work in your repositories and processes.