Building Agentic AI Systems:
From First Agent to MCP, Multi-Agent Orchestration, and Production

• The terminal runs commands;./course.sh runs them inside the course container.
• Dictionaries, lists, functions and try/except are the Python this book relies on.
• JSON is how programs exchange data; JSON Schema describes what valid JSON looks like.
• Web APIs return a status code and (usually) JSON; 4xx means fix your request, 5xx means retry.
• Secrets live in environment variables, never in code.

Sections: The terminal and the course kit · Python in one file · JSON and JSON Schema · Web APIs and HTTP · Secrets and environment variables · Docker in five minutes

• Comprehensions build lists and dictionaries in one line.
• fn(**args) calls a function with a dictionary of arguments: this is how tools are called.
• Functions are values: store them in dictionaries and pass them around.
• Classes bundle data with the functions that use it; dataclasses are classes for data.
• Decorators wrap or register functions.

Sections: Six features, one file · The one pattern to understand deeply

• An LLM call sends messages and returns one message with content blocks, token usage and a stop reason.
• LLMs don't know the present, can't be trusted with exact math and can't see private data.
• A workflow follows steps you wrote. An agent chooses its own steps. Autonomy has a cost, so choose the least autonomous option that does the job.
• "Agentic" is a spectrum; describe systems by their dimensions: autonomy, state, planning, tool use, environment, persistence, feedback, delegation and adaptation.
• Every agent has four parts: model, tools, loop and stop condition.
• The model only asks for actions; your code performs them.
• The reference model's layers (user/API, runtime, planning, memory, context, tools, policies, model, MCP/APIs/A2A, environment, evaluation and observability) organize the whole book.
• The model knows only what's in its context, so choosing that context is a core skill; the harness around the model decides what's allowed.

Sections: Anatomy of an LLM call · Where plain LLMs fail · Do you actually need an agent? · What makes a system agentic? · The four parts of an agent · A fixed workflow, for contrast · The agent architecture reference model · The route, and one agent to follow through it

• A test is a function named test_* that asserts; pytest finds and runs it.
• parametrize, pytest.raises, tmp_path and monkeypatch cover almost every test in this book.
• Test the model-free parts directly; replace the model with a scripted stand-in to test the loop.
• Good tests check one behavior, cover the edges and run fast.

Sections: A test is a function that asserts · The five patterns you'll use · Good tests

• A tool is a function plus a name, a description and a JSON Schema.
• The model asks for a tool with a tool_use block. Your code runs it and replies with a tool_result that has the matching ID.
• The description is the model's only guide, so write it carefully.
• Treat every tool input as untrusted; never eval it.
• Return errors as data with is_error: true so the model can recover.

Sections: What a tool is · Your first tool: today's date · A second tool, made safe: a calculator · The round-trip, step by step · Writing descriptions that work · Errors are data

• A registry maps names to functions; TOOLS describes them to the model.
• The model picks tools by reasoning over descriptions, so overlap and vagueness cause misroutes.
• tool_choice can require a tool, forbid tools or force a specific one.
• A routing eval turns "it seems better" into a number.
• Validate arguments in the schema and in code, and write error messages that explain the fix.
• With many tools, defer most of them and let the model find what it needs with tool search.

Sections: A tool registry · How the model chooses · Controlling the choice with tool_choice · Measuring routing accuracy · Validating arguments · When you have dozens of tools: tool search

• The agent loop repeats: call model → run tools → send results, until the model stops asking.
• Return a result for every tool_use block in a response.
• Always cap iterations; add budgets and no-progress checks later.
• Trace every step. The trace, not the final answer, shows you what went wrong. Appendix B has a step-by-step debugging playbook for when an agent misbehaves.
• History is resent on every call, so input tokens grow quickly; keep tool outputs small.

Sections: From two calls to a loop · Walking through one run · Several tool calls in one turn · Stop conditions · Tracing: see what your agent does · Why history grows, and what it costs · A multi-turn chat with the agent · Thinking and effort · Budgets for a whole task

• History lasts one session. Persistent state lives outside the model and is changed only by tools.
• Use exact identifiers (IDs) for anything a tool changes, and give the model a way to look them up.
• Make state-changing tools idempotent, because agents repeat calls.
• When a request is ambiguous, the right answer is a question.
• Choose storage by scale and concurrency: JSON, then SQLite, then a database.

