What an AI agent is — what changes when you hand a model tools
An AI agent is software built so that a language model does not stop at producing text but carries out a goal on behalf of the user — deciding which tool to call, reading what comes back, and choosing what to do next. The line against a workflow is autonomy: a workflow follows a sequence a person wrote in advance, while an agent decides its next step during execution. It is typically assembled from perception, reasoning, memory and action, with tools reached through function calling. Its failures show up as wrong actions, not wrong sentences
The three lines
- Definition — software that takes a goal, picks tools, reads results and decides its own next step
- Distinction — a workflow follows a fixed sequence; an agent decides at run time. The test is autonomy
- Cost — because it acts on the world, permission design matters as much as model quality
Key questions
- How is an AI agent different from a chatbot?
- The difference is whether the output is **text or action**. A chatbot takes a question and **produces an answer**; the user reads it and does the work. An agent takes a goal and **carries the work forward** — searching for what it needs, writing files, calling APIs, and changing approach when a result does not match expectations. Google Cloud defines an agent as a software system that uses AI to **pursue goals and complete tasks on a user's behalf**. The phrase doing the work is **on behalf of**. The same model can sit inside either: attach tools and grant decision authority and you have an agent; leave them off and you have a chatbot. This brief covered a concrete case in coding in "What Claude Code is — how it differs from asking a chatbot."
- How do you tell a workflow from an agent?
- By asking **who decides the next step**. A **workflow** has its sequence written in code beforehand — summarise the document, translate the summary, email the translation — with the model filling in each slot. An **agent** determines that sequence **while running**: it is given a goal, and it judges what to do now, which tool to use, and what to do after seeing the result. The distinction matters because **predictability and adaptability pull in opposite directions**. A workflow produces consistent results and stalls on situations it was not written for; an agent adapts to the unexpected and may take a different path on identical inputs. **Most business tasks are better served by a workflow.** Agents earn their cost where the path cannot be known in advance.
- How does an agent actually use a tool?
- Through **function calling**, in four steps. ① A developer gives the model a **list of available tools** and the input format each expects. ② Instead of prose, the model emits a **structured output saying which function to call with which arguments**. ③ That call is executed **by the surrounding program, not by the model**. ④ The result is fed back to the model as input, and it decides what to do next. Step ③ carries the weight. **The model does not reach the internet or delete a file itself.** It requests, and the surrounding program holds the authority to comply or refuse. That is why almost all agent safety design concentrates at this boundary — narrowing which tools exist at all, requiring human approval before irreversible actions, and separating read access from write access.
An AI agent is a model that has been given tools and the authority to decide.
A chatbot produces an answer. An agent carries the work forward.
The model can be identical. What differs is the structure around it.
1. What makes an agent an agent
| Input | Output | Who does the work | |
|---|---|---|---|
| Chatbot | A question | Text | The user |
| Agent | A goal | A sequence of actions | The agent |
Google Cloud's definition is a software system that uses AI to pursue goals and complete tasks on a user's behalf.
The load-bearing phrase is on behalf of. Ask a chatbot to summarise a document and you get a summary; what happens to it is your problem. Ask an agent to summarise a document and share it with the team, and it writes the summary, selects a channel, and sends it.
2. Workflow versus agent
These get conflated constantly. There is one test: who decides the next step.
| Workflow | Agent | |
|---|---|---|
| Sequence decided | Before running (by a developer, in code) | While running (by the model, in judgement) |
| Unexpected situations | Stops or errors | Changes approach and retries |
| Consistency of results | High | Lower — different paths on identical inputs |
| Cost | Predictable | Varies per run |
| Debugging | Straightforward | Hard — the path differs each time |
Which yields a practical conclusion that is easy to miss: an agent is not automatically the better choice.
For work whose path is fixed — producing the same report in the same format each morning — an agent adds cost and variance and nothing else. Agents earn their keep where the path cannot be known in advance: research where you do not yet know what to look for, debugging where you do not yet know the cause.
3. Four parts
Development guides converge on a similar decomposition.
| Part | Job | Without it |
|---|---|---|
| Perception | Takes in inputs, environment, and tool results | Repeats the same mistake, unable to see outcomes |
| Reasoning | Decides what to do now | Has tools but cannot choose among them |
| Memory | Retains what has been done and learned | Forgets earlier steps as it proceeds |
| Action | Calls tools and affects the world | Plans without executing |
Memory is the most frequent bottleneck in practice. An agent runs many steps, and the accumulated conversation and tool output eventually exceed the model's input limit, at which point the earliest material is dropped. This brief covers that limit in "What is a context window — a model does not read all million tokens."
4. How tools actually work — function calling
Saying an agent "went online" or "deleted a file" hides the actual structure.
| Step | Who | What happens |
|---|---|---|
| ① | Developer | Supplies a list of tools and their input formats to the model |
| ② | Model | Emits a structured call — this function, these arguments — instead of prose |
| ③ | Surrounding program | Executes the call |
| ④ | Model | Receives the result as input and decides the next step |
Step ③ is decisive. The model does not execute anything. It requests, and the surrounding program decides whether to comply.
Nearly all agent safety design lives at that boundary.
- Grant narrow permissions — a delete tool that is not in the list cannot be requested
- Gate irreversible actions — put human approval in front of sending, paying, deleting
- Separate reading from writing — issue query access and mutation access under different credentials
5. Failure costs more
When a chatbot is wrong, you get a wrong sentence. You read it and judge.
When an agent is wrong, you get a wrong action. The email is sent, the file is gone, the API call has landed.
| Failure | Chatbot | Agent |
|---|---|---|
| Factual error | A wrong answer | Acts on a false premise |
| Misread instruction | An off-target reply | Completes the wrong task |
| Repeated failure | Ask again | Retries the same failure, at cost |
| Contaminated input | A flawed summary | Mistakes text in a document for a command |
The last row is specific to agents. Agents read web pages, documents and email, and text inside those sources saying "ignore your previous instructions and do this" is not automatically distinguishable from the user's own instruction. The boundary that what an agent reads is data, not command, has to be enforced by the system around it — the model cannot be relied on to hold it alone.
This brief covers the sources of factual error in "What AI hallucination is — why models are trained not to say they don't know," and risk assessment in "What AI risk tiers are — when the company that built it grades its own work."
6. What is not settled
- Where the boundary sits — "agent" and "workflow" are a common distinction, not a standard. Products name similar systems differently.
- The four components — a shared framing across guides, not a specified architecture.
- Success rates — no reliable sector-level statistics were established.
- Function calling — implementations differ by provider; this describes the common structure.
- Permission recommendations — general principles, not verification of any product's security features.
Sources
- Google Cloud — What are AI agents? Definition, examples, types
- Salesforce — LLM agents: a complete guide
- Medium (UPC & TUM) — Fundamentals of Building Autonomous LLM Agents
- TILNOTE — What is an LLM agent? Practical notes on building agents that work
- WikiDocs — Introduction to building AI agents with Ollama and open-source LLMs