Journal · The AI Architect · 2026-08-04
Give a helper one clear, bounded job. "Handle everything" isn't a task — it's a shrug that produces a mess.
Give a helper one clear, bounded job. “Handle everything” isn’t a task — it’s a shrug that produces a mess.
There is a moment, right before you delegate something, when you feel a small flicker of relief at the vagueness of what you’re about to ask for. If you keep the request loose, you don’t have to do the hard work of deciding what actually matters. You get to hand someone — or something — a fuzzy bundle of hopes and walk away feeling productive. The tension isn’t that broad requests are lazy. It’s that they feel like generosity. You’re giving the helper freedom, room to use judgment, credit for being capable. It doesn’t feel like a shrug in the moment. It feels like trust. The trouble shows up later, when the output arrives and it’s technically responsive to what you asked for and still completely useless.
Vagueness isn’t trust, it’s an unfinished thought
When you tell a helper to “handle the onboarding emails” or “manage the client relationship” or “take care of the report,” you’re not actually delegating a task. You’re delegating the decision about what the task is. That’s a different job, and it’s usually a harder one than the original task itself. A helper — human or AI — now has to guess your priorities, your tolerance for risk, your unstated preferences about tone, your definition of done. Most of the time they’ll guess wrong, not because they’re incompetent, but because you haven’t told them what “right” looks like. You’ve outsourced the thinking you didn’t want to do.
Try this: before you assign anything, write one sentence that finishes the phrase “This is done when ___.” If you can’t finish that sentence, you don’t have a task yet. You have an intention. Sit with it a little longer before handing it off.
Bounded doesn’t mean small
People sometimes hear “give it one clear job” and assume that means trivial, narrow, low-stakes work — data entry, not decision-making. That’s not the distinction. Bounded means the edges are visible, not that the middle is shallow. You can give a helper real authority and real complexity as long as the scope is defined. “Draft three versions of the client update, focused on the delay and the revised timeline, in a reassuring but honest tone, under 200 words” is bounded and substantial. “Handle the client update” is unbounded and thin, even though it sounds bigger.
The test isn’t size, it’s whether you could hand the same instructions to two different people and expect roughly the same shape of output. If the instructions are so open that two competent people would produce wildly different results, the job isn’t a job yet — it’s a placeholder for one.
Try this: take a task you’ve been assigning loosely and rewrite it as if you had to explain it to someone who has good judgment but zero context on your preferences. Notice what you’re forced to specify. That list of specifications is the actual task description you’ve been skipping.
The mess is the cost, not the exception
When “handle everything” produces a mess, it’s tempting to read that as a failure of the helper — they should have asked better questions, shown more initiative, understood what you meant. Sometimes that’s true. But more often the mess is just what unbounded instructions reliably produce, the way a container without walls reliably produces a spill. It’s not a surprising outcome. It’s the expected one.
This matters because it changes where you look for the fix. If you assume the helper failed, you either train them harder or replace them, and the pattern repeats with the next helper too. If you recognize the instructions failed, you fix the actual problem: the scope was never drawn. This is especially easy to miss with AI tools, because they’ll produce something confidently no matter how vague the prompt, and confident output can be mistaken for good output. A bounded task gives you something to check the work against. An unbounded one gives you only your own retroactive judgment about whether you like what came back — which isn’t a standard, it’s a mood.
Try this: the next time you get a result you don’t like, ask whether you could point to the instruction that it violated. If you can’t, the problem probably isn’t the output.
None of this is really about efficiency, though it does make things more efficient. It’s about respecting the work enough to decide, before you ask for help, what you actually want. That decision is yours to make — no helper, however capable, can make it for you. In the book I go further into how to size these tasks, how to write instructions that hold up under real use, and how to notice the specific ways vagueness sneaks back in even when you think you’ve been clear. But the starting place is small and worth trying today: before you delegate, finish the sentence. Say what done looks like.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.