What Are AI Agents? Tools, Loops, Goals, and Failure Modes

An AI agent is a language model given three things a chatbot lacks: tools it can call, a goal to finish, and a loop that lets it decide its own next step until an exit condition fires. OpenAI's builder guide draws the line sharply — an app that integrates an LLM but does not let the model control workflow execution is not an agent. Everything else about agents follows from that mechanism, including how they fail.

What an AI agent actually is#

Strip away the marketing and an agent has three components, which OpenAI's practical guide names directly: a model that makes the decisions, tools it can call, and instructions that constrain both. The model does two jobs a plain integration never does. It manages workflow execution — recognizing when the task is complete and correcting its own course — and it dynamically picks which tool to use next, inside guardrails you define.

Anthropic's engineering guidance draws the same boundary from the other side. Workflows are systems where LLMs and tools move through code paths you predefined; agents are systems where the model directs its own process and tool usage, keeping control over how the task gets done. The distinction is who decides the next step: your code, or the model at runtime.

Tools come in three types under OpenAI's taxonomy. Data tools retrieve context, such as querying a database or reading a document. Action tools change external systems — sending a message, updating a record — and orchestration tools let one agent invoke another as a step in its own plan.

Agent vs chatbot: tools, loops, goals#

A chatbot maps an input to an output in one pass. OpenAI's guide lists simple chatbots, single-turn LLM apps, and sentiment classifiers as explicitly not agents, because the model never controls what happens next. The conversation may be long, but each reply is a dead end: no tool selected, no result observed, no goal carried forward.

The n8n documentation makes the same cut in workflow terms. Chains call the LLM in a fixed sequence along a predetermined path with no tool selection, and they lack memory; agents use the model to interpret the request, actively choose tools, and retain context across interactions. When an n8n workflow contains an agent node, that node runs multiple times in one execution — initial setup, each tool call, and the evaluation of every tool response.

The three-word summary holds up: tools, loops, goals. A system missing any one of them is something else — useful, often preferable, but not an agent.

The plan-act-observe loop, step by step#

The loop pattern most agents run traces back to the ReAct paper, which interleaved reasoning traces with task actions. Reasoning helps the model build, track, and update its plan and handle exceptions; actions let it pull real information from external sources instead of inventing it. In the paper's experiments, grounding steps in a simple Wikipedia API reduced the hallucination and error propagation that plagued chain-of-thought reasoning alone, and the resulting trajectories were easier for humans to inspect.

1. Plan

   The model reads the goal plus everything observed so far and reasons about what would move the task forward. This step produces an intention: either a specific tool call with arguments, or a decision that the task is done.

2. Act

   The chosen tool executes with the arguments the model wrote. This is the moment the agent touches the world — a database query, an API call, a file write — so it is also where permissions and risk gates belong.

3. Observe

   The tool's raw result is appended to the model's context. The next planning step sees actual output, not a guess about it, which is what keeps the loop anchored to reality when a lookup fails or returns something unexpected.

4. Exit or repeat

   OpenAI's guide documents two exit conditions: the model invokes a designated final-output tool, or it returns a response containing no tool calls at all. Until one fires, the loop goes back to planning with a longer context.

Note what the observe step buys you. An agent that checks the order database before promising a refund cannot hallucinate the order into existence, because the lookup result — including an empty one — sits in its context when it plans the next move.

A worked example: one agent loop in pseudocode#

Here is a refund-request triage agent reduced to its skeleton. Every real framework adds machinery, but this is the control flow underneath.

GOAL  = "Resolve the customer's refund request or escalate it"
TOOLS = [lookup_order, check_refund_policy, issue_refund, reply_to_customer]
RISK  = issue_refund: HIGH, reply_to_customer: MEDIUM, everything else: LOW

history  = [GOAL, customer_message]
failures = 0

