Stop prompting, start delegating
There's a mode most people never leave, and it has clear symptoms. You write one giant instruction and cram every requirement into it. When the output is wrong, you re-roll the same message with slightly different wording, like shaking a vending machine.
Last week I handed you a routing table — task class on the left, the tier it goes to on the right, the one-line reason in the middle. Copyable, practical, the least philosophical thing I've written in this series. And a few people wrote back with a version of the same question: fine, but I still can't get the thing to do what I want.
Here's the uncomfortable answer. You're not bad at prompting. You're doing the wrong job.
The tell: you're still prompting
There's a mode most people never leave, and it has clear symptoms. You write one giant instruction and cram every requirement into it. When the output is wrong, you re-roll the same message with slightly different wording, like shaking a vending machine. You treat a bad result as a phrasing failure — I must not have said it right — and reach for a better incantation.
That's prompting. Prompting optimises a single turn. You are tuning one message to squeeze a better response out of one model, and the whole game is word choice.
It works fine when the task fits in one turn. It falls apart the moment the task is big enough to need a stack — because a stack isn't a better vending machine. It's a team. And you don't manage a team by writing one perfect sentence and pulling the lever.
What a manager does that a prompter doesn't
Think about what actually happens when a good manager hands off work, versus what happens when you fire a prompt into a box.
A manager scopes the work before assigning it — decides what's in, what's out, what "done" even means. A prompter starts typing.
A manager picks the right person for the task — not the most senior one every time, the right one. A prompter sends everything to the same model and hopes.
A manager writes a brief, not an order. "Here's the goal, here are the constraints, here's what done looks like — you work out the approach." A prompter dictates steps and is surprised when the model can't improvise around the one thing they forgot to mention.
A manager sets the acceptance bar before seeing the output, so they can't be talked into "good enough" by a confident-looking result. A prompter decides whether it's acceptable after reading it, which is how you end up rationalising mediocre work.
A manager checks the work rather than re-typing it. A prompter, when the output is wrong, does the job themselves in the next prompt.
Map those onto the stack and it's not a metaphor, it's the actual division of labour. The brief and the "should we even do this" judgement live at the architect tier. Decomposing the brief into assignable pieces and coordinating them is the orchestrator. Executing the pieces is the workers. The manager's job — the part that's yours — is the scoping, the brief, and the acceptance bar. That part doesn't get delegated. It's the thing that makes delegation work.
The shift, concretely
The whole thing collapses to one contrast.
Prompt: "Make this better."
Brief: "Here's the goal, here are the constraints, and here's what done looks like. You choose the approach."
The prompt optimises a message. The brief defines a delegated task with an acceptance bar. Once you see it, you can't unsee it — the unit of work stopped being the message and became the task you can hand off and check. Everything downstream gets easier, because a well-briefed task can go to a cheaper tier and still come back right, and a badly-briefed one can't be rescued by any amount of model horsepower.
Why this is the skill, not a nicety
This is where it ties back to last week. You cannot route if you're still prompting.
The routing table assumes something quietly: that you've scoped the task well enough to know what it is — its ambiguity, its blast radius, its volume. That scoping is the manager's work. If you haven't done it, you're not routing, you're guessing, and no cheat-sheet saves a guess. Delegation isn't a soft skill you add on top of routing. It's the thing routing stands on. Post 13 was the mechanics; this is the prerequisite the mechanics quietly depend on.
Which is why "I'm bad at prompting" is usually a misdiagnosis. The people getting the most out of a multi-tier stack didn't find better words. They changed jobs — from operating a tool to managing a team — and the words stopped mattering as much as the brief.
Delegation includes designing the check
One last piece, because it's where this is all heading. A manager who never reviews anyone's work isn't a hands-off leader, they're negligent. The same is true of a stack. If you delegate the work but not the checking, you haven't delegated — you've abdicated.
So "who checks whom" belongs in the brief, not bolted on after. Deciding that a worker's output gets reviewed across a tier, not by itself, is part of scoping the task — the same act, not a later chore. That's the ground the forthcoming book chapter on "Quality at Machine Speed" is built on: quality gets delegated in, designed into the hand-off from the start, not inspected in at the end. Delegation done properly already contains the check. This series is going to spend more time there.
The short version
Stop optimising the message. Start designing the hand-off. If you're re-rolling the same prompt with better adjectives, you're operating a tool when the job is managing a team — scope the work, write a brief instead of an order, set the acceptance bar before you see the output, and decide who checks whom as part of the brief. That's the mindset the routing table quietly assumes. It's not a nicety. It's the whole game.
If you're testing Fable 5 / Opus 5 too, where did it land for you? And the delegation version: what's the last thing you re-rolled five times before realising it needed a brief, not a better prompt?
Diagram: operator vs. manager — the behaviour contrast, mapped onto the three tiers.
Series: Post 1 — Fable 5 talks to machines better than to people · Show me the receipts · Show, don't tell · Why I took the architect tier out · The RPIQ loop · Where the stack was overkill · BowSmith case study · I lost my favourite tool · Opus Max as architect · Fable 5 came back · CAST26: open season as a quality gate · Opus 5: the middle ground I chose · Is the token even the right unit of account? · Routing rules: which tier gets which task · Post 14 — Stop prompting, start delegating]