Sections: Two kinds of memory · The to-do tools · Idempotent tools · Ambiguity: ask, don't guess · Choosing a storage backend · What the agent should (and shouldn't) remember

• A pattern is built from a few pieces: literals, \d \w \s, sets, repetition, anchors and groups.
• search finds, findall extracts, sub replaces and match checks the start.
• Write patterns as raw strings (r"...").
• Use regex to find and extract text, never as a security check.

Sections: The pieces · The four functions

• Agentic search is list → search → read, with the model choosing each step.
• Resolve paths, then check they're inside the sandbox.
• Page large outputs and cap search hits.
• Require citations; they make answers checkable and evaluable.
• Use agentic search for exact, fresh, modest-size data, and RAG for fuzzy meaning at large scale, or both.

Sections: Agentic search · The notes tools · The sandbox · Protecting the context window · Citations · Agentic search or RAG?

• Wrap external APIs in tools with timeouts, retries with backoff, and clear failure messages.
• Retry timeouts, 429 and 5xx; fail fast on other 4xx.
• Return all candidates for ambiguous inputs and let the model ask the user.
• Cache responses that don't change quickly; measure hits and calls.
• Budget external calls per run, and tell the model what to do when the budget runs out.

Sections: Choosing an API for learning · The weather tools · What can go wrong with an API call · Ambiguity: ask the user · Caching · Budgets for external calls

• SELECT … FROM … WHERE picks and filters; ORDER BY and LIMIT sort and trim.
• Aggregates with GROUP BY summarize; JOIN combines tables on matching ids.
• Parameters prevent SQL injection; CTEs make long queries readable.
• Check someone else's SQL from FROM and JOIN through to ORDER BY.

Sections: Eight queries, each building on the last · Reading someone else's SQL

• A text-to-SQL agent needs only get_schema and run_query; the model does the rest.
• Enforce read-only access at the connection or user level, not in the prompt.
• Exact error messages turn failures into self-correction.
• Cap result sizes and tell the model when you truncate.
• Evaluate against known answers, because a confident answer can still be wrong.

Sections: A sample database · The SQL tools · Safety in layers · Error-driven self-correction · Keeping results small · Checking answers

• Rate every tool by reversibility and impact; don't give agents the most dangerous ones.
• Separate read-only planning from acting, and bind approval to a stored plan ID.
• Enforce approval gates in code; tell the model what to do when an action is declined.
• Log every change so you can undo and explain it.
• Use reviewed policies to auto-approve low-risk actions.

Sections: Rate actions by risk · Plan, then act · The gate lives in code · Audit log and undo · Never overwrite · Auto-approval policies

• Feedback loops replace "the model thinks it's done" with an objective signal.
• Protect the signal: agents must not be able to edit the tests.
• Run generated code with timeouts, and in isolation for anything real.
• Stop on budget and on lack of progress, not only on an iteration cap.
• Deliver changes as a diff for human review.

Sections: Why feedback loops work · A project with bugs · The fixer agent · Guardrails for code-changing agents · Stop conditions: budget and progress · Review by diff

• Async lets one program overlap many waits: for the model, APIs and servers.
• async def defines, await waits, asyncio.run starts and gather runs things at the same time.
• to_thread keeps blocking code from freezing everything; async with opens what must be closed.
• Always await a coroutine, and never call blocking functions inside async code.

Sections: Waiting without blocking · The five ideas · Reading async agent code

• Orchestrator–worker: a lead plans, subagents work in parallel with clean contexts and the lead synthesizes.
• Use a forced tool call to get a structured plan.
• Run subagents concurrently with asyncio, and run blocking tools in threads.
• Subagents should return short, cited findings.
• Multi-agent systems are more powerful for broad tasks and much more expensive; measure before choosing.
• Beyond orchestrator–worker: routers, handoffs, evaluator–optimizer loops and voting each fit a different job.
• Contracts, contained failures, least privilege and one trace id keep a team of agents under control; A2A connects agents across organizations.

Sections: Why more than one agent? · The research team · How it works · Writing good subtasks · Cost and when not to use it · Four more patterns · Keeping a team of agents safe and debuggable

• MCP packages tools once so any compatible host can use them.
• Hosts run models; each host has one client per server; servers offer tools, resources and prompts.
• The Python SDK builds tool schemas from type hints and docstrings.
• Log to stderr in stdio servers, and test with Inspector before involving a model.
• Use stdio for local servers and Streamable HTTP for shared or remote ones.

