Agents Overview

How LLMs go from answering questions to taking actions, using tools, and coordinating with each other. This section covers what actually makes something an "agent" rather than a chatbot, the concrete architectures for structuring an agent's reasoning loop, the emerging protocols that let agents talk to tools and to each other, and what changes once more than one agent is involved.

From a Single Call to an Agent

"Agent" isn't a single capability — it's a ladder, and where a system sits on it determines what it can and can't do on its own:

Click a rung -- each one strictly adds a capability the rung below it doesn't have.

Wraps the model in a loop: it can call a tool, observe the result, and decide what to do next -- potentially many times -- before answering.

A plain LLM call answers one prompt and stops. A chatbot holds a conversation but still can't act on the world. An agent adds a loop: the model can decide to call a tool, observe what comes back, and decide what to do next — see Agent Fundamentals for exactly how that loop and tool-calling work in detail.

The Loop at the Center of Everything

Every agent, regardless of architecture, is running some version of the same cycle:

Decide what to do about it, given everything so far -- the whole point of the underlying LLM call.

Perceive — take in the current state (a user request, a tool result, an observation). Reason — decide what to do about it, given everything so far. Act — take an action (call a tool, respond, hand off to another agent) that changes the state and feeds the next perceive step. The architectures below are all different answers to "how exactly should this loop be structured?"

The Two Load-Bearing Pieces: Tools and Memory

Everything an agent can do comes down to two capabilities, both covered in depth in Agent Fundamentals:

Click a pillar to see what breaks without it.

Without tools: an agent can reason about what to do, but has no way to actually do it -- it can only ever produce text.

Without well-designed tools, an agent has reasoning but no way to act. Without memory, an agent can act but can't accumulate context beyond a single conversation or a single context window's worth of history.

Architectures: Different Answers to "How Should the Loop Run?"

Click an architecture -- the axis is real: more reliability generally costs more per task.

Interleave reasoning and action, react to each result as it comes back. Flexible and course-corrects on real information, but can wander -- no commitment to an overall plan.

Agent Architectures covers ReAct (interleave reasoning and action, react to each result), Plan-and-Execute (commit to a full plan upfront, execute it, replan on failure), and reflection (critique and revise your own output) in detail — each trades reliability, cost, and latency differently, and the right choice depends on how predictable the task is upfront.

Standardizing Connections: MCP and A2A

Once an agent needs to talk to tools and to other agents, ad hoc integration code doesn't scale — two emerging protocols standardize each side of that:

Click either edge -- same "agent talks to X" shape, structurally different problem.

MCP standardizes agent -> tool: stateless-ish, synchronous, "call a function, get a result." Tools have no reasoning of their own.

MCP standardizes agent-to-tool connections (a database, a file system, an API) so tools and applications can be built independently. A2A standardizes agent-to-agent connections, which need to support longer-running, statesful, potentially cross-organization interactions that a simple function call doesn't fit.

When One Agent Isn't Enough

Coordination pattern

Same 4 agents, 3 different topologies -- the shape IS the tradeoff.

One orchestrator delegates to specialized sub-agents and combines results. Easiest to reason about and debug -- there's a clear owner of the overall task.

Multi-Agent Systems covers hierarchical (orchestrator delegates to sub-agents), peer-to-peer, and blackboard coordination patterns — each trading ease of debugging against flexibility, and each introducing its own conflict-resolution problem once more than one agent can act on shared state.

How Agentic Systems Actually Fail

Tool misuse→ Tool design

Runaway loops→ Loop structure

Context bloat→ Memory management

Coordination conflicts→ Coordination pattern

Four separate failure modes, four separate root layers -- not one generic "agents are unreliable" problem.

Ambiguous names/schemas lead the model to call the wrong tool, or call the right tool with malformed arguments.

Most production agent failures cluster into a small set of recurring modes — tool misuse from ambiguous schemas, runaway loops that never converge, context windows silently overflowing with stale history, and multi-agent coordination producing contradictory results. Each is addressed at the layer it originates from (tool design, loop structure, memory management, coordination pattern) rather than by a single fix.

Is This Even an Agent Problem?

Not every LLM-powered feature needs an agent — a lot of tasks are better served by a single call or a fixed pipeline:

This is the actual test for needing an agent: not "is an LLM involved" but "does the next action depend on a result I can't predict beforehand."

The moment a task's steps can't be fully predicted upfront — the right next action depends on what a previous step actually returned — is the moment a fixed pipeline stops working and an agentic loop earns its complexity.

How Much Autonomy Should an Agent Have?

Autonomy level: Human approves risky actions only2

More autonomy = less friction, higher blast radius when the agent is wrong -- independent of how capable the underlying model is.

Low-risk actions (read, draft, search) execute automatically; anything destructive or hard-to-reverse (delete, deploy, pay) still needs sign-off.

More autonomy means less human-in-the-loop friction but higher blast radius when the agent is wrong — a coding agent that can read files is lower-risk than one that can also run rm -rf or push to production, independent of how capable its underlying model is. Scoping what an agent is allowed to do is as much a design decision as how it reasons.

How This Section Fits Together

Click a stage for what it covers and how it builds on the one before it.

The loop, tool-calling mechanics, and memory -- the mechanical building blocks.

Start with Agent Fundamentals for the tool-calling and memory mechanics, move to Agent Architectures for how to structure the reasoning loop, then MCP and A2A for the protocols standardizing connections, and Multi-Agent Systems for what changes once more than one agent is coordinating. See the roadmap for the full ordered path through this section.