Agentic AI Development Services in India

The Problem You Are Actually Trying to Solve

The requests we receive rarely arrive as "build me an agent". They arrive as a description of humans doing structured work that nobody enjoys.

Two analysts spend most of their week opening tabs. One reads a support ticket, checks the order in the admin panel, checks the shipment status in a carrier portal, checks whether the customer is on the plan that includes priority handling, then writes four sentences. Another matches supplier invoices against purchase orders and chases the twelve percent that do not reconcile. A third reviews vendor security questionnaires by finding the answer somewhere in a policy library that has grown to nine hundred pages. None of that work is hard. All of it is sequential, context-heavy and slow, and it does not scale by hiring because the training curve is months long.

What it costs you is usually not the salary. It is the queue. Tickets sit for nineteen hours because the person who understands billing is asleep. Month-end closes three days late because reconciliation is serial. A deal slips because the security questionnaire took eleven days to come back. Those are the numbers worth putting in the business case, and they are the numbers we ask for in discovery, because they decide whether the project is worth doing and what "good" looks like when it ships.

There is a second problem underneath, and it is the one that kills most internal agent projects. Somebody built a convincing prototype in a fortnight. It worked in the demo. Then it met the real ticket queue, where twenty percent of inputs are ambiguous, three of the eight tools it needs are undocumented internal endpoints, and one of them returns HTTP 200 with an error message in the body. The prototype had no evaluation set, so nobody can say whether the fix made it better. That is the state we are most often called into, and the first month is usually spent building the measurement that should have existed first.

Which Agent Framework Should You Use?

There is no correct answer, only a correct answer for your control requirements, your team's language, and how much of the machinery you want to own. Here is where we land on each, including where each one is the wrong choice. If you want the longer comparison, weigh the trade-offs against your own control requirements before committing to a framework.

LangGraph

A graph over explicit state, from the LangChain team. You define nodes and edges, the state object is yours, and the runtime handles persistence and resumption. The features that earn it a place in production work are checkpointing, interrupts for human approval, and the ability to replay a run from a saved state to reproduce a bug.

Choose it when the process has a shape you can draw, when steps need approval, and when you need a run to survive a deploy. It is the framework we reach for most often on regulated or money-touching workflows for exactly that reason. Where it is wrong: an exploratory prototype where the shape is unknown, because you will spend your time refactoring the graph. It also carries the LangChain ecosystem's abstraction weight, and a team new to it will spend the first fortnight reading source code to find out what a wrapper actually does.

OpenAI Agents SDK

A deliberately small set of primitives: agents, handoffs between agents, input and output guardrails, sessions, and tracing that works out of the box. It is a pleasant place to start because it does not ask you to adopt a worldview, and the tracing means you can see the run from the first day rather than the first month.

Reach for it when you are on OpenAI models, want handoff patterns without building them, and value getting to a traced, evaluable agent quickly. It is the wrong tool for heavy multi-provider routing, or a workflow that needs durable, days-long execution with approvals. It is also the option most likely to make you an unwilling participant in one vendor's roadmap, which matters if your procurement team asks about model portability.

Claude Agent SDK

Anthropic's agent harness, built out of the machinery behind Claude Code. Its distinctive pieces are subagents with separate context, hooks that let you intercept the loop deterministically, permission modes for tool use, and automatic context compaction on long runs. Tools arrive through the Model Context Protocol, which means a tool server you write once can be used by other MCP-aware clients.

Choose it for long-running work over a filesystem or codebase, for anything where you want a deterministic hook in place of a polite instruction, and where context compaction on multi-hour runs is a real requirement and not a hypothetical one. It is the wrong shape for short, high-volume, latency-critical calls, where the harness is more machinery than the job needs.

CrewAI

Role-based multi-agent orchestration. You define agents with roles, goals and backstories, give them tasks, and run them in a sequential or hierarchical process. It gets a non-trivial multi-agent demo working faster than anything else on this list.

