How is an agent different from a chatbot or an automation?
A chatbot produces text. You read the text and decide what to do. Nothing changes in any system unless a person acts on it.
A traditional automation executes a fixed sequence. It is reliable precisely because it cannot deviate, and it fails the moment reality does not match the sequence — an invoice in an unexpected format, an email that is a question rather than a request.
An agent sits between the two: it has tools it can call, and it chooses which to call in what order based on what it finds. That flexibility is the entire value and the entire risk. An automation that goes wrong does the wrong thing once, predictably. An agent that goes wrong can do several wrong things creatively.
What do agents actually get used for?
The deployments that work share a shape: high volume, moderate complexity, and a cheap way to check the result. The ones that fail are usually low volume and high stakes, where the judgment being automated is the actual job.
| Task | Fit | Why |
|---|---|---|
| Reading incoming documents into structured records | Strong | High volume, verifiable output, an obvious human check on low-confidence extractions |
| First-line support triage and routing | Strong | Volume is high, misrouting is cheap to correct, and the escalation path already exists |
| Reconciling data across two systems | Strong | Tedious, rule-heavy but exception-rich — the exact gap between an automation and a person |
| Drafting quotes or responses for human approval | Good | The human approval step is the safety mechanism, and it is already in the workflow |
| Autonomous outbound communication | Weak | An error reaches a customer before anyone sees it, and cannot be recalled |
| Final approval of payments or credit decisions | Poor | Consequential, regulated, and requires accountability an agent cannot hold |
What does an agent need to be safe to deploy?
The engineering that makes an agent useful in production is almost entirely about constraint, not capability. The model is the part you do not build.
- A bounded tool set. The agent can only do what it has been given tools for, so the tool list is the real permission model — and it should be the smallest list that does the job.
- Its own identity and permissions. An agent acting as a shared admin account is indistinguishable from an incident.
- A human gate on anything irreversible. Sending money, sending mail to a customer, deleting records, changing prices — draft, then approve.
- Full audit logging. Every tool call, its inputs, and its result, retained. Without this you cannot answer 'why did it do that?', and that question will be asked.
- Confidence thresholds that route uncertainty to a person instead of guessing. An agent that says 'I don't know' is doing its job.
- A tested failure mode. What happens when the API is down, the document is unreadable, or the request is genuinely ambiguous — decided in advance rather than improvised at runtime.
What does a realistic first agent project look like?
Pick one workflow, high-volume, where a wrong answer is inconvenient rather than expensive, and where a person is already checking the output today. Document processing and support triage are the two most common starting points for exactly this reason.
Run it in shadow mode first: the agent processes everything and proposes, a person does the real work, and you compare. This gives an honest accuracy number before anything is at stake, and it usually reveals that the requirement was described slightly wrong — which is much cheaper to learn in shadow mode.
Then move to human-approved output, then to autonomous handling of only the high-confidence cases, with everything else escalating. Most production agents stop at that third stage permanently, and that is not a failure — it is what a well-scoped agent looks like.
What does it cost to run?
The model API cost is usually the smallest line and the one everyone estimates first. Per-task inference costs are typically fractions of a rupee to a few rupees, depending on how much context each task needs.
The real costs are the integration work to give the agent its tools, the evaluation harness that tells you whether a change made it better or worse, and the ongoing human review capacity. Budget for the evaluation harness specifically — without it, every prompt or model change is a guess, and you will make many of both.
The saving to measure is not headcount. It is hours returned on a specific named task, measured before and after. A project that cannot state that number was not scoped well enough to succeed.
Sources
- Building effective agents — patterns, and when not to use them — Anthropic
- Model Context Protocol — an open standard for connecting models to tools and data — Model Context Protocol
- AI Risk Management Framework — NIST