Sections: The problem MCP solves · Hosts, clients and servers · What a server offers · Your first server · Testing with MCP Inspector · Connecting to Claude Desktop · Transports: stdio and Streamable HTTP · Other MCP features you'll meet

• An MCP host lists tools from each server and gives them to the model; the loop itself doesn't change.
• Namespace tool names by server to avoid collisions and help the model.
• Route each call to its server with call_tool, and pass is_error through.
• Keep connections open for the session with AsyncExitStack.
• Use resources for reference data and prompts for user-selected templates.
• Wrap a whole agent as an MCP tool to delegate across teams; it keeps its own limits and reports failures as errors.

Sections: What changes in the loop · Two more servers · The MCP host · Connection lifecycle · Reading resources and prompts · Agents as MCP servers

• Reference and vendor servers give agents large capabilities with a line of config.
• Every server runs with your permissions; check who publishes it and narrow what it can do.
• Anyone who writes content your agent reads can attempt prompt injection.
• Defend in layers: remove capabilities, require approvals in code, hide unneeded tools, then prompt, then log.
• A policy layer between model and servers enforces allow-lists, approvals and auditing.
• The policy layer also limits where data can go; Chapter 25 explains why that matters as much as guarding writes.

Sections: Reference servers · One config for all of them · Trusting a server · Prompt injection through tool output · A policy layer

• The 2026-07-28 specification made MCP stateless: each request carries its version and capabilities, so any server copy can answer; server/discover is optional.
• HTTP requests repeat the method and tool name in headers for gateways; servers reject requests whose headers and body disagree.
• Lists carry ttlMs and cacheScope; clients cache them, which saves a request on nearly every model call.
• Long-running work returns a job handle at once, runs durably and is safe to retry; the Tasks extension standardizes the same shape.
• A gateway gives one place to allow-list tools, check agent tokens, rate-limit, cache and audit, and can offer tools through search.
• Registries verify publishers, not code: pin versions, watch tool definitions and keep your own allow-list.
• Company authorization is moving to issuer validation, client metadata documents and enterprise-managed authorization; agent identity is next on the roadmap.
• Optional features now live in extensions; sampling, roots, protocol logging and HTTP+SSE are deprecated with at least a year's notice.

Sections: From tool calling to infrastructure · The protocol on the wire · Discovery and caching · Long-running work · Gateways: one front door · Registries and the supply chain · Authorization for companies · Extensions and the road ahead

• Context engineering asks what information the agent needs on each step, in what form, from which source; prompts are only one part of it.
• Assemble context per call from routed sources, by priority, within a budget, and keep a report of what was left out.
• Give every item a time to live and a provenance label; refresh stale items and resolve conflicts by age and authority.
• Trim old tool results, compact older turns, keep notes outside the context, and cut only at safe points.
• Order context from stable to volatile and cache the stable prefix; cache reads cost a tenth of normal input.
• Give subagents a small brief and take back a condensed answer; never share raw tool output between agents.
• Programmatic tool calling keeps bulky intermediate results out of the context entirely.

Sections: From prompt engineering to context engineering · What fills the context, and measuring it · Assembling context for each step · Freshness and provenance · Trimming old tool results · Compacting with a summary · Prompt caching · Letting the API manage context · Isolating context between agents · System prompts and tool sets as design · Keeping big results out of context: programmatic tool calling

• Working, episodic, semantic and procedural memory need different lifetimes, stores and levels of scrutiny.
• A memory policy gives each memory a kind, subject, scope, owner, source, confidence and expiry, and your code enforces it.
• Recall ranks by match, recency, confidence and kind, and returns only what fits the budget.
• Supersede by subject, expire on schedule, consolidate episodes and forget on request.
• Scope memories to a user, an agent or a team, and restrict who may write shared memory.
• Defend against memory poisoning with a write gate, provenance, "memory is data" and least-privilege writes.

Sections: Why memory is architecture · Four kinds of memory · A first long-term memory · A memory policy · Recall by relevance · Forgetting and staleness · Who owns a memory: scopes and sharing · Memory poisoning · Where memories live

• RAG = chunk, embed, index, retrieve, then answer with citations.
• Embeddings capture meaning; BM25 captures exact words; hybrid ranking gets both.
• Retrieval works best as a tool the agent can call repeatedly.
• Measure retrieval with recall@k and MRR before tuning anything else.
• Agentic retrieval plans information needs, chooses a source for each, judges the evidence and searches again when it's thin.
• Verify answers in code: citations must point at retrieved evidence, and numbers must appear in it.