loop:
    step = llm(history, TOOLS)              # PLAN: model picks the next move

    if step has no tool call:               # EXIT: final answer produced
        return step.text

    if RISK[step.tool] == HIGH:             # gate before irreversible acts
        approved = ask_human(step.tool, step.args)
        if not approved:
            history.append("Denied by reviewer: " + reason)
            continue                         # loop again, denial visible

    result = execute(step.tool, step.args)   # ACT
    history.append(result)                   # OBSERVE

    if result is an error:
        failures += 1
        if failures > RETRY_LIMIT:           # escalation trigger
            return escalate_to_human(history)

Walk the annotations. The model, not the code, decides whether to call lookup_order first or jump straight to the policy check — that runtime choice is what makes this an agent rather than a chain. The exit condition on line one of the loop is one of the two OpenAI documents: a response without tool calls ends the run.

The risk gate mirrors OpenAI's tool-safeguard guidance: rate each tool low, medium, or high based on write access, reversibility, required permissions, and financial impact, then pause or escalate before high-risk functions. issue_refund moves money, so a human sees the tool name and arguments before it runs. The failure counter implements the other documented human-intervention trigger — exceeding a retry limit hands the whole history to a person instead of burning tokens on a doomed loop.

The same skeleton powers less risky builds too. The inbox triage automation walkthrough applies a similar classify-then-act pattern to email, where most actions stay comfortably in the low-risk tier.

What agents genuinely do well today#

OpenAI's guide gives three criteria for when an agent earns its complexity, and they make a decent honest list of strengths. Complex decision-making: workflows with judgment calls, exceptions, and context-sensitive choices, like deciding whether a refund request deserves approval. Difficult-to-maintain rules: systems whose rulebooks have grown so tangled that every update is expensive and error-prone. Heavy reliance on unstructured data: tasks that live in natural language, documents, and conversation rather than clean fields.

Anthropic's framing adds the operational upside: agents plan and operate independently, use environmental feedback to gauge progress, and can return to a human when they need information or judgment. That makes them a fit for open-ended tasks where you cannot enumerate the steps in advance — the plan emerges from what the tools return.

Design still matters more than ambition. OpenAI recommends maximizing a single agent before splitting into several, and only splitting when the agent fails to follow complicated instructions or keeps picking wrong tools. Its guide notes that some implementations manage more than 15 well-defined, distinct tools while others struggle with fewer than 10 overlapping ones — tool clarity, not tool count, is the constraint.

Where agents fail#

The benchmark numbers are blunt. On tau-bench, which tests agents talking to simulated users while following domain policy rules and calling API tools, state-of-the-art function-calling agents succeeded on fewer than 50% of tasks. Reliability is worse than the headline: the benchmark's pass^8 metric — the same task solved in all eight of eight runs — came in below 25% in the retail domain.

Errors also compound. Anthropic's guidance is explicit that agentic systems trade latency and cost for task performance and carry the potential for compounding errors: a wrong observation in turn two quietly poisons every plan after it. A workflow fails loudly at a known step; an agent can fail confidently, several steps past the actual mistake, which is why error handling patterns for automations and an eval harness like the one in the AI output quality testing guide matter more here than anywhere else.

Cost variance is the third failure mode. Each loop turn resends the growing context, so long sessions keep consuming budget even when they look idle, and scheduled agent tasks fire on their interval whether or not anyone is watching — both warnings straight from Anthropic's cost documentation. Budgeting a fixed per-run cost, the way the LLM API cost estimation tutorial does for single calls, simply does not work when the number of calls is the model's decision.

You do not need an agent when...#

Both vendors who publish serious builder guidance say the quiet part: most tasks do not need an agent. Anthropic advises finding the simplest solution possible and increasing complexity only when needed, noting that many applications are better served by optimized single LLM calls with retrieval and examples. OpenAI's guide says a deterministic solution may suffice unless the task involves complex decisions, unmaintainable rules, or unstructured data.

Skip the agent when any of these holds:

