AI agents explained

An AI agent is software that uses a language model to decide what to do next, acts through tools, and keeps going until a goal is met. This guide explains how agents work, the patterns they use to plan and remember, where the Model Context Protocol stands as of October 2026, and how to make an agent reliable, affordable and safe.

What an AI agent is

An AI agent combines four building blocks:

• A language model that reads the situation and picks the next step. Reasoning models are the usual choice because they plan well between steps.
• Tools: functions the model can request, such as searching documents, querying a database, running code or sending an email.
• A loop: code that runs the model, executes the tools it asks for, feeds back the results and repeats until the model finishes or hits a limit.
• Memory: what the agent knows beyond the current request, from notes made during the task to facts stored between sessions.

Agents vs chatbots and workflows

These labels get used loosely. A useful distinction, popularized by Anthropic's engineering team, is that a workflow runs model calls and tools along paths you wrote in code, while an agent lets the model choose its own path.

The rule of thumb: if you can write the steps down in advance, build a workflow. Use an agent when the path depends on what the model discovers along the way, as in debugging or open-ended research. Many production systems put one agentic step inside an otherwise fixed workflow.

Tools, tool calling and MCP

How a tool call works

Tool calling, also called function calling, lets the model ask your code to do something. The model never executes anything itself. Each exchange follows the same four steps:

1. You send tool definitions with the request: a name, a plain-language description and a JSON Schema for the arguments.
2. The model replies with a structured tool call, a tool name plus arguments, instead of or alongside text.
3. Your code validates the arguments, checks permissions and runs the tool.
4. You return the result, and the model calls more tools (sometimes several in parallel) or writes its answer.

Tool definition (field names vary slightly by provider):
{
  "name": "get_order_status",
  "description": "Look up the shipping status of one order. Use when a
                  customer asks where their order is.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "description": "Order ID, e.g. A-10442"}
    },
    "required": ["order_id"]
  }
}

Model's reply (a request, not an action):
{"tool": "get_order_status", "arguments": {"order_id": "A-10442"}}

Your code runs the lookup and sends back:
{"order_id": "A-10442", "status": "in transit", "eta": "2026-10-14"}

Model's final answer:
"Order A-10442 is in transit and should arrive on October 14."

The model chooses tools by reading their descriptions, so spell out what each tool does, when to use it and what each argument means. A few well-scoped tools, such as one that finds a customer's recent orders rather than one that dumps every order, beat dozens of thin wrappers around API endpoints.

The agent loop in code

messages = [system_prompt, user_goal]
for step in range(MAX_STEPS):              # hard stop
    reply = model(messages, tools)
    if not reply.tool_calls:
        return reply.text                  # the model is done
    for call in reply.tool_calls:
        require_permission(call)           # policy lives in code
        result = run_in_sandbox(call, timeout=30)
        messages.append(tool_result(call.id, result))
raise StepLimitReached(messages)

Limits, permission checks and sandboxing live in code, not the prompt. The model proposes; your code decides what runs.

The Model Context Protocol (MCP)

Without a standard, every app needs custom code for every integration. The Model Context Protocol fixes that: wrap a system once as an MCP server, and any MCP-compatible application can use it. Anthropic introduced MCP in November 2024, and in December 2025 contributed it to the Agentic AI Foundation, a Linux Foundation project whose founding members include AWS, Anthropic, Google, Microsoft and OpenAI.

The host application, such as a chat app, IDE or agent, runs one MCP client per connected server. Servers offer three main primitives: tools the model can call, resources it can read and reusable prompts. Local servers use standard input and output; remote servers use HTTP, with OAuth recommended for authorization.

As of October 2026, ChatGPT, Claude, VS Code, Cursor and most agent frameworks support MCP, making it the de facto way to connect agents to tools. The current specification revision, dated 2026-07-28, made the protocol stateless, so each request carries its own version and capabilities. It also moved long-running tasks into an optional extension and deprecated the sampling, roots and logging features, so check which revision your SDKs support.

Two cautions apply. Every connected tool's description takes up context on every call, so attaching dozens of servers can burn tens of thousands of tokens before the model reads the request. And an MCP server is code you're trusting, so install servers only from trusted sources and pin versions. For agent-to-agent communication, the Agent2Agent (A2A) protocol, created by Google and now under the Linux Foundation, complements MCP.

Planning patterns and memory

ReAct-style loops

The most common pattern alternates reasoning and acting: the model decides what to do, calls a tool, reads the result and repeats. The 2022 ReAct paper that named the pattern reported success-rate gains of 34 and 10 percentage points over imitation and reinforcement learning methods on two interactive benchmarks. Today's reasoning models can think between tool calls natively, so a plain loop with a capable model is often enough.

Plan-and-execute

Here the model writes a full plan first, then works through the steps, replanning only when something fails. A plan can be approved before anything happens, and a cheaper model can often carry out routine steps. The weakness is rigidity: if step three turns up a surprise, the rest of the plan may be wrong. Many coding agents blend both patterns with a to-do list they update as they go.

Reflection

Reflection adds a review step: the agent critiques its own output or trajectory, then retries using what it learned. In the 2023 Reflexion paper, agents that wrote down lessons from failed attempts reached 91 percent pass@1 on the HumanEval coding benchmark, against 80 percent reported for GPT-4 at the time. Reflection works best with an external signal, such as failing tests, rather than the model's opinion of its own work.

Memory types

Long-term memory is usually retrieval pointed at the agent's own history, so the same design questions apply: what to store, when to recall it and who may see it.

Multi-agent systems: when they're worth it

A multi-agent system splits work among several model instances, typically an orchestrator that plans and delegates and workers that each handle a subtask in their own context window. The benefit is separate contexts: each worker can read dozens of documents without crowding the orchestrator, and workers run in parallel.

