How AI agents work (and where they break)

An AI agent is an LLM that can take actions, not just produce text. It does this by calling external tools (functions, APIs, file systems, browsers) in a loop, deciding the next step based on the results of the previous one, until it decides the task is done.

The shift from "LLM that answers" to "LLM that does things" sounds incremental. It isn't. It changes what kinds of problems are tractable, what kinds of failures appear, and what kind of supervision the system needs.

The minimum that makes something an agent

Three ingredients:

1. An LLM that decides what to do next
2. A set of tools (functions the model can call) with clear input/output specs
3. A loop that runs the LLM, executes any tools it called, feeds the results back, and repeats

A non-agentic LLM call: prompt in → text out. Done.

An agentic loop: prompt in → LLM decides to call tool X with args Y → tool runs → tool output goes back to LLM → LLM decides what to do next (call another tool, call X again with different args, or produce a final answer) → repeat until the LLM signals "done."

That's it. Every agent framework is variations on that pattern.

What "tools" look like

A tool is just a function the LLM can call. The model is told (in its system prompt or via a structured "tools" parameter):

• The tool's name
• What it does
• What arguments it takes
• What it returns

For example, a tool definition for a search function:

Tool: web_search
Description: Search the web. Use when the question requires up-to-date information.
Arguments:
  query (string): the search query
Returns: list of {title, url, snippet}

When the LLM decides it needs to search, it outputs (in a structured format) "call web_search with query='2026 Nobel Prize laureates'." The agent loop intercepts that, runs the actual search, and passes the results back to the model on the next step.

Common tool categories:

• Read tools: search, file read, database query, API GET
• Write tools: file edit, API POST, database write, send message
• Compute tools: code execution, calculator, data analysis
• Browser tools: navigate, click, fill form, extract content
• Meta tools: spawn subagent, hand off to another agent, request human input

What agents are good for

The pattern earns its keep when the task:

• Has steps that depend on prior step outputs ("search → pick the most relevant result → read it → summarize")
• Involves integration with external systems (the LLM can't write to your database directly, but a tool can)
• Has uncertain length — sometimes 1 step, sometimes 20, depending on what comes up
• Benefits from adaptive planning — the model can change course based on what it discovers

Tasks where agents have shown reliable production value:

• Code modification across multiple files: read related files, understand the change scope, edit them, run tests, fix failures
• Customer support triage: read the ticket, search the knowledge base, draft a response, check if escalation is needed
• Research synthesis: search multiple sources, read them, extract relevant facts, cross-check, summarize with citations
• Data analysis: query the database, transform the result, generate a chart, write the interpretation

Where agents break

The failure modes are predictable and worth knowing before you ship one.

1. Looping without progress

The agent calls a tool, doesn't get what it expected, calls a similar tool, doesn't get what it expected, and keeps going. Costs spiral. Quality doesn't.

Mitigation: max-iteration limits, cost budgets, "are you making progress?" self-checks every N steps.

2. Calling the wrong tool with wrong arguments

The model picks a plausible-sounding tool, but the wrong one for the task. Or picks the right tool but malformed arguments. Either way, the result is garbage, and the model now reasons over garbage.

Mitigation: clear tool descriptions, restricted tool sets per task type, validation on tool arguments before execution.

3. Failing to know when to stop

The agent keeps refining "just one more pass" past the point of useful improvement. Bills compound.

Mitigation: explicit completion criteria, time budgets, human-in-the-loop checkpoints for high-stakes tasks.

4. Hallucinating tool outputs

Asked to call a tool, the model sometimes generates the expected output instead of waiting for the actual call. This used to be a common failure; modern frontier models do it less, but it still happens, especially under load.

Mitigation: parse outputs strictly, never trust the model's claim that "I called X and got Y" without seeing the tool execution log.

5. Cascading errors

A small mistake in step 3 becomes a confident wrong conclusion by step 10 because subsequent reasoning was built on the bad output. Hard to diagnose because the surface output looks plausible.

Mitigation: trace every step. When something looks wrong, replay the trace to find where reality and the agent's belief diverged.

6. Tool side effects you didn't authorize

The agent's tools include "send email" or "update database." The agent gets confused and sends emails to the wrong list, or updates the wrong records. Hard to undo.

Mitigation: dry-run modes, confirmation gates on irreversible actions, scoped permissions per task.

The autonomy spectrum

Agents aren't binary. Useful systems span a range:

• Pure chat: no tools. Just LLM in/out.
• Suggested tool calls: the LLM proposes tool calls, a human reviews and approves each one. (Cursor's tool-use UX, for example.)
• Constrained autonomous loops: the agent runs autonomously but only within a strict tool set, with budgets and check-ins.
• Autonomous with human oversight: the agent runs to completion, but a human reviews the output before any irreversible action.
• Fully autonomous in production: the agent operates without supervision on real workflows. High stakes; needs serious monitoring.

The right point on the spectrum depends on stakes, reversibility, and how often the agent gets things wrong. Most successful production agents in 2026 sit between "constrained autonomous loops" and "autonomous with human oversight" — full autonomy on real workflows is still rare for a reason.

Multi-agent vs. single-agent

A pattern that's grown common: split the work across multiple agents with different roles (planner, executor, reviewer). Each is a focused LLM call with its own tools and prompt.

Multi-agent helps when:

• The task has distinct phases that benefit from different system prompts
• Different phases need different tool sets (security implications)
• One agent's context window would fill up trying to do everything

It hurts when:

• Coordination overhead between agents exceeds the benefit
• Errors compound across agents (each adds noise)
• The user just wanted a quick answer

For most production tasks, a single well-designed agent with a clear tool set beats a 5-agent system. Multi-agent is worth the complexity only when the task structure requires it.

What to log when you ship an agent

If you're moving an agent to production, instrument:

• Every tool call (name, arguments, output, latency, error)
• Every model decision (the chain of "I'm going to do X because Y")
• Total cost per run (model tokens + tool costs)
• Iteration count (looping is the most common silent failure)
• Completion reason ("model said done," "max iterations hit," "error," "human canceled")

Without these, debugging agent failures is impossible. With them, you can usually find the exact step where things went sideways.

What's coming

Three directions the agent space is moving:

1. Better autonomy with fewer hallucinations: frontier models in 2026 are meaningfully more reliable at multi-step tasks than they were in 2024
2. Standardized tool protocols: Model Context Protocol (MCP) is becoming the de facto way for agents to discover and use tools across providers
3. Composable agents: agents that can spawn or call other specialized agents, with structured handoffs

The pattern of "LLM in a loop with tools" stays the same. What changes is how reliable, how composable, and how supervised these systems are.

What to read next

• Prompts vs Skills vs Workflows vs Agents — when to use which — the decision framework one level up
• How large language models work — the mechanism the agent loop is built around
• Catching AI-generated bugs before they ship — relevant when agents are editing your code