Tool Use & Agents

⏱ ~10 min read · 🎧 10 min listen · ✎ 3 quizzes · 🧪 ~90 min lab

Go back to the job posting from Lesson 01. Anthropic's FDE role asks you to "deliver technical artifacts for customers like MCP servers, sub-agents, and agent skills".⁴ This lesson is those deliverables. Tool use is what turns a model that talks into a system that acts — looks up the customer's data, calls their APIs, files the ticket. And the single most important decision you'll make on site, over and over, is deceptively simple: does this problem need an agent at all?

Workflows vs agents: the canonical decision

Anthropic's "Building Effective Agents" — still the standard framing — draws one line through everything: workflows are systems where LLMs and tools are orchestrated through predefined code paths; agents are systems where the LLM dynamically directs its own processes and tool usage.¹ In a workflow, your code decides what happens next. In an agent, the model does — it runs in a loop, calling tools, reading results, deciding the next step. The guidance that follows from it is the part customers least expect to hear: find the simplest solution possible, and only increase complexity when needed.¹ Most "agent" products in production are workflows, and that's a compliment.

So when do you actually build the agent? Four questions, all of which must come back "yes": is the task complex enough that you can't specify the steps in advance? Is it valuable enough to justify the extra tokens and latency? Is the model actually viable at this kind of task? And can errors be caught and recovered — via tests, review, or rollback?¹ A "no" on any of them means you build a workflow, whatever the customer's slide deck says. This is your first AI-judgment rep in the technical stack: an invoice pipeline with five fixed steps sold as "an AI agent" is a routing workflow, and telling the customer so — with the cost and reliability argument — is the job.

Tools are prompts: the design discipline

A tool is three things: a name, a description, and a JSON input schema.⁵ Here's the mental shift that separates working agents from flailing ones: the tool description is prompt engineering. The model decides when and how to call your tool based entirely on what you wrote there. Anthropic's tool-writing guidance reads like advice for onboarding a new hire, because that's exactly what it is: write descriptions that say when to use the tool, not just what it does; consolidate — a few purposeful tools beat a thin wrapper per API endpoint; namespace related tools (clinic_search_slots, not search2); and return meaningful, human-readable context — names and statuses, not bare UUIDs the model can't reason about.²

The loop mechanics are simpler than they sound. You send the model a request with your tool definitions; if it wants a tool, the response comes back with stop_reason: "tool_use" and the arguments; your code executes the tool, appends the result to the conversation, and calls the API again — until the model answers without asking for a tool.⁵ That while-loop is an agent. Everything else — memory, planning, sub-agents — is refinement. You'll write this loop from scratch in today's lab precisely so it never feels like magic again.

MCP: the integration seam

Every tool you write today is welded to your own harness. The Model Context Protocol fixes that: an open standard for connecting AI applications to tools and data sources through one interface — commonly described as USB-C for AI.⁶ For an FDE this is the integration seam: wrap the customer's scheduling system as an MCP server once, and Claude, their IDE assistant, and next year's app can all use it. The spec also bakes in the security posture you'll need on site — user consent, explicit authorization for tool execution.⁷ Today you just need the concept; Lesson 07 has you building MCP servers against messy enterprise systems for real.

The Claude Agent SDK: don't rebuild the harness

