CHAPTER 31
Agents, Tool Use and MCP
LLMs that plan, call tools, remember and act, and how to make them reliable
Source: PDF pp. 83–85
Core PDF content
PDF page 83Workflows vs agents p. 83
An agent is an LLM running in a loop: it decides the next step, calls tools, observes the result, and repeats until the goal is met. A workflow is a predefined sequence of LLM calls and code. Agents handle open-ended problems but are slower, costlier and less predictable, so use the simplest thing that works:
| Level | Pattern | Use when |
|---|---|---|
| 0 | Single LLM call (+ retrieval and good examples) | Most tasks: classification, extraction, drafting, Q&A |
| 1 | Prompt chaining: fixed steps, each output feeds the next (with checks between) | Task decomposes cleanly (outline, then draft, then translate) |
| 1 | Routing: classify the input and send it to a specialised prompt/model/tool | Distinct categories needing different handling |
| 1 | Parallelisation: run subtasks or multiple attempts concurrently and aggregate (sectioning, voting) | Independent subtasks, or need higher confidence |
| 2 | Orchestrator-workers: a lead LLM plans and delegates to worker LLMs/tools dynamically | Subtasks cannot be known in advance (code changes across files) |
| 2 | Evaluator-optimiser: one LLM generates, another critiques, loop until good | Clear quality criteria and iterative refinement helps |
| 3 | Autonomous agent: open-ended loop with tools and environment feedback | Unpredictable number of steps; needs strong guardrails and evals |
The agent loop
Memory Tools and environment context, notes, vector store
Tools: the interface between the model and the world p. 83
- Mechanics: you describe each tool with a name, description and JSON Schema for arguments. The model emits a structured call; your runtime executes it (the model never runs code itself), returns the result, and the model continues. Models can issue several independent calls in parallel.
- Good tool design is prompt engineering: narrow, unambiguous purpose; descriptive names and parameter docs with examples; consistent formats; return concise, relevant data (paginate or filter large outputs); error messages that tell the model how to fix the call; idempotent operations; separate read tools from write tools.
- Too many tools hurt selection accuracy and cost context. Group related tools, load tool definitions on demand (tool search), or route to specialised sub-agents.
- Code execution (Python sandbox) is a universal tool for calculation, data analysis and file manipulation; run it in an isolated, resource-limited container with no ambient credentials.
- Computer / browser use lets agents operate GUIs when no API exists: slower and more fragile; always sandbox and gate sensitive actions.
Model Context Protocol (MCP) p. 84
MCP is an open protocol for connecting AI applications to tools and data. Before it, each application needed a custom integration for every system (M x N). With MCP, a system exposes one MCP server and any MCP-aware host can use it (M + N).
Transports: stdio (local process) or Streamable HTTP (remote, with OAuth). Server primitives: tools, resources, prompts.
- Primitives: tools (actions the model can invoke), resources (data the application can read), prompts (reusable templates). Clients can also offer sampling (server asks the host's model to complete text) and roots (filesystem scope).
- Security is the main risk: a malicious or compromised server can poison tool descriptions or outputs (prompt injection), request excessive scopes, or exfiltrate data. Use vetted servers, OAuth with least-privilege scopes, per-tool user consent for sensitive actions, sandboxing, and audit logs.
Planning, memory and context engineering p. 84
- Reasoning patterns: ReAct (interleave reasoning and acting), plan-then-execute (write a plan, then run steps and re-plan on failure), reflection (critique and retry), search over alternatives (tree/graph of thoughts), and verification steps (run tests, check constraints).
- Memory types: working (the context window), episodic (summaries of past sessions), semantic (facts and preferences in a database/vector store), procedural (instructions, skills, playbooks the agent can load).
- Context engineering is the main lever for agent quality: keep the context small and relevant. Techniques: summarise or compact old turns; store notes in files/state outside the window and retrieve on demand; pass sub-agents only what they need; trim tool outputs; use prompt caching for the stable prefix (system prompt, tool definitions); load detailed instructions just-in-time.
- Multi-agent systems: a supervisor delegates to specialised sub-agents (research, coding, review) that run in parallel with isolated contexts and report back condensed results. They help with breadth-heavy tasks and context isolation, but can consume several times more tokens and add coordination failures; use them only when a single agent with good tools is not enough.
PDF page 85Making agents reliable and safe p. 85
| Concern | Practice |
|---|---|
| Bounded behaviour | Step, time and cost budgets; loop and repeated-call detection; fail to a human rather than spin |
| Least privilege | Scoped credentials per task; read-only by default; separate identities for agent actions; allow-lists of tools and domains |
| Human-in-the-loop | Approval for irreversible or high-impact actions (payments, deletes, external messages); show a plan and diff before applying |
| Idempotency and recovery | Make tool calls idempotent, persist state after each step, support resume; use durable workflow engines (Temporal, LangGraph checkpoints) for long tasks |
| Prompt injection | Treat all tool and retrieved content as untrusted data, not instructions; privilege separation (the component that reads untrusted content cannot also take sensitive actions); confirm before acting on instructions found in data |
| Observability | Trace every step (prompt, tool call, result, tokens, latency); replay failures; sample for human review |
| Evaluation | Task-success rate on a scenario suite, trajectory checks (right tools, no unnecessary calls), cost per task, stability across runs (pass^k), adversarial and safety scenarios |
Review questions for this chapter have not been written and reviewed yet. The chapter text above is the full source content.
Try it
References
System Design & AI System Design: The Complete Guide — 2026 Edition, pp. 83–85; figures 57, 58.
Tip: use ← and → keys to move between chapters.