This is the keep-it-handy version of the course, laid out as a chain of decisions. Each stage opens with one question to settle and closes with what disqualifies an option. Come here when you're facing a specific choice — which process to automate, how to run the agent, where to put the approval checkpoint, what to charge — and want to choose deliberately instead of running with the first idea.
A rule that comes back at every stage: building stopped being the bottleneck. The value is in spotting the right problem and pricing what it's worth, not in an impressive agent.
Decision: what to build in the first place
Which process to automate
The question to settle: where does this business waste the most time on repetitive, expensive work?
A picture worth returning to: a business is a pipe that work, orders and money flow through. If there's a clog in the pipe, pouring in more water — more people, AI bolted onto random problems — speeds up nothing. First you find the clog and clear it, only then do you increase flow.
Criteria for judging an automation candidate:
- The work is repetitive — it comes back regularly, it isn't a one-off.
- It eats a lot of time — meaning it genuinely costs the business money.
- It can be described in plain language as a process (a step-by-step recipe).
What disqualifies an option:
- The idea starts from the tool ("I'll build an agent in Claude Code") instead of from the business problem.
- The agent is meant to impress but is built without a specific clog behind it — a nice toy nobody pays for.
An impressive agent with no clog underneath is a toy. An agent that removes a specific, costly bottleneck is something the market pays for. That's the whole difference.
Decisions when setting up your environment
How to run Claude Code
The question to settle: which of the four run modes should you work in for a given task?
Each mode trades off differently. There's no single right answer — you pick for yourself and for the task, not "because that's how someone else does it."
| Mode | Strength | Trade-off |
|---|---|---|
| Terminal | Closest to the raw tool, most control, fewest distractions | A steeper learning curve if the command line is new to you |
| Desktop app | Convenient, self-contained window; a good start without a code editor | — |
| Editor extension (VS Code) | You see the files and the conversation together, easy to track changes | — |
| In the browser | The task runs in the cloud, it doesn't stop when you close your laptop | Better suited to longer background jobs than to hands-on learning |
Default criterion: if you're just starting out or want to learn, take the editor extension (VS Code) — you see the files and the conversation side by side, so it's easy to track what the agent changes.
What disqualifies a mode:
- You pick it "because that's how someone else does it" instead of for your task.
- You use the browser for learning, when its whole point is long jobs running in the background.
Which model
The question to settle: which of the three models should you use for a given job?
You usually have three to choose from — from fastest and cheapest, through a middle tier, to the strongest (Haiku, Sonnet, Opus). You switch models on the fly with the /model command.
Selection criteria:
- At the start, leave the default in place or stick with the strongest model — you'll build a feel for what good output looks like.
- Longer term, a sound strategy is the middle model for most work, switching to the strongest one only for hard design decisions or tangled bugs — then going back to the cheaper one.
- Down to the weaker one, you switch deliberately — say, when you're assigning simple, high-volume work and want to save money.
What disqualifies a choice:
- You drop to the weaker model right at the start, before you've built a feel for quality.
- You keep the strongest model on simple, high-volume work, where it just burns money.
How to manage the context window
The question to settle: what do you do with the model's working memory once it fills up?
The context window is the model's working memory — a notepad where Claude keeps your instructions, your files and the whole conversation so far. Its capacity is finite, typically on the order of two hundred thousand tokens. When the notepad fills up, the model loses the thread or has to summarize itself, and quality drops. Usually that isn't the model's fault — it's a cluttered memory.
| Option | When to use it |
|---|---|
/clear | You're moving to a new task and want a clean start |
/compact | You want to keep the thread but shrink it to the key points (usually around 60% full) |
| Nothing — let it summarize automatically | Right at the start; memory summarizes itself anyway once it hits the limit |
Criterion: the longer the work runs, the more deliberately you manage context; at the start, understanding what's happening is enough.
What disqualifies an option:
- You drag one conversation through several different tasks — you clutter memory and tank your own quality.
Decisions when building the automation
What to hand to a tool versus an agent (the WAT model)
The question to settle: for a given step in the process — should a predictable tool run it, or a decision-making agent?
The WAT model (workflow, agent, tools) organizes the whole job. Workflow is the process described in plain language, like a recipe. Tools are specific, predictable actions (say, a piece of code that always extracts the same data or assembles the same file the same way). Agent is the model in the decision-maker role: it reads the workflow, reaches for tools, and handles exceptions.
| Nature of the step | Who to hand it to |
|---|---|
| Repetitive, can be worked out in advance, should always run the same way | A tool (predictable code) |
| Requires thinking, a decision, or handling an exception | An agent (the model) |
Criterion: hand what's predictable to a tool — cheaper and more reliable. Leave what needs a decision to the agent.
What disqualifies a choice:
- You make the model work out from scratch, every time, something that should run identically — you pay more and lose certainty about the result.
Where to put the human approval checkpoint
The question to settle: can the automation close out this step on its own, or does the final word stay with a human?
A rule you'll carry into practically every job: automate the boring steps, leave the heavyweight decisions to the human. In the newsletter example, the workflow reaches a point where you approve the headline and the whole piece before it ships — on purpose.
Criteria for when to place a checkpoint:
- Reputation is at stake — something goes out under your name or the client's.
- A mistake is costly and hard to undo.
What disqualifies full automation (meaning: when a human has to be there):
- A step releases something into the world with no way back, and a mistake would hit your reputation — that's when you don't let an automation close it.
Keep in mind a distinction that comes back later: what runs in the background is the workflow and the tools, not the agent from your editor. The agent stays on your side, for building and fixing.
How to react when something doesn't work
The question to settle: when the result is weak or something breaks — where do you look for the cause?
The first time, something will break, and that's a normal stage, not a reason to panic. Typically it turns out the test message went out with broken formatting, or the agent got the wrong spreadsheet ID and had no access to it.
Diagnostic criteria (in this order):
- Was the instruction precise — did you clearly describe what you wanted, what result you expected, and what not to do? A vague instruction gives a vague result.
- Does the agent have access to what it needs (the right address, materials, tool)?
- Only once the input is in order do you consider that the problem lies somewhere else.
The fix: show the agent specifically what's wrong ("the message went out with a broken background, fix that"; "I gave you the wrong spreadsheet ID, here's the right one"). The more specifically you name the flaw, the faster it gets fixed.
What disqualifies your reaction:
- You blame the model and give up after the first error instead of fixing the input — this is exactly what separates people who deliver working systems from people who quit.
Decision before handing off to the client
Whether the system is ready
The question to settle: can you put the process on a schedule or a trigger and show it to the client?
A picture: before you let trains onto a new track, you run different trains over it — light ones, heavy ones, on different wheels. You test an automation the same way before putting it into production.
Readiness criterion: you run a series of different inputs through the process — typical ones, but also extreme and unusual ones: an empty document, incomplete data, a strange format, two submissions at once. Every case has to end in a sensible result or a clear message, never a silent failure. When something breaks, you fix it and run it through again.
What disqualifies "ready":
- You only checked the typical case and skipped the extremes — this is exactly where a lot of beginners stop.
- The process ends in a silent failure instead of a clear message.
Only once the system has passed the hard cases do you have the right to look the client in the eye and say: this works.
Decisions on selling and pricing
How to open the sales conversation
The question to settle: what do you open the conversation with the client with?
First rule: you don't open with "I build automations in Claude Code." The client doesn't care — the hammer doesn't matter, the result does.
Criterion for a good opening: you start with diagnostic questions — where are you losing the most time in the business? which processes would you like to run themselves? Diagnosis leads to a solution, and a solution can be translated into measurable value for the business.
What disqualifies an opening:
- You open with "let me show you my workflow" and a tool demo — you become "just another automation guy" instead of a solution seller.
There's one more trap here: knowing how to tell an agent to build something isn't the same as knowing how to judge whether the result is good. You don't need to be a programmer, but the mindset from the start comes back — stay curious, read what the agent does, ask "why that way?" It's curiosity, not coding knowledge, that lets you answer to the client for quality.
How to price the solution
The question to settle: what do you set the price from — the cost of building it, or the value to the client?
The biggest shift is in your head: value-based pricing. You don't count how many hours the build will take — you count what the automation is worth to the business. A glass of water is worth something different to someone after a run in the heat than to someone in an air-conditioned office; same product, different value.
A way to calculate the value (treat the numbers as a mechanism, not a promise — on a real project you plug in the client's own figures): take the hourly cost of the person who does this by hand today, multiply by the time the process eats, and scale it to a week, a month, a year. That's your reference point — not "how many hours will I spend building this" but "how much will the business stop losing once this is live."
The five-step PRICE model:
| Step | What you do |
|---|---|
| P — Prepare | Set value-based pricing in your head: you count the effect (time saved, money, fewer errors), not the hours |
| R — Research | The discovery stage: you talk, map the process, work out where the clog is and what it costs — that's where the pricing numbers come from |
| I — Implementation and pricing | You design the solution and tie the price to the calculated value (say, how much the business recovers in year one) |
| C — Communicate | You paint the picture of the business with the system running, explain scope and quality control — a price with no picture behind it is just a number |
| E — Expand | After delivery, you look for what's next: maintenance, monitoring, optimization, further automations |
What disqualifies a price:
- You price from build hours instead of from value to the business — you position yourself as a freelancer, not a partner.
How to bill, and when to propose an ongoing arrangement
The question to settle: what billing model do you use, and at what point do you propose ongoing support?
Criterion for the moment to propose a retainer: trust comes before the retainer. Asking for a monthly retainer before you've done anything for someone is like asking for a reference before the work has started. First you deliver one or two projects and show the value — then the conversation about ongoing support becomes natural.
Path for the billing model:
- At the start, hourly billing can be fine — you're after experience and proof, not the maximum rate.
- Later, you move toward milestone-based billing. Hours position you as a freelancer; milestones position you as a partner.
- There's no single correct model: the market accommodates a flat price for a result, hour packages, and a scoped retainer.
The step that builds the most trust: once the system is running, show that it's running — record a short walkthrough or go through one or two full runs with the client (from input to result). That turns an abstract "we automated the process" into tangible proof.
What disqualifies your approach:
- You obsess over a retainer before delivering even one project — the second most common mistake, right after skipping tests.
- Early on, you chase the maximum rate instead of collecting experience and proof.
The decision path — one page
Work through these questions in order. Each one is a single decision to make before you move on.
- Process — where does the business waste the most time on repetitive work? (start from the clog, not the tool)
- Run mode — terminal, app, editor extension, or browser? (learning → VS Code extension)
- Model — default or strongest to start; middle tier for most work; weaker deliberately for high-volume jobs
- Context —
/clearfor a new task,/compactat around 60% full, the rest summarizes itself - WAT — repetitive step → tool; step needing a decision → agent
- Approval checkpoint — reputation or a costly mistake? → leave the final word to a human
- Error diagnosis — instruction precision first, then access, only then the rest
- Readiness — did it pass extreme and unusual inputs with no silent failure? → only then production
- Opening the conversation — ask about the problem and lost time, don't demo the tool
- Pricing — count from value to the business, not build hours; run the conversation on the PRICE model
- Billing — deliver first and show proof; hours → milestones; a retainer only after trust
One closing thought: the value isn't in building an impressive agent — building is easy now. It's in spotting the clog correctly, pricing what it costs, and clearing it in a way people can see.