What Is an AI Agent? (2026)

Skim to the part you need:

1. A precise definition of an AI agent.

2. The agent loop — perceive, plan, act, observe.

3. Tool use — the thing that makes an agent more than a chatbot.

4. The ReAct pattern — reasoning and acting interleaved.

5. Agent vs chatbot vs workflow — the comparison that ends the confusion.

6. When to use an agent (and when not to).

7. Risks and how to contain them.

8. How to start small.

9. FAQs and Sources & further reading.

Sources include the ReAct paper (Yao et al.) and the DAIR.ai Prompt Engineering Guide, both linked with dates in the final section.

An AI agent is an LLM-driven system that, given a goal, repeatedly decides on and executes actions — including calling external tools — and uses the results of those actions to inform its next decision, continuing until the goal is met or a stopping condition fires.

Unpack the three load-bearing words. **Goal:** you give the agent an objective ('book the cheapest flight under these constraints', 'triage these 40 support tickets'), not a single instruction. **Decides:** the model, not a hard-coded script, chooses the next step. **Tools:** the agent can affect the world or pull in fresh information — search the web, run code, query a database, call an API — rather than relying only on what's in its weights.

Contrast that with a plain LLM call: you send a prompt, you get one response, the interaction ends. The LLM didn't choose to look anything up or take an action; it just produced text. The moment you add a loop, tool access, and goal-directed decision-making, you have an agent.

Almost every agent runs some version of the same loop: perceive the current state, plan the next step, act (often by calling a tool), and observe the result — then repeat.

**Perceive.** The agent reads its current context: the goal, conversation/history, and any results from previous actions.

**Plan / reason.** It decides what to do next. This might be 'search for X', 'run this code', 'ask the user a clarifying question', or 'I have enough — produce the final answer'.

**Act.** If the plan calls for a tool, the agent emits a structured tool call (e.g. a search query or an API request). A surrounding program executes that call.

**Observe.** The tool's output is fed back into the agent's context. With the new information, the loop repeats. A stopping condition — goal achieved, step/cost budget exhausted, or an error — ends it.

This loop is what distinguishes agentic behavior. Remove the loop and the tools and you're back to a chatbot.

Tool use (also called function calling) is the mechanism that lets a language model do more than generate text. You describe the tools available — name, what they do, and the parameters they accept — and the model can respond with a structured request to call one. Your code runs the tool and returns the result, which the model reads on the next turn.

Common tools: web search (fresh information), a code interpreter (calculation, data work), database/API queries (your systems and data), file operations, and even other agents. The key idea is that the model decides which tool to use and with what arguments; it's not a fixed pipeline you wrote in advance.

Tool use is also where agents earn their keep: an LLM alone can't know today's exchange rate, run a real query against your data, or send an email — but an agent with the right tools can. For the prompt-design side of describing tools well, the DAIR.ai Prompt Engineering Guide is a strong reference.

The most influential pattern behind modern agents is ReAct — short for 'Reasoning and Acting' — introduced by Yao et al. in 2022 (arXiv:2210.03629). ReAct interleaves reasoning steps ('thoughts' about what to do) with actions (tool calls) and observations (tool results), so the model reasons about a problem and acts on it in the same loop rather than separately.

A simplified ReAct trace looks like this:

``` Thought: I need the current population of the city to answer this. Action: search("current population of <city>") Observation: <search result> Thought: Now I can compute the per-capita figure. Action: calculator("<number> / <population>") Observation: <result> Thought: I have what I need. Answer: <final answer with the figure> ```

