11  Can it do the whole job?

A chatbot answers your question. An agent does your job. That difference (small in words, enormous in blast radius) is what this chapter is about.

11.1 From answering to acting

The core systems examined so far have been responders. You asked; it answered. A classifier sorted a row. A RAG chatbot pulled a paragraph. A sentiment model labelled a ticket. In every case the human decided what to do with the output. The model produced text; you produced action. That separation is one safeguard; source integrity, data permissions, and evaluation also matter.

An agent erases the line. An agent is a model wired to tools and a loop, and the loop is the whole difference between “answer my question” and “do this job.” The model may be the same as in a chat application. What changes is the harness around it. Instead of answering once, the harness lets the model run a cycle:

1. Plan: break the task into steps.
2. Act: call a tool: read a file, search a folder, run a calculation.
3. Observe: read the tool’s result back into its own context.
4. Repeat or stop: until the task is done, or until something tells it to stop.

An action-taking loop changes what must be checked. A mistaken answer can mislead a reader; a mistaken tool call can also alter records or communicate on someone’s behalf. Do not infer that a public chatbot failure involved an autonomous tool loop unless the evidence establishes that architecture. Here we will use a constructed support workflow whose permissions are explicit.

This chapter specifies a small workflow and its checks. The core route is a paper design; an executable agent is an optional extension.

11.2 Tools add an action boundary

A tool call is structured output, not a paragraph. When the model decides to act, it does not reach into your file system. It emits something that looks like a function call (search_docs("churn", region="Metro")) and the harness executes it, handing the result back. The model proposes; the harness disposes.

A read-only search can still expose confidential information, cross an access boundary, or return injected content. Its risk depends on the data and permissions. A tool that sends an email, files a support ticket, refunds a payment, or closes an account is high risk, because those actions touch people, money, and records you cannot walk back. You do not control the danger by hoping the model is careful. You control it by controlling which tools the harness exposes, and, just as importantly, by reading every exposed tool as a permission you have granted the loop.

A vendor will tell you their agent is “safe” because the model is aligned. That is persuasion, not proof. Start with the tool list: what, precisely, have you let this loop do? Combine it with the data boundaries, evaluation, action validation, and stop controls; a tool inventory alone is not proof of safety. If you cannot name every action the agent can take, you have not evaluated it.

11.3 MCP: a standard plug for tools

Wiring tools to a model used to be bespoke work: one integration per tool, per model, per harness. Model Context Protocol (MCP) is an open standard that replaces the tower of custom plumbing with one shared interface. The analogy the spec itself uses is apt: MCP is the USB standard, but for AI tools. An MCP client can connect to a compatible server; supported capabilities, versions, permissions, and authentication still need checking. MCP does not itself authorise access or make a tool safe. Official MCP introduction

You will not build an MCP server this chapter, and you do not need to. What you need is to recognise it when a vendor mentions it, because “the agent reached into our CRM” stops being a custom build and becomes a standard pattern the moment MCP is involved. That is convenient. It is also why the tool-list question gets harder, not easier: a standard plug means a standard way to hand the loop a dangerous capability. The convenience and the risk are the same feature.

11.4 Divide the work; specify the runtime

A support digest has at least three jobs: group tickets into themes, retrieve relevant guidance, and draft a brief. You can describe each job in a separate instruction file. That makes the responsibilities reviewable, but the files do not create sub-agents by themselves.

A running implementation needs software to load instructions, make model calls, pass results, enforce permissions, and stop. Some harnesses provide those capabilities; their configuration is product-specific. Do not assume dropping three files into an interface creates a working agent. Anthropic distinguishes fixed workflows from systems in which a model directs its own tool use; either may suit a task. Building effective agents

For this case, begin with a fixed, inspectable sequence. A separate model call for each job is optional. More agents introduce coordination and cost; they are not a learning objective in themselves. Retrieval inside the sequence must return usable evidence, and the reviewer must check that evidence supports the proposed recommendation.

11.5 The danger zone

Now pull up the trust tool you have carried since the introduction. Ask the two questions of an agent’s output, before you act on it:

1. Does it need to be precise, or is average fine?
2. If it is wrong, how big is the blast radius, small or large?

Consequential actions such as sending a customer promise or changing an account need stronger controls than an isolated calculation on synthetic data. Classify the actual action, not every agent under a single risk label.

Errors can propagate: an unsupported retrieval claim can become a recommendation in the next stage. A check must inspect that dependency before the recommendation is authorised. Do not assume every later stage will notice an earlier mistake.

11.6 What “human-in-the-loop” actually means

It is not “a human glances at the end.” That is a rubber stamp wearing a safety vest. Human-in-the-loop is a checkpoint you design into the workflow so that a human makes the load-bearing decision at the load-bearing moment. Four possible patterns, whose safety depends on implementation:

1. Approval gate. The agent drafts; a human approves before any action fires. The reviewer still needs suitable evidence and time.
2. Review checkpoint. The agent runs freely within a sandbox, but must stop and surface its work at a defined point for human review.
3. Confidence threshold. The agent acts on its own when its confidence is high; escalates to a human when it is not. Requires a validated uncertainty signal; a model’s self-reported confidence alone is insufficient. Do not use this as the only safeguard.
4. Dry-run then execute. The agent produces a plan of actions; a human reviews the plan; only then does execution proceed.

