Name the Station Before You Write the Brief

“The AI isn’t good enough yet” is one of the most common complaints I hear about these tools, and in my own experience it’s almost never actually true.

I built something recently that makes the pattern obvious, because I ran straight into it myself before I saw it. I wanted an AI worker to publish my YouTube videos — find the finished file, the thumbnail, the title, the description, get it onto the channel, correctly, without me doing it by hand every time. That sounds like one job. It isn’t. “Publish my videos” is actually five or six different asks stacked inside one sentence: assemble the package, remember which file goes with which post, format it the way the platform wants, choose the playlist, confirm it actually went live. I built toward that whole stack at once, the way most people do, and the result was competent but forgettable — a tool that did roughly what five separate manual steps already did, just slightly faster.

The moment that actually changed anything wasn’t a better model. It was noticing what I’d actually built. I’d automated the click. I hadn’t automated the handoff. Worse — I was the handoff, still standing between every other part of my own system and the platform, manually re-explaining content that other parts of that system already understood perfectly well.

The fix wasn’t a smarter tool. It was a smaller, exact job description.

Once I saw that, the rebuild wasn’t about adding capability. It was about naming one station and refusing to let the job wander past it. The tool I ended up with — I call it Scribe Hands — doesn’t take “manage my publishing.” It inherits work that’s already been decided elsewhere (a script already written, a thumbnail already designed, a calendar that already records what’s approved and when it’s due) and does exactly one thing with it: get it onto the platform correctly, without asking me to reassemble a package it could have inherited in the first place. Nothing broader. That narrowness isn’t a limitation bolted on after the fact — it’s the entire reason the thing is trustworthy enough to actually leave alone. A tool that knows its one job can be judged against that job. A tool doing five vague jobs at once can’t really be judged against any of them, so every disappointing result gets blamed on “the AI,” when the actual problem was upstream of any model.

None of this means the job disappears — it means it moves to a different place. I still review every script and every storyboard before anything ships; the judgment doesn’t go away, it just happens before approval instead of being re-litigated after it, one platform at a time. And precision doesn’t fix everything on its own: Scribe Hands only works because the calendar it reads from is already correctly filled in. What happens when that input is wrong or incomplete isn’t something I’ve settled yet — whether it would catch the mismatch, recover from it, or need me pulled back in is a real, open question I’m still testing, not a guarantee I’m making here. A precise tool isn’t a mind reader. Naming one exact job doesn’t hand you an answer key to every way that job can fail — it just narrows the job small enough to actually watch.

A precise job is trustworthy. A vague one, however capable the tool behind it, never quite is.

So before you hand your next real task to an AI tool and judge the result, try naming the actual station first — out loud, in one sentence, the way you’d brief a new hire on their first specific task rather than handing them your whole inbox and a shrug. If you can’t finish that sentence without an “and” in the middle, you don’t have one job. You have two or three, wearing one request. Split them, hand each its own precise ask, and see what changes before you conclude the tool was the problem.

The clearest working proof of this I can point to is Scribe Hands itself, built exactly this way — one named job, inherited context, nothing broader asked of it, if you want to see what a tool built to do one thing, instead of everything, actually looks like in practice.

The models underneath these tools keep getting more capable every few months. That was rarely the actual bottleneck. The bottleneck was the size and shape of the job we handed them — and that part has always been ours to fix, model or no model.

Reading started recently with a seven-post prompting course, Wise Architects Corner, taught by a moderator going by Bas inside Jake Van Clief's Skool community. That’s an affiliate link — if you join through it, I get a small commission at no extra cost to you.

The course’s prompting content itself isn’t what this piece draws on. What is: a structural observation from that same reading about compound, undefined asks — that a request asking for a decision and a finished deliverable in the same breath tends to produce a worse version of both than splitting them would have. That’s the same shape as the mistake in my own Scribe Hands story above, just first noticed in a different context.