Sections: The pipeline · Chunking · Embeddings · Keyword search and hybrid ranking · Retrieval as a tool · Measuring retrieval · Going further · From RAG to agentic retrieval · Choosing a source · Is the evidence enough? · Verifying the answer

• Long-running work follows goal, plan, execute, checkpoint, recover, continue, verify, deliver.
• A job is data: each step's status and result are saved before the next step starts, including model outputs.
• Retry transient failures with backoff and a limit; raise permanent errors immediately; timelimit steps and jobs.
• Give every side effect a stable idempotency key, or escalate when its outcome is unknown.
• Leases let another worker finish a dead worker's job.
• Escalate to a person when the runner shouldn't guess, and compensate finished steps, newest first, when a job is abandoned.
• For open-ended work, keep a checklist with checks in code and a progress file, and do one verified item at a time.

Sections: From prompt → answer to goal → deliver · What breaks when work takes hours · Checkpoints: a job is data · Retries, timeouts and errors you mustn't retry · Idempotency: doing it twice must be safe · Leases and task queues · Escalation and compensation · Open-ended work: a harness across sessions · Durable execution in production

• Decide step by step for short tasks; plan first for long ones, and replan when reality disagrees.
• Get plans as structured data: steps, tools, dependencies and a done condition.
• Check plans in code before running them: size, known tools, valid dependencies, no cycles.
• Execute each step with its own brief, tools and done condition; keep finished results when replanning.
• A checked plan can become a durable job (Chapter 19).
• Route between models and effort levels with rules, a classifier or a cascade.
• Compare routers by cost per successful task, measured on real checks.

Sections: Step by step, or plan first? · A plan is data · Check the plan before running it · Execute: one step, one brief · Replanning · Plans and long-running jobs · Model routing · Three routers · Measure cost per successful task

• Choose a topology deliberately; a supervisor with limited depth is the usual start.
• Contracts define what agents hand each other, and code validates them.
• A shared board records the team's work; only the orchestrator writes it, and it enforces depth, task, duplicate and budget limits.
• Specialists get briefs, not histories: smaller, safer and testable.
• Contain failures as error results the lead can handle, and label results as data from another agent.
• Resolve disagreements with independent verification, evidence, code and people.
• A2A connects agents across teams and companies through agent cards and tasks; MCP inside your system, A2A at its boundary.

Sections: Topologies · Contracts between agents · A shared board and hard limits · Briefs, not histories · How teams fail, and containment · Resolving disagreement · Agents across boundaries: A2A · MCP or A2A? · When not to build a team

• Give the model what needs judgment: understanding text, drafting, planning. Give code what must be right every time.
• Put model calls inside a deterministic shell: states and transitions in code, with one method that moves a case and logs why.
• Treat model outputs as proposals, and check them against the input, the records, the user's identity and the policy.
• Keep rules as data, and take every number from records.
• Guard model outputs before they reach people, with a fallback that's always correct.
• Log every transition; wait for people without holding resources.
• Unit-test the deterministic parts; evaluate the probabilistic parts.

Sections: Two kinds of work · A deterministic shell with model steps · States and transitions in code · Model outputs are proposals · Rules as data, numbers from records · Guard what the model says · Approvals and the audit trail · Where to draw the line

• Use a computer-use agent when there's no API; use the API when there is.
• Show the model the page as text with numbered controls; keep screenshots as evidence for people, or use them when there's no page structure.
• The harness signs in, keeps the browser on an allowlist, holds dangerous clicks for approval, limits and logs actions and never lets the agent type passwords.
• Read, act, read again; verify important results in code.
• Page text is untrusted input. The strongest defense is an account that can only do what the task needs.
• Make it reliable with waits, fresh references, timeouts, an isolated browser and durable steps for long queues.

Sections: When to use the screen · How an agent sees a screen · The harness · Acting and checking · Controls that don't depend on the model · Injection through the screen · Making it reliable · Desktop computer use

