🍳 The three pieces

New here? WAT it’s the abbreviation that gives this course its name: Workflow + Agent + Tools. Three parts that, together, turn a request in Portuguese into a task that’s actually carried out. To get a firm grasp of the mental model, think of a professional kitchen.

A good kitchen has three separate things: the recipe (the written step-by-step instructions), the cook (the one who reads the recipe, decides on adjustments, and fixes the seasoning) and the ingredients and appliances (what physically exists to become a dish). Remove any one of the three and the kitchen stops working—or becomes something else.

The analogy works for any repetitive task, not just cooking. Take an example very different from a newsletter: organizing the month’s receipts for expense reporting. The recipe (workflow) says, “get the receipts from the ‘finance’ folder, sort them by category, total each one, and create a summary spreadsheet.” The cook (agent) decides which category an ambiguous receipt belongs in ("transportation" or "food"?) and notices if a file is corrupted. The ingredients (tools) are the PDF/image reader that extracts the value and the spreadsheet tool that records the summary. None of the three pieces, on its own, organizes any receipts.

New here? Workflow here is simply the written recipe: a sequence of steps in plain text (often in markdown — a way to format text with headings and lists, without complicated code) that says what to do, in what order, and what to check at each step.

A good workflow doesn’t need to anticipate every exception—it just needs to be clear enough so whoever reads it (the agent) knows what to do in the normal flow and recognizes when something goes off track. It's different from a traditional computer program: these aren't rigid, line-by-line instructions, but guidance that someone capable of interpreting them (the agent) will follow with good judgment.

## Workflow: relatório semanal
1. Ler os números de vendas da planilha "vendas.csv"
2. Somar por categoria
3. Escrever um resumo de 3 parágrafos
4. Salvar como "relatorio-semana.md"
5. Se algum número parecer errado (negativo, vazio), avisar antes de salvar

Another short example, outside the world of email: a workflow for scheduling social media posts could say “read the texts in the ‘posts-da-semana’ folder, generate a cover image for each one, publish one a day at 9 a.m., and let me know if any text exceeds 280 characters.” The recipe doesn’t explain how generate the image or how publish — that’s the tools’ job. It only specifies the order, the exception, and when to stop.

O agent (agent) is Claude Code — the cook in our analogy. It reads the workflow, interprets each step, decides which tool to use to carry it out, checks the result, and adjusts its course if something didn't match expectations. It's the part that provides judgment to the process: without it, the recipe stays on paper.

This is different from a traditional script (a fixed program that just repeats the same steps without understanding what it's doing). The agent understands the intent behind the “sum by category” step, even if the spreadsheet has an extra column or a different name than expected — it adapts within reason.

Common error: the agent “makes up” a path. Imagine a customer service workflow that says “answer questions about orders using the system data” but never says where there’s neither the system nor what to do if the request isn’t found. Without this information, the agent may improvise — respond with a guess — because it was instructed to solve the problem, and “I don’t know” is rarely the first option it tries. The agent isn’t “lying”: it’s filling in a gap the recipe left open. The fix is always in the workflow — say, “if you can’t find the request, stop and ask.”

Tools (tools) are the ingredients and appliances: the things that actually do the work when the cook calls them — opening a file, running a command, sending an email, searching for something online, calling an API (a communication channel that a website or service leaves open so programs can talk to each other without needing a screen). Without them, the agent would only have opinions, not the ability to act.

A tool without a workflow is practically useless: having an oven on doesn’t make the cake bake by itself — someone (the agent, following the recipe) needs to put the batter in at the right time and temperature. That’s why Tracks 2 (MCP) and 4 (Deploy) in this course are entirely about providing and connecting tools — but they only make sense alongside a workflow that says when to use them.

Common error: the tool’s key is missing. A lot of tools require a API key (a long password that identifies you to the service— Gmail, Google Calendar, a database—configured before it can work. Without it, the tool is stuck: the agent tries to use it, gets an access denied error, and stops there. It’s worth checking before any new automation: does the key exist, is it in the right place, is it still valid? “Tool installed” and “tool authorized to act” are different things—the Trails 2 and 4 show you how to store keys securely.

Caption: the same agent attempt, two different outcomes — the tool with a configured key completes the work; the one without a key blocks execution until someone fixes the configuration.

Separating workflows, agents, and tools isn't a technical nicety — it's what makes the system predictable enough to trust and flexible enough to be useful. The workflow holds the intent (what to do), the agent stores the judgment (how to interpret and adjust), and the tools store the capacity (what is physically possible to do on the computer or online).

Caption: the recipe comes in from the left, the agent interprets it and activates the tools on the right, and the result cycles back so the agent can decide the next step — this is the loop detailed in module 1.2.

To see all three pieces in action from start to finish, follow a real customer email triage request— a scenario quite different from the newsletter that appears later in the track:

1. 1. The recipe exists

   The workflow says: “read new emails, classify them as question/complaint/praise, answer simple questions, forward complaints to a human.”

2. 2. The agent reads and classifies

   Opens the inbox (via a tool), reads each email, and decides on a category—that judgment is its own; the workflow only provided the possible categories.

3. 3. The tools act

   For a simple question, the email tool sends the standard reply. For a complaint, another tool forwards it to a human and marks it “priority.”

4. 4. The result is observed

   The agent checks whether the submission was confirmed before moving on — if it fails, it tries again or records the error.

5. 5. End of the cycle

   If there’s no new email, the agent stops and reports a summary: how many were answered, how many were forwarded.

Two broken combinations explain why all three pieces need to work together. One agent without a workflow it still works, but becomes expensive and erratic: with each request, it reinvents the process from scratch, without learning from last time, and it may take different paths in similar runs. A tool without a workflow is practically useless on its own: an email-sending tool can't decide by itself when or to whom it should send something.

Example of an agent without a workflow: asking “organize my calendar” without details. In one run, it prioritizes work meetings; in another, it prioritizes personal commitments—there’s no recipe setting the criteria. A tool without a workflow would be a perfectly configured post-scheduling tool with a valid key, but no instructions for when to publish what—available, but idle. Both situations reinforce the same lesson: a workflow is what turns standalone capabilities into reliable results.