It earns a place in prototypes, internal tooling, and cases where the role metaphor genuinely matches the work. It struggles in production systems that need fine-grained control over what enters the context window, precise cost accounting per step, or resumption after failure. The abstraction that makes it fast to start also puts distance between you and the actual model calls, and that distance is expensive when you are debugging a cost spike.

Microsoft AutoGen

An event-driven runtime with a conversational multi-agent layer on top. Group chat and reflection patterns are first-class, and the asynchronous message-passing core is genuinely well designed for agents that run concurrently rather than in a line.

Use it when you have a real multi-agent problem with concurrency, when you are already inside the Microsoft and Azure ecosystem, or when you want to experiment with agent-to-agent protocols. It is overkill on a single-agent workflow, where the conversational framing adds turns, tokens and unpredictability that buy you nothing.

No framework

A loop, a tool registry, your own state object, and direct calls to the provider API. This is a legitimate production choice and we ship it regularly. You own about three hundred lines of orchestration code that you fully understand, you upgrade on your schedule, and nothing sits between you and the request payload when you are chasing a cost problem.

Choose it when the agent has fewer than about six tools, when the control flow is simple, and when your team would rather maintain their own code than someone else's abstraction. Where it is wrong: when you need durable execution, resumable approvals or distributed multi-agent coordination, at which point you are about to rebuild a framework badly.

The pieces that sit underneath, whichever you pick

The Model Context Protocol has become the practical standard for exposing tools and resources to agents, and writing your integration as an MCP server instead of framework-specific code is the cheapest insurance against changing your mind about the framework later. For workflows that run for hours or days with human approvals in the middle, a durable execution engine such as Temporal underneath the agent solves retries, timers and crash recovery far better than any agent library will. On the evaluation and tracing side, LangSmith, Langfuse, Arize Phoenix and Braintrust all do the job; we care more that OpenTelemetry's GenAI semantic conventions are emitted so your traces are portable than which vendor's dashboard you end up on.

One more piece of advice from having done this: pick your model provider strategy before your framework, not after. Whether you need a second provider for redundancy or for data-residency reasons changes which frameworks are viable, and finding that out in month three is an expensive way to learn it.

Evaluation, Guardrails and Human-in-the-Loop

Evaluation: the artifact that lets you change things

Without evals you cannot upgrade a model, edit a prompt, add a tool or change a retrieval parameter with any confidence, so in practice you stop touching the system and it decays. Building the eval set is the least exciting week of the project and the one that determines everything after it.

We build from your real cases, including the ones that went wrong, and we grade on outcome. Did the agent reach the right decision? Did it call the right tools with the right arguments, in an order that made sense? Did it correctly decline the cases it should not have handled? Text similarity to a golden answer is a poor scorer for agents, because two correct runs can read completely differently.

Practical shape: a small deterministic set of assertions for the things that must never vary, such as never emailing a customer without approval, plus an LLM-as-judge layer with a written rubric for the qualitative calls, plus a held-out set nobody optimises against. We calibrate the judge against human labels before trusting it, because an uncalibrated judge is a confident random number generator. The suite runs on every pull request and every model version change, and a regression blocks the merge.

Guardrails, and their honest limits

Guardrails work in layers. Input filters catch obvious injection and off-topic use. Output validation checks structure, checks claims against the retrieved sources where that is possible, and refuses to pass through anything malformed. Tool-level permissions are the layer that actually matters, because a model that cannot call the refund endpoint cannot be talked into a refund regardless of what the prompt says.

NeMo Guardrails and Guardrails AI both do useful work at the input and output edges, and Llama Guard is a reasonable classifier for content policy. None of them are a security boundary. The security boundary is your permission model, your least-privilege credentials, and your approval gates. Anyone selling you a guardrail library as the answer to prompt injection is selling you a false sense of safety, and the OWASP Top 10 for LLM Applications is worth reading precisely because it frames these as containment problems rather than filtering problems.

Human-in-the-loop, designed rather than bolted on

The interesting question is not whether to have a human in the loop but where, and how the review interface is built. Approval on every action produces alert fatigue in a fortnight and a reviewer who clicks approve without reading. We place approvals by consequence: irreversible actions, anything touching money, anything that leaves your organisation, and anything the agent's own confidence signal flags as uncertain.

