The patterns
behind every agent.

A plain language model does one thing: you give it text, it gives you text back. An agent wraps that model in a loop and hands it tools. Now, instead of answering in one shot, the model can reason about a goal, take an action in the world, look at what came back, and decide what to do next — over and over, until the job is done.

That shift — from "answer" to "act, observe, adjust" — is the whole idea. Everything in this handbook is a pattern for structuring that loop: how the model decides what to do (ReAct, plan-and-execute), how it acts (tool calling), how it remembers (memory), how many models cooperate (multi-agent), and how you stop it going off the rails (failure modes).

The pattern almost every agent runs is ReAct: Reasoning + Acting. The model alternates between thinking about what to do and doing it, feeding each result back into the next thought. Reasoning decides the next action; the action's result grounds the next round of reasoning.

The magic is the synergy: reasoning makes acting smarter — the model plans which tool to call and recovers from dead ends — while acting makes reasoning honest, because every observation is a real fact from the world, so the chain of thought can't quietly drift into fiction. ReAct hallucinates far less than reasoning alone.

An agent is only as capable as the tools it can reach. Tool calling (a.k.a. function calling) is how a model asks your code to do something: you describe each tool with a name, a plain-language description, and a typed argument schema; the model responds with a structured call — the tool name and JSON arguments — instead of prose.

The quality of your tool descriptions matters as much as the model. The model decides which tool to use by reasoning over those descriptions, so vague or overlapping ones cause wrong calls. Good tools are narrow, well-named, clearly documented, and validate their inputs.

Design tool schemas the way you'd design an API — that's exactly what they are. The interactive Tool-Schema Designer lets you draft and pressure-test one.

ReAct decides one step at a time, re-reasoning after every observation. That's flexible but token-heavy, and on long tasks the agent can lose the thread. Plan-and-execute takes the opposite tack: first produce a full plan of steps, then execute them, re-planning only when reality diverges.

These aren't rivals — mature agents combine them: a planner lays out the high-level steps, and each step runs a small ReAct loop to handle the messy details. Choosing where to draw that line is one of the real design decisions in building an agent.

Agents get noticeably better when they check their own work. Reflection adds a step where the model critiques its output — "is this actually correct? did I miss anything?" — and revises before finishing. It's the difference between a first draft and a proofread one.

Common forms: a critic pass that scores or flags the draft, a verifier that re-checks a result against the tools (re-run the query, re-read the source), and retry-with-feedback, where a failed step is fed back in with the error so the model can fix it. Reflection costs extra calls, so reserve it for steps where being wrong is expensive.

Agents have two kinds of memory, and confusing them is a classic bug.

Short-term memory is the context window — powerful but bounded, so as a run grows you must summarize earlier steps to keep the important bits without blowing the budget. Long-term memory is an external store the agent writes to and retrieves from, so knowledge persists beyond one conversation. Retrieving from it is exactly RAG, pointed inward at the agent's own notes.

One agent with fifty tools becomes confused and slow. A cleaner pattern is to route: a lightweight classifier or small agent decides which specialised agent or tool should handle a request, then hands off. Push this further and you get multi-agent orchestration — several agents, each good at one thing, cooperating.

Multi-agent shines when sub-tasks are genuinely different (research vs. writing vs. code) or need isolation (one agent's mistake shouldn't corrupt another's context). But every extra agent adds coordination cost and new failure surfaces, so reach for it only when a single agent is genuinely struggling. The full architecture — message flow, shared state, termination — is covered in Multi-Agent Orchestration.

The single most important guardrail is the step limit — a hard cap on how many loops an agent may run before it must stop or ask for help. After that: validate every tool call against its schema, wrap tools in error handling so a failure becomes an observation rather than a crash, and put a human in the loop for any irreversible or high-stakes action (spending money, deleting data, sending messages).

The two most important guards are just a few lines. A step limit caps the loop; retry with exponential backoff survives a flaky tool without hammering it:

A stuck agent halts at the cap instead of spinning forever; a transient failure recovers on attempt 3 or gives up cleanly. The runnable version below is both guards.