• Frameworks package the loop, tool schemas, limits, approvals and memory you built by hand.
• The tool runner is the lightest step: your Chapter 4 loop in one call.
• The Claude Agent SDK is a full agent runtime; isolate it and gate tools with can_use_tool.
• A skill is reviewed procedural memory; test that it improves results, with checks in code.
• Choose a runtime by where state lives, how controls are enforced, what you can observe, where code runs, and cost.
• LangChain's create_agent is model-agnostic and extensible with middleware.
• Agent Skills package instructions and files that an agent loads only when a task needs them.
• Claude Managed Agents runs the loop and the sandbox for you; custom tools, permission policies and budgets keep you in control.
• The practices matter more than the framework.
• Almost everything in this book works with other model providers: keep model calls behind one function, and rerun your evaluations when you switch.

Sections: The same ideas, different names · The tool runner: your loop, built in · The Claude Agent SDK · LangChain: model-agnostic agents · Build or buy? · Using other model providers · Agent Skills: packaging know-how · Claude Managed Agents: renting the whole runtime · Choosing a runtime · Where the field is going

• An agent's attack surface is its ways in (untrusted text), its ways to act, and what it can reach.
• Threat-model with four questions, and break the lethal trifecta wherever you find it.
• Prompt injection comes directly, indirectly, stored in memory, relayed by agents, in tool descriptions and hidden in content. Prompts reduce it; code and architecture stop it.
• Allow-list outbound sites, ask before sending anything after private data was read and refuse private addresses.
• Separate reading from acting: a quarantined reader with no tools and a schema, a planner that never sees untrusted text.
• Guard actions, not intentions: canaries, leak scans and egress checks work when the model is fooled.
• Treat model output as untrusted input to whatever comes next, including the screen.
• Red-team with a model that obeys attackers, keep the suite in CI and check your agents against the OWASP agentic list.

Sections: The attack surface of an agent · Threat-modeling an agent · Prompt injection, in all its forms · Data leaving: exfiltration and SSRF · Designs that defeat injection · Guards that don't trust the model · Model output is untrusted too · Red teaming and monitoring · Checking your agent against industry lists

• Every action has a user, an agent and a service; record all three.
• Agents get their own identities and short-lived tokens, never a person's credentials.
• Tokens carry the agent, the user, an audience, scopes, limits, an expiry and an id; a registry caps what each agent may ever hold.
• The tool verifies the token, the resource's owner, the scope and the limits on every call, and logs the decision.
• Derived tokens can only narrow; revoking a token revokes everything derived from it.
• Risky actions need a step-up token: minted after a person approves, for one action, one amount, once.
• Keep revocation, an agent kill switch and key rotation ready; use OAuth, token exchange and your identity provider in production.

Sections: Who is acting? · Never lend an agent your password · Tokens that say what's allowed · Checking at the tool · Narrower tokens for sub-agents · Step-up for risky actions · Audit, revocation and the kill switch · In production

• Evaluation suites turn "seems better" into pass rates; grow them from real failures.
• Run cases several times and read pass rates with confidence intervals, pass^k and flaky cases.
• Calibrate model judges against human labels before trusting them.
• Grade every run on outcome, process and cost.
• Trajectory checks cover tools, order, arguments, efficiency, repeated failures and recovery.
• Score each run on ten dimensions: task success, trajectory, tools, arguments, safety, cost, latency, reliability, groundedness and escalation. Each automatic check is a proxy with blind spots, and the dimensions cover for each other.
• A scorecard per release shows success, pass^k, accuracy, completion, safety, steps, latency and cost side by side, and uses the same definitions as your production SLOs.
• Gate CI on a statistical comparison with the baseline, plus fixed limits for what has no slack, such as safety.
• Evaluate continuously in production: sample, grade, watch for drift and turn failures into test cases.

Sections: From demo to production · Evaluation suites · Outcome, process and cost · Checking the trajectory · Ten dimensions of agent quality · The agent scorecard · A regression gate for CI · Continuous evaluation

• Agent observability follows the chain from goal to context, decision, tool, result and outcome.
• OpenTelemetry spans with the GenAI conventions record model and tool calls without changing the agent; structured logs join them through the trace_id.
• Keep secrets out and redact personal data; prefer references to copies; retain on purpose.
• Summarize runs into tokens, cost, latency and per-tool error rates; record error.type so a tool error, a denied authorization and a blocked action reach different owners.
• Break latency into model, tool and "other", and read a run's trajectory as a timeline.
• Classify failures with a fixed taxonomy; five of the 12 classes need evals and one needs a memory audit, because traces can't see them.
• Public incidents map to the same classes and to controls from earlier chapters: grounding, business rules in code, approval gates, isolation of untrusted text and narrow tokens.
• One page shows the headline numbers, SLOs, failure classes and tools. SLOs measure what users feel, from traces, evals and human review; their error budgets drive burn-rate alerts and release gates.
• Debug from the alert down: SLO, class, runs, span, logs, change, mitigation and a new test case.

