Concept · RAG & Agents
AI agents explained: from answering to acting
What makes an AI agent different from a chatbot, how agents are built, and how to keep them safe and useful.
Intermediate7 min read

Key takeaways
- An agent plans and carries out multi-step tasks using tools. A chatbot only replies.
- Autonomy is a dial, not a switch: start with suggestions, then approvals, then limited actions.
- Least privilege, step limits, approval points and logs are what make agents safe to run.
- If the steps are always the same, plain automation is usually better than an agent.
A chatbot answers a question and waits for the next one. An AI agent is given a goal and works towards it. It decides which steps to take, uses tools such as search, databases or email to take them, checks what happened, and carries on until the job is done or it needs help. That shift from answering to acting is what makes agents both powerful and risky.
This article explains how agents work, where they help, and the safeguards that keep them useful. It assumes no background in AI.
Chatbot or agent?
Ask a chatbot, “What is the status of order 4821?” and it can only repeat what it knows, which is nothing about your order. Give an agent the same question and access to the order system, and it can look the order up, notice the parcel is delayed, check the refund rules, draft an apology and offer the customer a choice. The difference is access to tools and the freedom to chain several steps together.
The parts of an agent
- A language model that reasons about the goal and decides the next step.
- Tools it is allowed to call, each with clear inputs and limits: search, a database query, a calculator, a ticketing system, a calendar.
- Memory and context: the current task state, the steps so far and any relevant documents.
- A loop that repeats: think, act, observe the result, think again, until a stopping condition is met.
- Guardrails: permissions, spending and time limits, and points where a human must approve.
How one run looks
Consider an agent that triages incoming support emails.
- 01It reads a new email and works out what the customer wants.
- 02It looks up the customer’s account and recent orders with a lookup tool.
- 03It searches the knowledge base for the relevant policy.
- 04It drafts a reply, and decides whether it is confident enough to send.
- 05If the case is simple, it queues the reply for approval. If it involves a complaint or a large refund, it hands the case to a person with a short summary.
Notice that the last step is not a failure. Knowing when to stop and ask for help is a core part of a well-built agent.
Levels of autonomy
It helps to think of autonomy as a dial. Most organisations should turn it up slowly.
- Level 1, suggest: the agent proposes actions and a person does them.
- Level 2, act with approval: the agent prepares the action, and a person approves each one.
- Level 3, act within limits: the agent acts alone on low-risk, reversible tasks, and escalates anything outside its limits.
- Level 4, broad autonomy: the agent runs long tasks on its own. This level is rare and demands strong monitoring.
What can go wrong
- Wrong actions. A mistaken reading of the goal can lead to a wrong email, a deleted record or a bad purchase.
- Prompt injection. Text in an email or web page can try to hijack the agent’s instructions, for example by telling it to forward private data.
- Runaway loops. An agent that keeps retrying can burn time and money.
- Data exposure. An agent with broad access might reveal information to someone who should not see it.
- Overconfidence. Agents can sound sure of themselves when they are wrong.
Design principles that keep agents safe
- Least privilege. Give each agent only the tools and data the task needs, and make most tools read-only.
- Approvals for anything irreversible, such as sending money, deleting data or contacting customers.
- Hard limits on steps, time and spend, so a loop ends by itself.
- Treat all outside text as untrusted. Instructions found in a document or email must never override your own rules.
- Log every step: what the agent saw, decided and did. Logs make errors traceable and improvement possible.
- Test before trusting. Run the agent on past cases with known outcomes and measure how often it gets them right.
Agent or plain automation?
If the steps never change, a regular workflow or script is cheaper, faster and easier to test than an agent. Reach for an agent when the path varies: when the input is messy text, when the next step depends on what was found, or when many possible tools could apply. Many of the best systems combine both, with fixed workflow steps for the predictable parts and an agent for the judgement calls.
Good first use cases
- Triage and routing of incoming requests, with a human sending the reply.
- Drafting reports by pulling figures from several systems.
- Checking records against a set of rules and flagging exceptions.
- Research assistants that gather and summarise sources, with links to each one.
How to measure an agent
- Task success rate on a fixed set of test cases.
- How often it escalates, and whether it escalates the right cases.
- Time saved per task, compared with doing it by hand.
- Errors that reached a customer, which should trend towards zero.
- Cost per completed task.
A worked design: an expense-report checker
Imagine an agent that helps a finance team review expense claims. Here is how a careful design might look.
- Goal: check each claim against the policy and prepare a recommendation, so a person can approve in seconds.
- Tools: read the claim, read the receipt image through text recognition, search the policy, look up the employee’s earlier claims. All are read-only.
- Limits: the agent cannot approve, pay or edit anything. It writes a recommendation and a list of issues.
- Escalation: claims above a set amount, or with a missing receipt, go straight to a person with a short explanation.
- Logging: every claim, every tool call and every recommendation is stored, so that a manager can see exactly what happened.
- Evaluation: before launch, the agent runs on 200 past claims whose outcomes are known, and its recommendations are compared with what people decided.
This agent saves time without being given authority. If it proves reliable over months, the organisation can decide whether to let it approve small, clean claims alone.
Do you need an agent framework?
Many tutorials start with a framework, and communities often argue about which is best. Practitioners who run agents for real customers tend to report that the choice matters less than the basics: good error handling, saved state so a task can resume, clear logs and honest evaluation. Frameworks can help you see what the agent is doing. They cannot supply reliability for you.
A good rule is to start with the simplest approach that works, understand every step it takes, and adopt a framework when its features solve a problem you actually have.
Frequently asked questions
- Are AI agents just hype?
- Some claims are. But agents that do narrow tasks with clear tools, limits and human review already deliver real value. The risk is in giving broad autonomy before the evidence supports it.
- How is an agent different from automation tools like Zapier?
- Automation runs a fixed sequence that you design. An agent chooses its own steps, which suits messy inputs but is less predictable. Many systems combine fixed workflows with an agent for the judgement calls.
- What is prompt injection?
- It is an attack in which text that the agent reads, such as an email or web page, contains instructions that try to override the agent’s own. Defend against it by treating outside text as data, limiting tools and requiring approvals.
- Which tasks should an agent never do alone?
- Anything irreversible or high stakes, such as moving money, deleting records, sending messages to customers or making legal or medical decisions.
Agents are a real step forward, but their value comes from careful boundaries as much as from clever models. Start small, keep a person in the loop for anything that matters, and widen the agent’s freedom only as the evidence earns it.
Join the conversation
Reactions & comments
Comments are opening soon.
In the meantime, tell us what you think by email at info.istem.lab@gmail.com.