Once you've written the raw loop, you'll appreciate what a harness gives you. The Claude Agent SDK packages the production agent loop — built-in file and shell tools, MCP connections, sub-agents, permission hooks, session management — as a library you call with a prompt and options.⁸ The FDE decision pattern: raw API + your own tools when the agent is small and the tool surface is custom (today's lab); the Agent SDK when the customer needs a capable general agent on their infrastructure fast. Knowing both — and which one a given engagement needs — is exactly the "agent development" line on your gap map.

Multi-agent: powerful, expensive, usually premature

Multi-agent systems are real — Anthropic's own Research feature runs an orchestrator that spawns parallel sub-agents, and it beat a single-agent baseline by 90% on internal research evals. But read the fine print like an FDE: agents use about 4× more tokens than chat, and multi-agent systems about 15× — so the economics only work for high-value tasks, and the architecture only pays off when the work genuinely parallelizes, like breadth-first research across independent sources.³ Sequential tasks where every step depends on the last — most coding, most form-filling, most support flows — gain little and pay everything. When a customer asks for "a team of agents," your first question is the one from this lesson's third quiz: what part of this work is actually parallel?

🧪 Practical steps: triage assistant with tools (~90 min)

Time to build. Your customer is the course's fictional virtual-care provider, and the question their intake staff ask forty times a day is: "can nurse triage handle this, or does it need a GP telehealth slot?" You'll build an agent that answers it by calling real tools — a clinic-availability lookup over a small JSON dataset and a triage-protocol search over provided text snippets. One of the three tools ships with a deliberately bad description: you'll watch the agent fail, fix the description using this lesson's principles, and document the before/after. That failure analysis is the most interview-quotable part of the artifact. Full instructions and starter code are in labs/0003-triage-agent.md.

1. Set up — create D:\Projects\FDE-Portfolio\l03-triage-agent\, copy the starter file and dataset from the lab instructions, confirm ANTHROPIC_API_KEY is set and pip install anthropic is current.
2. Read the tool definitions first — before running anything, predict which tool the model will struggle with and why. Write your prediction down.
3. Write the agentic loop — the starter marks a TODO: loop while stop_reason == "tool_use", execute the requested tools, return tool_result blocks, repeat.
4. Run the five test questions — routing questions of increasing nastiness are in the starter. Log every tool call the model makes.
5. Observe the failure — one tool has a uselessly vague description. Capture the misbehaviour concretely: wrong tool chosen, malformed arguments, or the model guessing instead of calling it.
6. Fix the description — rewrite it per this lesson: say when to use it, describe each parameter, name the return format. Re-run the same five questions.
7. Document before/after — in README.md: the bad description, the observed failures, the fixed description, the new behaviour, and one paragraph justifying why this problem got an agent rather than a workflow.
8. Commit the artifact — code, dataset, README. This agent gets a real MCP integration in Lesson 07 and production hardening in Lesson 08 — it's a running character in your portfolio, not a throwaway.

Feedback loop: bring your README and transcript back to me in chat and I'll review it like a staff engineer would — is the workflow-vs-agent call justified, do the tool descriptions follow the principles, and is the failure analysis honest about what broke? This artifact feeds the Lesson 11 capstone engagement and is tracked in reference/artifact-tracker.html.

You are a staff-level applied AI engineer reviewing my work: a patient-routing triage agent for a virtual-care provider, built in Python with the anthropic SDK. It uses an agentic tool-use loop over 2–3 tools (clinic availability lookup, triage protocol search). The lab included a deliberately bad tool description; I observed the failure, fixed the description, and documented before/after.

Grade each criterion as Strong / Adequate / Missing, with one sentence of evidence:
- Workflow-vs-agent justification: the README argues from the actual decision criteria (unpredictable paths, value, viability, recoverable errors) why this is an agent and not a routing workflow — or honestly concedes where a workflow would do.
- Tool description quality: each tool description says WHEN to use the tool, documents every parameter, and the tools return human-meaningful context (names/statuses, not bare IDs).
- Failure-analysis honesty: the before/after documents concrete observed misbehaviour (which calls went wrong and how), not a vague "it worked better afterwards".

Be skeptical — probe the weakest criterion first. Then ask me 2–3 follow-up questions an FDE interviewer would ask about this build (e.g. how I'd eval it, what breaks at 10× tool count). Finish with the single highest-leverage improvement.

My README and transcript follow below.

Check yourself — think like an FDE

Scenarios, not recall. Diagnose from the mental model — don't scroll up. Wrong picks stay live.