A year ago most “AI agent” projects were chatbots with a new label. That has changed. Today's models can reliably call tools, read the result, and decide what to do next across several steps. Connected to your ERP, CRM, inbox and document store, they can finish real work rather than just answer questions about it.
But agents are not magic employees. They are software that makes probabilistic decisions, and they succeed or fail based on how carefully the job is scoped. This is what we have learned building them for Indian businesses this year.
What an AI agent actually is
An agent is a language model running in a loop. It gets a goal, a set of tools (search the CRM, read an invoice, create a ticket, send a draft for approval) and instructions. It picks a tool, looks at the result, and repeats until the goal is met or it hands off to a person.
Standards such as the Model Context Protocol (MCP) have made the “tools” part far easier. Instead of writing custom glue for every model, you expose a system once as an MCP server and any compatible agent can use it, with permissions you control.
Agent, chatbot or plain automation?
Not every problem needs an agent. Many “AI” requests are better served by a simple workflow or a well-built chatbot, which are cheaper to run and easier to test. We use this rule of thumb:
| Approach | Best when | Example |
|---|---|---|
| Rule-based automation | Every step is predictable and the inputs are structured | Copy paid orders from the website into the ERP |
| Chatbot / assistant | People need answers, but a person still takes the action | Answer staff questions about leave policy |
| AI agent | Inputs are messy and the next step depends on what it finds | Read a supplier email, find the PO, check prices and draft the bill |
The best systems mix all three. Fixed workflows handle the predictable steps, and the agent is called only where judgement on unstructured information is needed. That keeps costs low and behaviour predictable.
Where agents deliver today
- Order and invoice intake: reading purchase orders or supplier invoices from email, matching them against masters, and posting drafts into the ERP for approval.
- Customer support triage: classifying tickets, pulling order history, drafting a reply and routing the hard ones to the right person.
- Sales operations: enriching leads, logging call notes into the CRM, and preparing follow-up drafts from meeting transcripts.
- IT and HR helpdesks: password resets, access requests and policy questions answered from your own documents.
- Reporting: assembling weekly MIS from several systems and flagging the numbers that moved.
Where agents still struggle
Agents are weak where the “right answer” lives in someone's head, where one mistake is expensive and hard to undo, or where the process changes every week. Negotiation, credit decisions and anything touching payments should stay human-led, with the agent preparing the work rather than finishing it.
An eight-week pilot that proves value
- Week 1–2: pick one task, document it including the exceptions, and baseline the time and error rate today.
- Week 3–4: build the agent with read-only tools and run it in “shadow mode” beside the team.
- Week 5–6: review every run, tighten instructions and add the validation rules the agent kept missing.
- Week 7–8: switch on write access behind an approval step and measure the same metrics as week one.
| Metric | What to track | Healthy target |
|---|---|---|
| Straight-through rate | Runs completed with no human edit | 60–80% after tuning |
| Exception rate | Runs handed to a person | Falling week on week |
| Time per item | Minutes from arrival to done | 50%+ lower than baseline |
| Cost per run | Model + infrastructure cost | Well below the labour it replaces |
Guardrails we always put in place
- Least-privilege tools: an agent that drafts invoices does not get the delete endpoint.
- Full logs of every step, tool call and output, kept for audit.
- Hard limits on spend, retries and the number of actions per run.
- Personal data handled in line with the DPDP Act: minimise what the model sees and where it is processed.
What an agent pilot costs
Running costs are usually smaller than people expect. A typical back-office task uses a few thousand tokens per run, so even thousands of runs a month cost far less than the staff time they replace. The larger cost is the engineering: connecting systems safely, writing validation rules and building the review screen that people use every day.
- Integration work: APIs or MCP servers for each system the agent touches.
- Validation: the business rules that catch a wrong answer before it reaches a customer or a ledger.
- Review interface: a simple queue where staff approve, edit or reject the agent's work.
- Monitoring: dashboards for volume, exceptions and cost, so drift is noticed early.
Choosing the model
For most business tasks the choice of model matters less than the design around it. We usually start with a leading hosted model to prove the workflow, then test smaller or cheaper models on the same evaluation set. If a smaller model scores the same on your real cases, use it. Keep the model behind an interface so you can switch later without rebuilding.
The best agent projects start boring: one task, one team, one number to move. Ambition comes after the logs prove the agent is reliable.
If you have a process that eats hours every week and follows rules most of the time, it is probably a good first candidate. Start there, measure honestly, and grow from evidence.
