It told me the ten steps. I ran every one by hand — open, change, run, paste the error back, ask again. I was the manual fallback. That's the scar. An agent is what ends it.
For a year I used AI the way everyone starts: I asked a question, it wrote me a paragraph telling me what to do, and then I — the human — went and did the ten steps by hand. Open this file. Change that line. Run this command. Read the error. Paste it back. Ask again. The AI was a very smart person behind glass, narrating while I ran the machine. That's the scar this whole tier names: Iron Law — "done" means it runs without the human in the chair, and its sharp edge, no manual fallback. A workflow where the human is the hands between every step isn't done — it's a person doing the AI's job by hand, forever. The system that ends it is the one below: an agent — an AI wired to actually touch the project, so it runs the ten steps itself and I read the report.
"For a year I thought 'AI coding' meant a really good autocomplete that talked back — and I was the one carrying every step from its mouth to the keyboard. That's not a partner, that's me being the AI's hands. The day it stopped describing the steps and just did them, the scar closed: I wasn't the manual fallback anymore. And once one of them can run the job, the obvious next thought is — why am I waiting for them one at a time?"
"Straight version: a chat model only emits text — which is exactly why you became the hands. An agent is that same model handed real tools (read a file, write a file, run a command) plus permission to use them in a loop until the job's done. That's the whole jump: from 'answers you then execute' to 'acts.' And because each unit of work is just another agent, you're not stuck with one — hand a focused piece to a fresh one, or fan a batch out so several run side by side."
The shift is one idea with three sizes. An agent is an AI that doesn't just chat — it's been handed real tools (read a file, write a file, run a command) and the freedom to use them in a loop until the work is done. A subagent is an agent you dispatch: you hand a fresh one a narrow, self-contained job ("find every place we read the user's email"), it does that job in its own clean context — a separate conversation, not a separate copy of your files — and it hands you back a short answer, without cluttering your main thread with all 40 files it had to open to find out. A swarm is when the jobs don't depend on each other, so you launch many subagents at the same time and they run in parallel. Same atom — an AI that acts — at one, dispatched, and many. The reason this matters isn't speed for its own sake. It's that you stop being the one who does the ten steps. You describe the work and the machine carries it.
acts, doesn't just chatA model handed real tools and allowed to use them in a loop. It reads, writes, and runs commands itself until the job is finished. Not advice -- action.
one you dispatchA fresh agent you hand ONE focused job. It works in its own clean context -- a separate conversation, not a copy of your files -- and reports back a short answer, keeping the 40 files it read out of your main thread.
many in parallelWhen jobs don't depend on each other, launch several subagents at once. They overlap, so the batch finishes in roughly the time of its slowest one or two -- minus some launch and reporting overhead -- not all of them end to end. Width, not just speed.
Pick two real jobs actually on your plate right now. Ask the one question out loud: does either one need the other's result before it can finish? No → that's a swarm. Yes → that's a sequence. You just ran the whole decision on your own work — the rest of this module only sharpens that reflex.
The model: think of yourself as a foreman, not a bricklayer. A chat AI is a consultant on the phone telling you how to lay the bricks — you still lay them. An agent is one worker you hand a job to who goes and lays them. A subagent is sending one worker off to a side task — "go price the lumber" — so they come back with just the number, not the whole hardware store in your face. A swarm is realizing the plumbing, the wiring, and the roofing don't wait on each other, so you put three crews on them at once. You didn't get faster at laying bricks. You stopped laying bricks. That's the entire move from "AI that answers" to "a machine that does the work, and many parts of it at the same time."
Coming up, you'll watch the operator hand off work. Here's the setup: six small jobs that have nothing to do with each other — audit six different files for the same bug, say. Each takes one agent about two minutes. You dispatch them as a swarm — all six at once — instead of asking one agent to do them one after another. When you dispatch the swarm, what happens?
Watch what broke: nothing was slow — it was wrong, because job 2 ran against a result job 1 hadn't produced yet. The fix isn't "try harder," it's one move: stop the swarm and put the dependent pair back in order. That failure is the whole reason the next question exists — before you swarm anything, you ask the one thing that would have caught this.
Halfway between watching and being tested: a worked sort with one move left to you. Four jobs are on the table. Run the one question on each pair — does it need another's result? — and decide what swarms and what sequences. The answer's right below; check yourself.
The four jobs:
1. audit payments.js for a leaked key · 2. audit upload.js for a leaked key
3. fix the login bug · 4. rewrite the login-flow copy (references the fix from #3)
The sort: Jobs 1, 2, and 3 each wait on nothing — different files, no shared result — so all three are independent → swarm them together. Job 4 depends on Job 3's result → dependent → it sequences after 3: fix login, verify, then write the copy. So the real dispatch is: swarm {1, 2, 3} in parallel, and run job 4 only once 3 is verified done. The one wrong answer is swarming all four at once — that drops job 4 onto a login flow that doesn't exist yet, exactly the mistake you just watched break. (This is the verdict dispatch-check.sh in the payoff prints for you.)
Same rule as always: answer it right, or the module isn't done.
A chat AI answers; an agent acts. Dispatch one subagent for a focused job; swarm many only when the jobs don't depend on each other. You stop doing the ten steps and start running the crew that does.
Two pieces of the machine. First, a runnable dispatch-check.sh: you list your jobs and mark any dependency between them, run it, and it prints the verdict for you — SWARM the independent ones in parallel, SEQUENCE any pair where one waits on another. The decision stops living in your head (where, under pressure, you swarm a dependent pair and bake in a wrong assumption — exactly the break you watched) and starts living in a check that runs the same way every time. Second, a plain DISPATCH-DECISION.md you keep next to you: the one-look card behind the script — "do I dispatch one agent, or a swarm?" answered by the only question that matters, are these jobs independent of each other? Independent → swarm them and get the width. Dependent → dispatch in order so nothing runs against a result that doesn't exist yet. This is the first turn of the wheel the ban forced (the 2026-03-31 account ban, appeal denied 2026-04-13): once you stop being the bricklayer and start dispatching the crew, the real asset is the workflow itself — not any one model — because the same dispatch reflex runs on whatever agent you have that day.
Two checks, both yours to run. First, dispatch-check.sh: feed it a real pair of jobs and watch it print the verdict — don't decide swarm-vs-sequence in your head. Second, the reflex this whole tier turns on: when a subagent comes back saying "done — 23 tests pass," that's a claim, not a fact. You run the test or open the page yourself before you believe it — read before you assert. Here's the script sorting a real batch, out loud:
If the answer to "do they wait on each other?" is no, you have a swarm and you get the width. If it's yes, swarming is how you get an agent confidently building on a result that isn't there yet. The script doesn't make the work faster by magic — it stops you swarming things that needed to go in order, and it never lets a swarm's "done" stand in for a result you actually checked.