“Agent” has become a marketing word for anything with a text box. The useful distinction is simpler: a chatbot answers, a RAG assistant answers from your documents, and an agent takes actions to finish a task. Each has a different cost and a different failure mode. Choose based on the job, not the label.
Three things people call AI
| Type | What it does | Typical job | Main risk |
|---|---|---|---|
| Chatbot | Responds to a message, often from a script or a general model. | FAQs, first-line support, lead capture. | Generic or wrong answers with no source. |
| RAG assistant | Retrieves passages from your documents and answers with citations. | Policy Q&A, proposal drafting, support from a knowledge base. | Bad retrieval or stale documents. |
| Agent | Plans steps and uses tools — search, create, update, notify — to complete a task. | Resolving a ticket end to end, preparing a quote, reconciling records. | Unintended writes, loops, cost spikes. |
When an agent earns its keep
- The task has a known sequence of steps across two or more systems.
- Each step has a clear success condition the system can check.
- The tools can be limited to the minimum permissions needed.
- There is a natural approval point before anything irreversible happens.
- The volume is high enough that the saved minutes matter every week.
When a chatbot is enough
- People need an answer, not an action.
- The knowledge fits in a bounded set of documents you can keep current.
- A wrong answer is annoying but not expensive.
- You want to learn which questions people actually ask before automating the response.
- The budget is a prototype, not a platform.
The failure modes to design out
- Over-permissioned tools. An agent that can delete records because deleting was easier than scoping a write action.
- Loops. A step fails, the agent retries forever, and the bill grows. Step limits and dead-letter handling are not optional.
- Silent writes. Changes happen without a record of who approved them. Every action needs an audit trail.
- Prompt-only guardrails. “Do not do X” in a prompt is a suggestion. A permission boundary is a control.
- No evaluation set. If you cannot replay twenty real tasks and check the outcomes, you cannot tell whether the agent improved.
A sensible build order
- Ship a read-only RAG assistant over the documents the agent will need.
- Measure the questions and the gaps. Most “agent” ideas shrink at this stage.
- Add one tool with read access and log every call.
- Add a single write action behind a human approval screen.
- Only then allow multi-step autonomy, with step limits and a kill switch.
- Review the logs weekly and remove tools the agent does not need.
The permission questions that decide the design
Most agent projects are really permission projects. Before choosing a framework, answer these in writing:
- Which system holds the source of truth for each field the agent reads?
- What is the smallest write the agent needs — create a draft, or update a live record?
- Who approves that write, and in which interface do they see the evidence?
- What happens after a timeout or a partial failure: retry, roll back or escalate?
- What is the per-task cost ceiling, and what stops the agent when it is reached?
- How do we remove a tool or revoke a credential without redeploying the product?
What it costs
The read-only stages follow our normal AI bands: a prototype from USD 3,000 and a production assistant around USD 8,000–25,000. Agent work is scoped individually once the tools, permissions and approval points are known. Be sceptical of a fixed agent price quoted before anyone has listed the systems it will touch.
We build both read-only assistants and tool-using agents; the AI development page covers the approach, and the AI RFP case study shows a drafting workflow with a human in the approval seat.
Mayur Saptal
CEO at Oysty India. Writes about AI delivery, scoping and the unglamorous part of shipping software. You can check the public client reviews on Upwork.