• The logic fits explicit conditions you can write down. If a human can flowchart it, code should run it.
• Every run takes the same steps in the same order. That is a chain, and chains are cheaper, faster, and testable.
• The output must be identical for identical input. Agent runs vary by design; tau-bench measured exactly how much.
• Latency or per-unit cost is tight. An agent decides at runtime how many model calls to make; a workflow gives you a fixed bill.
• One well-crafted prompt already solves it. A single LLM call inside a workflow is not a lesser solution — it is the recommended starting point.

Anthropic's guidance names five workflow patterns that cover most structured cases before an agent is justified: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. Routing plus one LLM call handles a surprising share of what gets pitched as "agentic."

For the workflow route, a visual automation platform is usually the fastest path, and the n8n vs Make vs Zapier comparison breaks down which one fits which team. n8n is the natural pick if you want the option to embed an agent node inside an otherwise deterministic workflow later — with the caveat its docs spell out: an agent node runs the model multiple times per execution, once for setup and again for each tool call and each tool-response evaluation, so that one node's cost scales in a way the fixed nodes around it never will.

Safety basics before you let an agent act#

An agent is software that writes its own next command, so the controls have to live outside the model. Three mechanisms cover most of the risk: permissions, spend caps, and human approval gates.

Permissions: read-only by default#

Claude Code's permission system is a concrete reference implementation of tiered access. Read-only operations like file reads need no approval inside the working directory; shell commands — apart from a built-in read-only set — and file modifications require explicit approval. Rules come in three types — allow, ask, deny — evaluated deny first, then ask, then allow, so a broad deny always beats a narrower allow.

The detail worth copying: the harness enforces the rules, not the model. Prompt instructions cannot change what the tooling permits, which is the property you want when the thing being constrained is also the thing writing the prompts. The docs reserve the bypass-permissions mode for isolated environments such as containers or VMs where the agent cannot cause damage, and note that file rules do not cover arbitrary subprocesses — OS-level enforcement needs the sandbox turned on.

Spend caps: assume the loop runs long#

Because the model decides how many calls to make, budget control is a platform setting, not a prompt line. Anthropic's cost docs report that across enterprise Claude Code deployments, the average cost is around $13 per developer per active day and $150-250 per developer per month, with 90% of users staying below $30 per active day (checked August 2026). The same docs describe workspace spend limits that cap total Claude Code spend and workspace rate limits that protect other workloads.

Set both before the first unattended run. The failure mode is not one expensive session — it is the session nobody remembered, resending its full context on every request.

Human approval for irreversible actions#

Anything that cannot be undone should stop and ask. OpenAI's guide names the trigger list plainly: sensitive, irreversible, or high-stakes actions such as canceling orders, authorizing large refunds, or making payments should route to human oversight, alongside runs that blow past retry limits.

n8n ships this as a feature rather than a pattern. With human review enabled on a tool, the workflow pauses when the agent wants to call it and sends an approval request — tool name and parameters included — to a reviewer over channels that include Slack, Telegram, and n8n's built-in chat. Approval executes the tool with the AI-specified input; denial cancels the action, and the docs recommend the gate for deleting data, sending external communications, and making purchases.

Layer the rest of OpenAI's guardrail catalog around the loop as the stakes rise: relevance and safety classifiers for prompt-injection attempts, PII filters, rules-based blocklists and input length limits, and output validation. The AI tool security checklist covers how to vet the platforms these agents run on.

The bottom line#

Define agents by mechanism and the decision gets easy. Tools, a goal, and a model-controlled loop: if a task genuinely needs all three — judgment calls, unstructured input, steps that depend on what the last step found — build an agent, start it read-only, cap its spend, and gate every irreversible tool behind a human.

If you can write the procedure down, do not build an agent. Build the workflow, keep the one LLM call where language understanding is actually required, and bank the reliability: the deterministic version runs the same way every time, which is more than a sub-25% pass^8 can promise. The teams getting value from agents in 2026 are not the ones deploying them everywhere — they are the ones who know exactly which branch point earned the loop.