Sections: Tracing with OpenTelemetry · Structured agent logs · What never goes into telemetry · Token and cost telemetry · Tool-call telemetry · Latency breakdown · Visualizing a trajectory · The agent failure taxonomy · Production dashboards · SLOs for agents · Alerting · Debugging production agents

• Latency is model + tool + retrieval + orchestration + queueing + serialization; cost per task is model + tools + retrieval + infrastructure + retries + human review. Measure every term from traces, and attack the biggest.
• Each step resends the whole conversation, so cost and latency grow faster than the number of steps; output tokens dominate latency.
• Pull the levers in order of payoff: caching, trimming, routing, effort, fewer steps, parallel tools, batching, streaming.
• Judge every change by cost per successful task on your evaluation suite.
• Enforce budgets in code (per request, per user and per job) and alert on cost per success.
• Sweep concurrency to find the knee: throughput stops rising, queueing takes over latency, the cache hit rate falls and goodput drops as tasks time out. Cap concurrency at the knee and name the limiting resource.
• Load-test open-loop at your forecast rate, measure from arrival and watch p95 and errors.
• Plan capacity with Little's law, the knee and token rate limits, and fail gracefully at the limit.

Sections: The agent performance model · Where the time and money go · The levers · Budgets in code · Performance experiments: finding the knee · Load testing at an arrival rate · Capacity planning

