How agents work · AI Agents Field Guide

In Chapter 1 we hit the model's hard limit: it's a stateless function that turns text into more text and nothing else. It can't read a database, run code, or send an email. So how do we get from "autocomplete" to systems that fix codebases and resolve support tickets? We wrap the model in a loop and hand it tools. That's an agent — and by the end of this chapter you'll have stepped through one by hand and seen exactly how a text model "does things."

1 · What actually counts as an "agent"?

The word is thrown around loosely, so let's use the definition the labs use. OpenAI: an agent is a system that uses an LLM to control workflow execution — the model chooses the next step, notices when the task is done, self-corrects, and hands back to a human when stuck. Anthropic frames the same line as workflow vs agent: in a workflow, YOU wrote fixed code paths and the LLM just fills slots; in an agent, the LLM decides its own path and tool use at runtime. The whole distinction reduces to one question: who chooses what happens next — your code, or the model?

That boundary is slippery in practice, so test your intuition — click each system:

Interactive · agent, or not an agent?

The test isn't "does it use an LLM" — plenty of non-agents do. It's "does the LLM control the flow." A scripted FAQ bot and a sentiment classifier don't; a coding assistant that decides which files to read, runs the tests, sees they failed, and tries again does.

2 · The three parts of every agent

Strip any agent down and you find exactly three components. Keep this picture in your head for the rest of the book — every later complication (memory, RAG, guardrails) is an upgrade to one of these three.

An agent = a model that reasons, instructions that shape it, and tools it can call — cycled in a loop.

Tools come in three practical kinds, and you'll design all three: data tools (read a DB, search the web, fetch a file), action tools (send email, issue a refund, open a PR), and orchestration tools (other agents, exposed as callable tools).

3 · The agent loop — step through it yourself

The engine is a loop, often called a run. Each turn the harness assembles context and calls the model; the model returns either a final answer or a tool call; if it's a tool call, your code executes it, appends the result, and loops. It exits on a final answer, an error, or a max-turn cap — Anthropic's shorthand: gather context → act → verify → repeat. Reading that is one thing; watching state accumulate is another. Step through a real run:

Interactive · step through an agent run

Watch the rhythm: the model only ever reasons or emits a tool call — it never runs anything itself. Your harness executes the tool and feeds the observation back. The loop repeats until the model has enough to answer. That control structure is behind every agent in this book.

4 · Tool calling — the exact round-trip

This is the mechanism that lets a text model act, and the model's role is smaller than people think: it only ever emits an intention (structured JSON); your code does the doing. Watch the round-trip, then read the four steps:

Interactive · the tool-call round-trip (watch the packets)

The model sends a JSON tool_call to your harness (amber); your code runs the real function and sends the observation back (cyan). The model never touches the API directly — which is also your security boundary.

You declare tools as JSON Schema.Name + description + typed parameters, in the API's tools field. The description isn't decoration — a vague one misroutes the model.

The model emits a call.When it decides a tool is needed, it interrupts its prose and outputs JSON arguments matching your schema.

Your code executes it.Parse, run the real function, capture the result. The model executes nothing.

You feed the result back.Append a role:"tool" message with the matching tool_call_id; call the model again.

// tool you declare · call the model emits · result you return { "name":"get_weather", "parameters":{ "type":"object", "properties":{ "city":{"type":"string"} }, "required":["city"] } } → { "tool_call_id":"call_01", "name":"get_weather", "arguments":{ "city":"Paris" } } ← { "role":"tool", "tool_call_id":"call_01", "content":{ "temp_c":14, "condition":"light rain" } }

Structured outputs — guarantee the JSON is valid

By default, tool arguments are best-effort: the model usually produces valid JSON, but "usually" breaks pipelines. Strict mode constrains generation to your schema so the output is always valid. Flip it and see:

Interactive · strict mode on/off

strict mode

Off: the model occasionally emits malformed or extra fields, so you must validate and re-prompt (a lossy feedback loop). On: generation is constrained to the schema — valid every time. Use strict whenever the output feeds another system.

5 · Design the tool interface like a product (ACI)

The model operates your system blind, through a keyhole of text. So the Agent–Computer Interface deserves as much care as a human UI: tools should be self-describing, hard to misuse, and fail loudly. This is error-proofing ("poka-yoke") — shape the signature so a mistake is nearly impossible. The same capability, designed two ways:

✗ easy to misuse

refund(amount, reason)
// amount: free string ("50", "$50", "fifty?")
// reason: free text
// no currency, no limit, no enum

✓ error-proofed

issue_refund(
  order_id: string,
  amount_cents: integer,   // one unit
  reason: enum[ "damaged",
    "late", "wrong_item" ])

The right column removes whole classes of model error: no ambiguous currency, no invented reasons, no unbounded amount. In practice, tightening tool schemas buys more reliability than any amount of prompt-tweaking.

6 · Start with one agent

A single model in a loop with well-designed tools solves a surprising share of real problems. Reach for multiple agents only when specialization removes a genuine bottleneck — because more agents is distributed-systems complexity, not maturity.

Keep this number in mind

Anthropic's multi-agent setups beat a single agent on hard research tasks — but burn roughly 15× the tokens of a normal chat. Split work only to (1) protect context, (2) parallelize a wide search, or (3) use genuinely different tools/expertise. We'll build multi-agent systems properly in Chapter 4.

Recap

An agent = model + tools + instructions, run in a loop the model controls (that's the agent-vs-not test).
The model only reasons or emits tool calls; your harness executes and returns observations.
Declare tools as JSON Schema; use strict mode; design the interface to be error-proof.
Start single-agent — multi-agent costs ~15× tokens.

Carry into Chapter 3

You have the loop. Next: what happens inside each turn — the reasoning patterns (CoT, ReAct, Reflection, Tree-of-Thoughts) that decide how well the agent plans, acts, and recovers.