The review surface matters as much as the placement. A reviewer needs the agent's proposed action, its reasoning, the evidence it used with links to the source records, and one-click approve, edit or reject. Every rejection and every edit is captured as an eval case, which is how the agent gets better at the things it currently gets wrong. Over time the low-risk paths graduate to full autonomy on the evidence of that data, and the graduation is a decision you make from a dashboard rather than a promise we make in a proposal.

Failure Modes We Design Against

Four Situations Where an Agent Earned Its Place

These are the shapes of problem we are most often asked to solve, written as scenarios, not as claimed client work. Each one includes the part that goes wrong, because that is the part worth knowing before you start.

Support triage across systems that do not talk to each other

A B2B software company gets a few hundred tickets a week. Answering most of them requires four lookups: the account record, the subscription plan, the recent deployment log, and a knowledge base article. Humans do it well and slowly, and the queue backs up overnight because the people who understand billing are in one timezone.

An agent handles the lookups, drafts a reply, and either sends it on the low-risk categories or attaches it to the ticket for a human. What goes wrong first is confident answers from stale knowledge: the agent quotes a refund policy from a document last edited nineteen months ago. A better prompt will not save you here. What does is a policy tool that returns the authoritative current answer directly, a freshness check on retrieved documents, and a rule that anything touching money or cancellation routes to a human regardless of confidence. The second thing that goes wrong is the agent answering questions it should have escalated, which is why "correctly declined" is one of the metrics in the eval suite from the start.

Invoice and purchase order reconciliation

A distribution business receives supplier invoices in mixed formats. Most match a purchase order cleanly. Around one in eight does not, and a finance clerk resolves each exception by pulling the PO, the goods-received note, and sometimes an email thread about a partial delivery.

This is a genuine agent case, because which document you need next depends on what the previous one said. The failure we see is a loop: a partial quantity match leaves the agent uncertain, so it fetches the PO again, then the note again, then tries a slightly different search. The fix is structural, not prompt-level. A turn budget, a state machine that forces a decision after a fixed number of evidence-gathering calls, and an explicit "insufficient evidence" terminal state that creates a task for the clerk with everything the agent found already attached. That last part is what makes it useful even when it fails, because the clerk starts from assembled evidence rather than from an empty screen.

Responding to a failing build

An infrastructure team wants an agent that reads a failed CI job, pulls the logs, checks recent commits, reproduces where it can, and proposes a fix. Attractive, and the one where excessive agency does the most damage.

Two things go wrong. The first is permissions: someone gives the agent a token with write access to the default branch because it was easier during development. Give it a token that can only open pull requests, and require human review, so the worst case is a bad PR rather than a bad deploy. The second is cost, and it is the one people do not anticipate. A flaky test fires the agent four hundred times in a day, each run burning through a large log file. Put a dedupe key on the trigger so an identical failure signature runs once, a daily budget with a defined degradation to posting a diagnosis without attempting a fix, and a rule that the agent never runs on a job that has already failed the same way in the last hour.

Account research that reads the open web

A sales team wants an agent that researches a prospect before a call: recent funding, hiring signals, tech stack, any published incident. The value is obvious. So is the attack surface, because the agent is reading content that anybody can write.

A page that includes text instructing the model to summarise its own system prompt, or to call a tool with attacker-chosen arguments, is a real risk once the agent has any tool at all. The architecture we use splits the roles. A fetching step retrieves content with no dangerous tools available to it. A summarising step reads that content wrapped in explicit untrusted-data markers, with tool access removed entirely for that turn. Only structured, validated output crosses back into the step that can act. The second issue is quieter and just as damaging: confident summaries of the wrong company, because two businesses share a name. Every claim in the brief carries a source URL, and a claim without a source is dropped instead of shown, which reviewers trust far more than a polished paragraph with no provenance.

What Could Go Wrong With an Offshore Agent Team?

Losing control of quality