The value of ReAct is that the reasoning grounds the actions (the model explains why it's calling a tool) and the observations ground the reasoning (the model updates based on real results instead of guessing). This reduces unsupported answers and makes the agent's behavior more inspectable. The DAIR.ai guide's ReAct section walks through it with examples.

These three get conflated constantly, and the distinction is mostly about who controls the steps.

**Chatbot:** responds to each message in turn. No goal-directed multi-step autonomy of its own; it answers what you ask. Great for Q&A, support deflection, and conversation.

**Workflow:** a fixed, pre-defined sequence of steps that you, the developer, wired up. An LLM may be one step in it ('summarize this', 'classify that'), but the control flow is hard-coded. Predictable, cheap, easy to test.

**Agent:** the LLM decides the steps dynamically using tools in a loop. Flexible and capable of handling open-ended tasks, but less predictable, harder to test, and more expensive (more model calls).

The practical rule: if you can write the steps down in advance, build a workflow. If the steps genuinely depend on what's discovered along the way, an agent earns its complexity. Our deeper guide covers this tradeoff in production: agents vs workflows: when to use each.

Use a workflow when: you can specify the steps in advance, you want predictable cost and behavior, and the task is the same shape every time.
Use an agent when: the required steps depend on what's discovered mid-task, the input space is open-ended, and dynamic tool use genuinely beats a fixed pipeline.

**Good fits for an agent:** open-ended research where the next query depends on the last result; tasks that require choosing among many tools depending on the input; multi-step workflows where branching is too variable to hard-code; and exploratory work where you genuinely don't know the steps in advance.

**Poor fits (use a workflow or a single LLM call instead):** anything with a fixed, known sequence of steps; high-volume simple tasks where the extra model calls of an agent loop are wasteful; tasks where predictability and auditability matter more than flexibility; and cases where a single well-crafted prompt already does the job.

A common and costly mistake is reaching for an agent because it's the exciting option. Agents multiply your token cost (each loop step is a model call), add latency, and introduce unpredictability. Start with the simplest thing that works — often a single prompt or a small workflow — and escalate to an agent only when the task's variability demands it.

Agents act, which means their mistakes have consequences beyond a bad sentence. Three risks deserve attention.

**Cost and runaway loops.** Because each step is a model call, an agent that loops can rack up cost fast. Always set hard limits: maximum steps, maximum cost/tokens, and timeouts.

**Unsafe actions.** An agent with tools that can send email, spend money, or modify data can do real damage. Gate consequential actions behind human approval, scope tool permissions tightly, and prefer read-only tools where possible.

**Prompt injection.** When an agent reads external content (web pages, documents, emails), that content can contain instructions that try to hijack the agent. Prompt injection is the #1 risk in the OWASP LLM Top 10 (LLM01:2025). Treat retrieved content as untrusted data, not instructions. For practical defenses, see our prompt injection defense checklist.

These aren't reasons to avoid agents — they're reasons to bound them. A well-scoped agent with step limits, permission gates, and injection awareness is safe to run.

Don't build a multi-agent system on day one. Start with one agent, one or two tools, and a tight goal. Give it a single capability it can't get from a plain prompt — web search, for example — and watch how it reasons through the loop.

Instrument everything: log each thought, action, and observation so you can see why the agent did what it did (the ReAct trace makes this natural). Set a low step cap. Run it on real tasks and read the traces — you'll quickly learn where it gets stuck or over-acts.

Only add more tools, more autonomy, or more agents once the simple version proves it needs them. For writing the prompts and tool descriptions that drive an agent, the Code Prompt Builder and our system prompt guide help you be precise about role and constraints.

Definitions and patterns above draw on these sources — confirm details at the originals:

ReAct: Yao et al., 2022, 'ReAct: Synergizing Reasoning and Acting in Language Models' — arXiv:2210.03629 (accessed June 2026).

DAIR.ai Prompt Engineering Guide — agents, tool use, and the ReAct pattern: promptingguide.ai (accessed June 2026).

OWASP GenAI / LLM Top 10 — prompt injection (LLM01:2025): genai.owasp.org/llm-top-10 (accessed June 2026).

Learn Prompting — agent and tool-use explainers: learnprompting.org.

On-site reading: agents vs workflows: when to use each and prompt injection defense checklist.