• An agent service needs auth, per-caller rate limits, private sessions, budgets and clean errors.
• Stream progress with Server-Sent Events so long runs feel responsive.
• Remote MCP servers run over Streamable HTTP (MCP's HTTP transport) and must be authenticated.
• Configuration and secrets come from the environment; logs record ids and numbers, not content.
• Deploy a small, non-root image with secrets given at run time, limits on instances and cost and a smoke test against the public HTTPS URL.
• When many teams ship agents, a platform team provides shared gateways, identity, policy, memory, workflow, evaluation, observability and cost controls as paved roads. Standardize identity and secrets first.
• Memory, sessions, private caches and tokens are never shared between tenants; each tenant gets its own keys and budgets.
• The reference architecture (user or API, runtime, model, MCP, APIs and A2A, environment, with evaluation and observability across all layers) places every agent you build.

Sections: The architecture · The agent API · Streaming progress · A remote MCP server · Configuration and containers · Deploying to the cloud · Launch checklist · From one agent to an agent platform · The end-to-end reference architecture

• An agent that answers from the help center with citations, looks up only the signed-in customer's orders and never reveals another customer's data (Chapter 18).
• Starts a return only when the order is inside the return window, checked in code; refunds over a threshold need human approval (Chapters 9 and 22).
• Remembers preferences and open issues under a memory policy: what to keep, for how long and what never to store (Chapter 17).
• Hands off to a human with a written summary when the customer is upset, asks for a person or the agent is unsure. Real-world version: Intercom's Fin.

Sections: Help-center answers with citations · order lookup · returns within policy · memory · human handoff

• An agent that answers data questions over a real multi-table database, shows its SQL and makes charts.
• A read-only SQL MCP server with a business-definitions resource; table selection is confirmed by the user before querying.
• Self-correction with a retry budget; queries are parsed and checked in code (read-only, row limits, allowed tables) and business terms come from the definitions, never the model's guess (Chapter 22).
• Real-world version: Uber's QueryGPT, with separate steps for domain, table selection and column pruning.

Sections: Read-only SQL MCP server · table confirmation · self-correction · deterministic guards · charts

• Collects logs, metrics, recent deployments and runbooks when an alert fires, and posts a first triage summary.
• Flags metric anomalies such as p95 latency or error rate against a baseline; statistics are computed in code, never by the model.
• Investigates logs, metrics and deployments in parallel with subagents, each with a narrow brief (Chapters 16 and 21).
• Suggests runbook steps but never runs a remediation without approval; outputs impact, timeline, suspected cause, evidence and next steps.

Sections: Logs, metrics and deployments in parallel · statistics in code · runbooks · structured summary

• Reviews a pull request through the GitHub MCP server with a read-only, repository-scoped token; write access is a separate, approved step (Chapter 26).
• Runs tests and linters in a container with no network (Chapter 10) and posts a structured review tied to files and lines.
• For failing tests, proposes a fix on a new branch with a long-running harness: progress file, checklist, a commit per step and resume after interruption (Chapter 19).
• Treats PR text and code comments as untrusted input (Chapter 25).

Sections: GitHub MCP server · scoped tokens · tests in a sandbox · structured review · long-running fix harness

• A multi-agent research assistant that plans, researches in parallel, checks its claims and writes a cited brief within a budget.
• The lead produces a structured plan with objectives, boundaries and effort per subtask, and stops at its budget (Chapter 20).
• Every claim is checked against fetched source text; unsupported claims are revised or dropped (Chapter 18). A critic pass adds one revision.
• Real-world version: Anthropic's Research feature, a lead agent delegating to parallel subagents at roughly 15 times the tokens of a chat (Chapter 11).

Sections: Lead planner · parallel subagents · claim verification · critic pass · cited brief within a budget

• Works through a queue of requests in a web application that has no API, in a browser, one at a time, over hours (Chapter 23).
• Processes the queue as a long-running job: checkpoint after each request, resume after a crash, retries with a limit and escalation to a person (Chapter 19).
• Hard rules in code whatever the model decides: credits above a limit need approval, the agent visits only the app's own address and every submission is logged (Chapter 22).
• Signs in as its own service account with only the permissions the queue needs, never a person's password (Chapter 26).

Sections: Browser automation with Playwright · durable request queue · hard rules in code · service-account identity

• Every exercise runs in the course kit's Docker image: Ubuntu 24.04, Python 3.12, Node.js 24, the MCP SDK, MCP Inspector, reference servers, GitHub's server, the Claude Agent SDK, LangChain, FastAPI and a small embedding model.
• You type commands on your own computer; Docker runs them in the container against your workspace folder. On Windows use .\course.cmd wherever the book shows ./course.sh.
• The same Python, libraries, sample data and MCP servers on Windows, macOS and Linux; nothing to install beyond Docker.

Sections: What's in the kit · course.sh commands · the sandbox service

• A symptom → likely cause → fix table for setup errors such as a 401 AuthenticationError (API key not set in this shell) or a NotFoundError for a retired model name.
• A step-by-step debugging playbook for the harder case: the agent runs but does the wrong thing. Start from the trace, not the final answer (Chapter 4).

Sections: Setup errors · the debugging playbook for an agent that does the wrong thing

• All chapters cost roughly $35–75 in API usage, assuming Claude Sonnet 5 at $2 per million input tokens and $10 per million output tokens (2026 prices).
• Part 0 costs under $0.10; the biggest items later are routing evals, tool-search experiments, the 2,000-note scale test and the SQL evaluation harness.
• Chapter 4 shows how to log token counts so you always know what a run cost.

Sections: Cost per part · biggest items

• You don't have to pay for API calls: the course kit runs the open-source qwen3.5:9b model in Docker on your own computer, and the book's code uses it without changes.
• qwen3.5:9b was chosen because it is good at tool calling, which is what agents do, and small enough for an ordinary computer.
• Every exercise is labeled with the model it needs; the appendix lists the ones that still need Claude. LOCAL_MODEL.md in the repository has the same instructions.

Sections: Why qwen3.5:9b · hardware, GPUs and Macs · speed tips · which exercises still need Claude

• The book's frameworks on a few pages, for design reviews and on-call, each pointing to the chapter that explains it.
• Card 1, Do you need an agent?: a function when rules are exact; a workflow when steps are known in advance; a state machine for stages, rules and audits; RAG for answering from documents; a single LLM call when one prompt does the job; an agent only when the steps depend on what you find along the way.
• Also collects the agent architecture reference model, the failure taxonomy, the evaluation scorecard, agent SLOs and the performance model.

Sections: Do you need an agent? · reference model · failure taxonomy · scorecard · SLOs · performance model

• Every concept in the book carries over to other providers and open-source stacks; only the names change.
• A table maps each concept (tool calling, the agent loop, MCP and more) to the Claude API, OpenAI API, Google Gemini API and open-source equivalents, checked in September 2026.
• Section 24.6 shows how to switch providers: keep model calls behind one function and rerun your evaluations when you switch.

Sections: Claude API · OpenAI API · Google Gemini API · open source