The fear is reasonable and the answer is process rather than promises. Engineers on agent work are assessed on a practical exercise built from a real problem, not a puzzle: given a flaky tool and a failing run, find the cause. English is assessed in the same session, in the way the work actually uses it, which is written explanation of a technical decision rather than conversational fluency.

After that, quality is visible rather than asserted. You have repository access from the first commit, you see every pull request, you read the traces, and the eval scores are on a dashboard you can open without asking. If the numbers are moving the wrong way you will know before we tell you, which is the point.

Who owns the code, the prompts and the data

You do, from the start. The master services agreement carries a present assignment of IP, and it names prompts, eval sets, trace data and infrastructure definitions explicitly, because a generic software IP clause written before 2023 does not clearly cover them and that ambiguity is worth closing. Everything lives in your GitHub organisation and your cloud accounts. NDAs cover the company and every individual engineer.

On data protection: we work as a processor under UK and EU GDPR with a data processing agreement and standard contractual clauses where transfer requires them, and India's Digital Personal Data Protection Act 2023 applies on our side. Where your data cannot leave a jurisdiction, we build for that, which usually means model endpoints in your region and self-hosted tracing. Say it in the first call rather than the fourth, because it changes the architecture and it is expensive to retrofit.

Security and access

Least privilege, applied to both people and agents. Engineers get access to the systems their tasks need, through your identity provider with multi-factor authentication, and access is reviewed when someone joins or leaves the team. Company-managed devices with disk encryption and screen lock. No production data in development environments without approval and masking. Where you have SOC 2 or HIPAA obligations, we work inside your control set and produce the evidence your auditor needs; we do not claim your certification as ours.

The agent-specific part deserves separate attention. Agents get their own service accounts with narrow, tool-level scopes, credentials live in your secret manager and are rotated on your schedule, and there is a written permission matrix listing every tool, what it can reach, and whether it needs approval. That document is reviewed at handover and it is the first thing an auditor asks for.

Attrition, replacement and the bus factor

The Indian technology market is competitive and people move. Anyone telling you their attrition is zero is either very new or not counting carefully. What we control is the blast radius. Notice, handover and exit terms are written into the agreement before work starts rather than settled in a hurry later. No single engineer is the only person who understands a component; the second reviewer on every pull request is doing double duty as a knowledge backstop. Decision records, runbooks and the eval suite mean the system is documented by construction rather than by someone's memory.

If a replacement is needed, tell us and we will deal with it; how the overlap and the ramp-up are treated is one of the things your agreement should say, so it is worth settling before you sign. Where the calendar allows, the replacement pairs with the outgoing engineer while both are still on the team.

If it does not work out

Written into the agreement, not negotiated in a bad month. Notice and handover terms are agreed with you before the engagement starts. Everything is already in your accounts, so there is nothing to hand back. Exit includes a knowledge transfer period with recorded working sessions, an updated runbook, and a documented list of known issues and deferred decisions, because the honest version of that list is worth more to your next team than a clean-looking one.

The costs that do not appear in a proposal

Three, and they are real. Ramp-up: a new engineer on your codebase is not fully productive for two to four weeks, and on an agent project with unfamiliar internal tools it is at the longer end. Your own management overhead: an offshore team needs written specifications and someone on your side who can answer questions with authority, and if that person does not exist the project stalls no matter who you hire. And the operating cost of the agent itself, which is not a build cost at all but an ongoing model bill that scales with volume, and which we model with you during discovery rather than after launch.

Where This Fits With Our Other Work

If your problem turns out to need one well-designed model call rather than a loop, LLM integration is the cheaper and faster route, and we would rather point you there than sell you an architecture. Where the agent depends on retrieval over your own documents or a warehouse, the quality ceiling is set by the pipeline underneath it, which is data engineering work. Where the tools the agent needs are locked inside an ERP, a CRM or a system with no usable API, that is enterprise integration, and it is usually the longest pole in the build.

On the staffing side, most agent work in this ecosystem is Python, so teams are commonly built around Python developers in India with orchestration and evaluation experience. And if you are still choosing between orchestration libraries, the right choice usually comes down to your team's language and how much of the machinery you want to own.