The skill is not picking the most autonomous pattern. The skill is matching the pattern to the blast radius, and, harder, placing the checkpoint at the right step. The wrong place is “at the very end, after everything is done.” Ask:

At which step does the output become load-bearing or irreversible?

Put the checkpoint just before that step. Earlier steps still need access controls and proportionate checking. Everything after it carries a human’s decision forward, and you can defend why you put it there, and not one step later.

11.7 A constructed failure and correction

Tessera wants a support digest: group new tickets, retrieve relevant guidance, and draft a brief. The following is a teaching scenario, not a log from an executed system.

The retrieval stage returns a plausible statement about congestion without a supporting passage. The drafter turns it into a recommendation to change a route. Reading only the final brief hides the gap.

Place a source check between retrieval and drafting, then check the final recommendation again before distribution. A real citation is not enough: the cited passage must support the action, and an authorised person must approve it. A runbook saying “check telemetry” does not confirm congestion.

Keep a record of what was retrieved, what was inferred, and what remains untested. A system may be grounded in supplied context without a retrieval call; when evaluating automated retrieval specifically, inspect whether that call occurred and what it returned. Do not infer a mechanism from fluent prose.

11.8 Core: trace the action boundary on paper

Time: 25 minutes. Inputs: these invented records:

• Ticket T1: “Premium route latency rises each evening.”
• Ticket T2: “The same route slows after 18:00.”
• Runbook R1: “Check service telemetry before recommending a route change.”
• Draft brief: “The runbook confirms congestion. Change the route immediately.”

Draw the sequence: group tickets, retrieve guidance, propose a recommendation, review, and distribute. Mark the inputs, outputs, allowed tools, and stop condition at each step. Identify where the draft exceeds the source: R1 requires a check; it does not confirm a diagnosis or authorise a change.

Artefact: an action/checkpoint map and a corrected brief in the dossier. Success: require telemetry evidence before a diagnosis, source support before a recommendation, and approval before distribution or operational change. State what happens when a source or reviewer is unavailable.

Optional implementation: reproduce the sequence in a disposable, approved sandbox with synthetic files, no live customer integrations, and no send or write permissions. Log whether retrieval actually occurred. Document the required runtime configuration rather than assuming an interface recognises a “skills folder.” Do not remove the checkpoint to test against real people or systems.

11.9 Where this leaves you

State, before you switch the loop on, every action the agent can take. Name which steps are red-quadrant. Place a checkpoint just before the output becomes load-bearing or irreversible, and be able to defend why there, and not one step later. Treat an agent that could retrieve but didn’t as identical to one that confabulated, because to the reader they are.

Your design should now say what may run, what requires review, and what is still untested. It does not yet establish the speed, cost, or reliability of an implemented system.

The final chapter brings the component tests, model comparison, and action boundaries together. Your capstone must explain not only whether a workflow meets its brief, but who gains, who carries the transition cost, and who can stop it. Keep unresolved evidence visible; a persuasive pitch cannot fill the gaps.

11.10 🔍 Go deeper

• Building Effective Agents: Anthropic, https://www.anthropic.com/engineering/building-effective-agents. A practitioner primer on the agent loop and tool use, including when an agent is overkill and a simple prompt will do. Read it for the discipline of reaching for the loop only when simpler solutions fall short, and for Anthropic’s three principles: keep the design simple, make the planning transparent, and craft the agent-computer interface as carefully as you’d craft a user interface.

• How we built our multi-agent research system: Anthropic Engineering, June 2025. In that team’s data, agents used about 4× the tokens of chat interactions and multi-agent systems about 15× chat, not 15× a single agent. Treat this as a reported result for their workload, not a universal multiplier. The article also describes source-based evaluation and the coordination work behind a running system.

• Model Context Protocol: Introduction: https://modelcontextprotocol.io/docs/getting-started/intro. The official MCP documentation, which itself uses the USB analogy. Read it to demystify the standard: tools, resources, and prompts are the three primitives, and “the agent reached into our CRM” is a vendor phrase you should now be able to translate into a concrete, auditable tool call.

11.11 🗣️ Take it to the AI

Where to start. Three questions worth arguing about rather than looking up:

1. Ask the AI to list every action an agent you describe can take. If neither of you can enumerate the tool list, the agent has not been evaluated, whatever the vendor says.
2. Ask where the checkpoint goes and, harder, why there and not one step later. The justification is the deliverable, not the placement.
3. Ask how you would tell an agent that retrieved from one that only appeared to. To the reader of the finished prose they look identical, which is the whole problem.

Keywords to steer with. agent loop · plan, act, observe, repeat · tool call as structured output · Model Context Protocol · skills folder · sub-agent · read-only versus write tools · compounding drift · approval gate · review checkpoint · confidence threshold · dry-run then execute

A starting prompt (RTCF).

Role: You are a safety reviewer who signs off on agent deployments and has refused several.

Task: Take the agent I describe, tell me at which step its output becomes load-bearing or irreversible, then place the checkpoint and defend the placement.

Context: I have read a chapter arguing that tool permissions create action risks and errors can propagate across steps. The agent does [describe the steps in order]. The tools it can call are [list them honestly, including the read-only ones]. The output goes to [say who acts on it].

Format: The loop step by step with a risk note on each. Then the checkpoint, with a paragraph defending why there rather than one step later. End with the one tool you would remove entirely, and what capability that costs.