This is the version to keep at hand. Open it while you build your first agentic workflow in Claude Code and tick the steps off in order. You don't need to write code — the work is in how clearly you describe the goal and the finish line.
The guiding rule in one sentence: you don't script every step — you state the outcome, and the agent picks the route and asks when something is missing.
0. Before you start — what you need
Check you have everything in place before you go further.
- Install Visual Studio Code — Microsoft's free code editor for writing and running code.
- Add Claude Code as an extension to the editor — the tool where Claude reads files, plans, and executes tasks.
- Make sure you have a paid Claude plan — Claude Code requires it.
- After signing in, check that a conversation panel appears on the right. It looks like an ordinary chat, but it shows in real time what the model is thinking and doing.
- Work in one project folder: files that Claude Code creates and changes sit on the left, the conversation on the right.
1. Structure the project with the WAT framework
Organize the project with a simple WAT framework — Workflows, Agent, Tools.
- Treat Claude Code as the agent — the "brain" you talk to.
- Keep workflows as processes written in plain language, in text files (Markdown — plain text with headings and bullets, no code).
- Leave tools (individual actions written in code) to the agent — you don't need to look at or understand that part.
- Give the agent an instructions file up front — the equivalent of a job description: scope of work, rules, way of working.
- Make sure the instructions explain all three layers of WAT to the model, plus how to keep the files organized so the project doesn't turn into a mess.
2. Start in plan mode
At the bottom of the Claude Code window you choose how much freedom to give the model: ask before every change, auto-edit, plan mode, or skip permission prompts entirely.
- Turn on plan mode first. The model changes nothing yet — it writes out what it intends to do and asks questions.
- Read the plan and answer the clarifying questions.
- Approve the plan only once it looks sound.
- Turn on full autonomy (skipping permission prompts) only when you're sitting right there watching the model work. The more freedom you give it, the closer you need to watch.
- If you notice the model drifting off course, correct it in the conversation.
3. Connect tools over MCP
For the agent to reach data from the web or other services, it needs tools. It connects to them through MCP (model context protocol).
- Connect a service over MCP with one command — for example, a service for pulling data from web pages.
- Leave the agent to choose which action to use and how to fill it in — for email there's a separate action for sending a message, a separate one for saving a draft, a separate one for fetching a list. You don't need to think about that.
- Never type an API key straight into the conversation — it stays in the conversation history.
- Store the key in a separate, local config file. That way, if you ever share the project files, the key doesn't leak out with them.
4. Frame the task: a clear input, a clear finish line
Two easy-to-avoid mistakes come from an imprecise brief. Check both before you send the task.
- Describe the goal concretely. "I need a tool for collecting contacts" is not enough — the agent doesn't know the industry or the roles. Give the industry, the roles, and what you want to get out of it.
- If you're not sure how to describe the requirements, use the plan-mode trick: "here's roughly what I want, help me turn it into a solid requirements document." The agent will draft it and ask the right questions itself.
- Define "done." The agent needs to know when to stop, or it can overbuild or loop on fixes.
- Instead of "find profiles of tech company CEOs," write it precisely: how many records, where to save them, and which fields — for example, "I need exactly 75 profiles, in a spreadsheet, with name, company, and address — stop at 75."
- Treat the agent like an expert; you're the manager keeping it on course.
5. Run it and watch it self-correct
Once you approve the plan, the agent runs the task — and along the way it builds the tool and workflow it will reuse next time.
- Watch the actions unfold in the conversation window.
- Watch how the agent handles a snag: when the data it needs isn't there, or a tool returns too few results, it stops, names the problem, tries another route, and fixes the tool so the error doesn't repeat. That's self-correction.
- When the conversation runs long, compress the context — ask the model to summarize what's been settled so far and keep working from there. The longer the conversation, the more context piles up, and the worse the model performs ("context decay").
For the record: a token is a fragment of text the model works with; context is all the text the model can see at once.
What to watch for
- Don't leave the goal vague. The agent will ask, but it's better to describe the problem precisely up front — industry and roles included.
- Don't skip the definition of "done." Without a clear finish line the agent overbuilds or loops on fixes. Set a clear input and a clear output so the result is repeatable.
- Don't turn on full autonomy without supervision. Skipping permission prompts only makes sense when you're right there and can correct it in real time.
- Don't type an API key into the conversation — it lands in the history. Keep it in a local config file.
- Remember the limit of self-correction. It works when you run the agent by hand and stay nearby. If a process is meant to run on its own — every morning at six, or after someone submits a form on the site — it's the workflow's code running unattended, not the agent, and that process loses the ability to self-correct.