The evidence cuts both ways. In June 2025, Anthropic reported that its multi-agent research system outperformed a single agent by 90.2 percent on an internal research evaluation. The same report found agents used about 4 times the tokens of a chat and multi-agent systems about 15 times. It named poor fits too: tasks where every agent needs the same context, work with many dependencies between steps, most coding, and anything that requires real-time coordination.

Use multiple agents when the job splits into independent parts, such as profiling ten competitors or checking fifty contracts against a policy, and the value of each task justifies the tokens. Otherwise, one agent with good tools is easier to build, debug and pay for.

Frameworks and platforms

A model API and a loop like the one above is enough for a first agent, and it's the best way to learn what's happening. Frameworks add state management, retries, tracing, approval pauses and multi-agent orchestration. The main options as of October 2026:

Choose based on your language, how much control you need, whether you're committed to one model provider and where you'll deploy. Most support MCP tools, so integrations carry over if you switch. Our resources page tracks more frameworks.

Reliability, evaluation, cost and latency

Why errors compound

Agent failures multiply. If each step succeeds 95 percent of the time, a 20-step task succeeds only about 36 percent of the time (0.95 to the 20th power); at 99 percent per step, it's about 82 percent. Shorter tasks, checkpoints that verify progress and graceful recovery from tool errors often matter more than a slightly smarter model.

Consistency is a separate problem. The 2024 τ-bench study introduced pass^k, the chance that an agent succeeds on all k attempts at the same task. Agents built on GPT-4o solved fewer than half of its tasks, and their pass^8 in the retail domain fell below 25 percent.

How to evaluate an agent

• Start small. Twenty to fifty realistic tasks with checkable outcomes will reveal the effect of early changes.
• Grade the end state, not the path. Check whether the ticket was resolved or the tests pass, because agents can reach a correct result by different routes.
• Repeat runs. Run each task several times and report pass^k next to the average.
• Track operations. Record steps, tokens, cost per successful task, tool error rate and how often a person had to step in.
• Trace everything. Log every model call, tool call and argument so you can replay failures.
• Judge carefully. Use an LLM-as-a-judge with a rubric for open-ended output, and keep people reviewing samples.

Public agent benchmarks are covered in our benchmarks guide.

Controlling cost and latency

Agents resend their growing context on every step, so tokens climb fast. Take a 10-step task with 3,000 tokens of system prompt and tool definitions, where each step adds 1,500 tokens of output and tool results. Input totals 97,500 tokens across the run. At $2 per million input tokens and $10 per million output tokens, with 300 output tokens per step, that's about $0.23 per task, roughly 25 times a single 3,000-token chat call.

If your provider bills cached input at a tenth of the normal rate, prompt caching the repeated prefix cuts that to under $0.08, before any cache-write surcharge. Other levers:

• Cap steps, tokens and wall-clock time per task, and fail loudly when a cap is hit.
• Route routine steps to a smaller model and save the strongest one for planning.
• Trim tool output in code before the model sees it. Anthropic described a case where calling MCP tools from code cut token use from 150,000 to 2,000.
• Load tool definitions on demand, and lower reasoning effort for simple steps.

Latency adds up the same way. At 4 seconds per model turn and 1 second per tool call, a 10-step run takes about 50 seconds, so stream progress or run the agent in the background.

Security: permissions, sandboxing and approval

An agent acts with whatever permissions you give it, and anything it reads can try to redirect it through prompt injection. OWASP's Top 10 for Agentic Applications, published in December 2025, lists goal hijacking, tool misuse, privilege abuse and memory poisoning among the leading risks. The defenses are architectural:

• Least privilege. Scope each tool narrowly: read-only where possible, per-user credentials rather than a shared admin key, and allowlisted domains and recipients.
• Sandboxing. Run code and shell commands in a disposable container or virtual machine with no secrets, restricted network access and CPU, memory and time limits.
• Human approval. Require confirmation for irreversible, costly or public actions such as sending, paying, deleting, deploying or changing permissions. Show the exact action and arguments, not a summary.
• Separation. Don't let one agent hold private data, read untrusted content and send data out without a checkpoint in between.
• Audit and stop. Log every action with what triggered it, and keep a kill switch that revokes tool access immediately.

The LLM security and privacy guide covers these defenses and guardrails in more depth.

Where agents work today, and where they don't

Agents succeed where results can be checked and mistakes can be undone. As of October 2026, the strongest use cases are:

• Software engineering: coding agents working in a repository with tests, version control and code review.
• Research: gathering, reading and summarizing sources with citations; mostly read-only and easy to parallelize.
• Data analysis: writing and running code in a sandbox, where errors surface as exceptions.
• Support and operations: narrow, well-tooled tasks such as order lookups, small refunds and runbook steps, with escalation to people.

They still struggle with long, open-ended tasks without checkpoints, high-stakes decisions made without human sign-off, and graphical interfaces with no API, where computer-use agents remain slow and brittle. They're also poor value for simple, high-volume tasks that a single call or fixed workflow handles more cheaply. Before you build, confirm the basics:

Common mistakes

• Starting with a multi-agent framework before a single loop works.
• Giving the agent every tool just in case, which wastes context and invites misuse.
• Vague tool descriptions and error messages. The model can only use what it understands, so errors should say how to fix the problem.
• No step, token or time limits, so a confused agent loops until the budget runs out.
• Judging from a few demo runs instead of repeated runs over a task set.
• Enforcing permissions in the prompt instead of in code.

Next steps

Estimate your per-task token bill with the LLM cost calculator, and use the prompt engineering guide to write the system prompt and tool descriptions. Before an agent touches real data, work through the checklist in the security and privacy guide. If you'd like experienced help designing, evaluating or hardening an agent, you can hire LLM experts.