An agentic workflow differs from classic automation in one thing: you don't tell the system how to do something step by step, you tell it what to achieve — and it picks the steps itself and asks when it's missing something. Picture explaining it to a ten-year-old: you don't have them carry out instructions one after another, you say what should come out of it and leave the rest to them. I'll show you the difference with a concrete example and walk you through building your first such workflow in Claude Code, without writing a single line of code.
Two terms to start. An agent is a program built on an AI model that's given a goal and plans and carries out the steps to reach it on its own — unlike a script, which only replays a sequence written in advance. A workflow is simply a process: a chain of actions leading from a starting point to a result.
A recipe versus ordering at a restaurant
In classic automation, you lay out every step. You drag blocks onto a canvas, connect them, make sure the right data lands in the right places, and configure the connections to other services yourself. You draw the whole map. Skip a step or get something wrong and the whole thing falls apart.
The simplest comparison is cooking from a recipe versus ordering at a restaurant. Classic automation is like cooking dinner from a cookbook: step one, check the ingredients; step two, measure them out, set the oven, watch the clock. An agentic workflow is walking into a restaurant and telling the waiter: "I'll have a good steak." You don't explain how to season it or what temperature to cook it at — you state the result and the kitchen handles the rest. A good chef might still ask: "and how would you like it done?" You say "medium" and the rest happens without you.
That's exactly how an agent works. You give it a goal, it lays out the steps, but it also asks clarifying questions — because many of us know perfectly well what result we want, yet don't know exactly how to get there.
A concrete example. You need the contact details of fifty dental practices in one city so you can send each a personalized message. In an agentic workflow you don't spell out every step. You say what you need, and the agent works out for itself where to pull the data, how to find the contacts, and how to prepare the messages. It may ask along the way what offer you want to present, so it can write them more accurately.
Where you build it: Claude Code
You don't need to know how to program to build a workflow like this. All it takes is the free Visual Studio Code editor (a free Microsoft program for writing and running code) and Claude Code — the tool where the Claude model reads files, plans, and carries out tasks. Claude Code installs into the editor as an extension and requires a paid Claude plan. Once you log in, a conversation pane appears on the right — it looks like an ordinary chat, but you can watch in real time what the model is thinking and doing.
All the work happens in a single project folder. On the left you have the files Claude Code creates and changes; on the right, the conversation where you plan, answer questions, and watch the actions being carried out.
The WAT framework: workflows, agent, tools
The easiest way to organize this is the simple WAT framework — workflows, agent, tools. The agent here is Claude Code, the "brain" you talk to. Workflows are processes written in plain language in text files (in Markdown — plain text with headings and bullet points, no code). Tools are specific actions, already written in code — a part you don't have to look at or understand.
In short: workflows are processes, and tools are individual actions. Back to the kitchen — the agent is the chef. The chef either uses a ready-made recipe (a workflow) or composes one of their own. A recipe has instructions like "crack two eggs, add a cup of flour." The eggs and flour are tools. Out of the combination of recipes and ingredients comes a result — a cake, or a finished agentic workflow.
So the agent works to this framework, it gets a file of instructions at the start — I call it a "job description," because it's exactly what a new hire gets on day one: the scope of tasks, the rules, the way of working. The file explains the three WAT layers to the model and — importantly — how to keep the files tidy, so the project doesn't turn into a mess.
Working modes: from a plan to full autonomy
At the bottom of the Claude Code window you choose how much freedom to give the model. You can have it ask permission before every change, let it edit automatically, switch on planning mode, or skip the permission prompts. My practical advice: start with planning mode. The model then changes nothing — it first lays out what it intends to do and asks questions. You approve the plan only once it looks sensible.
Switch on full autonomy (skipping permission prompts) only when you're sitting beside it watching the model's every move. If you notice it drifting off course, you simply correct it. It's a sensible rule: the more freedom, the more closely you have to watch.
MCP: one address instead of many shops
For the agent to reach data from the internet or other services, it needs tools. It connects to them through MCP (the model context protocol). It sounds technical, but the idea is simple. Take email: there's a separate action to send a message, to save a draft, to fetch the list of emails. MCP means the agent picks for itself which action to use and how to fill it in — you don't have to think about it.
Back to the cake: instead of running separately to the egg shop, the flour shop, and the one for icing, you give the agent access to a single "supermarket" and say: take what you need. In my example, that supermarket is a service for pulling data from web pages, connected through MCP with a single command.
One note on security. Access to services like these works on an API key — a kind of password. You don't type the key directly into the conversation, because it would stay in its history. You save it in a separate, local configuration file. That way, if you ever share the project files, the key won't leak out with them.
What happens when the agent builds
In my example, the task was: pull job listings spread across many pages of a site and save them to a spreadsheet. In planning mode the agent asked questions (whether to fetch the details of each listing, where to save the file, whether to filter the results), presented a plan, and once approved carried out the task — creating, in the process, a tool and a workflow it will reuse next time.
The most interesting part shows up on harder jobs. When it turned out that the requested five hundred listings simply didn't exist in a given region, the agent stopped, weighed other approaches, and asked whether to broaden the criteria. When the tool returned only two results instead of hundreds, it found the bug in how the data was being read and fixed the tool so the problem wouldn't recur. This ability is called self-repair: the agent hits an obstacle, names it, tries a different route, and updates its workflows and tools.
There's one more term worth knowing. The longer the conversation with the model, the more context piles up in it and the worse the model copes — this is so-called "context decay." So every now and then it's worth "compacting" the conversation: the model summarizes what's been agreed so far and works on, keeping what matters. For clarity: a token is a chunk of text the model works with, and the context is all the text it sees at once.
Two mistakes that are easy to avoid
First: too vague a goal. "I need a tool to collect contacts" isn't enough — the agent doesn't know which industry or which roles. Yes, it'll ask, but it's better to describe the problem concretely from the start. The planning-mode trick works well here: "here's roughly what I want — help me turn it into a solid requirements document." The agent will lay it out, ask follow-ups, and pose the right questions itself. You're allowed to treat it as an expert; you're the manager keeping an eye on direction.
Second: no definition of "done." The agent has to know when to stop. Without a clear finish line, it can overcomplicate or loop on revisions. Instead of "find profiles of CEOs of tech companies," write: "I need exactly 75 profiles, in a spreadsheet, with name, company, and address — once you have 75, you're done." Clear input, clear output, a repeatable result.
Why this can be more convenient
Three concrete differences from classic automation. First, less tedious bug-hunting — instead of reading logs after a crash, you watch the agent handle the obstacle itself. Second, control in plain language — you don't have to know every block or read the documentation for the connections; you describe what you want. Third, the system gets more capable over time, because after each stumble it updates its workflows and tools.
One important caveat. Self-repair works when you run the agent by hand and you're beside it. If the process is meant to start on its own — every morning at six, or after a form is submitted on the site — what gets deployed is the workflow's code itself, not the agent. Such a process then loses the self-repair ability, because the agent is what provides it. That's a separate topic I won't go into here.
A calm note to close on. If you're only just learning automation, you're not losing anything — the center of gravity shifts from building step by step toward designing whole processes. What counts isn't how many blocks you know, but how clearly you can describe the goal and the finish line.