Delegation: You Already Know How to Manage an Agent

Everything you learned managing people just became the most valuable thing you can do with software.

There’s a skill almost everyone reading this has, and almost nobody thinks to use on their software. You learned it the first time you handed a piece of your work to another person and didn’t hover. You described what “done” looked like, you let them figure out the middle, and you judged the result instead of policing every step. That’s delegation. It’s the quiet competence that separates people who are merely busy from people who actually multiply what they can do.

For most of the AI era so far, that skill was useless. You typed, it answered, you typed again. You operated a very clever vending machine: insert prompt, receive output, repeat. The whole interaction lived inside your hands. Step away and nothing happened, because nothing was happening without you.

That’s the part that’s changing. The clever vending machine is starting to behave like a colleague. And the people who’ll get the most out of it won’t be the ones with the cleverest prompts. They’ll be the ones who already know how to hand off a goal and trust it to come back done.

Assistant or agent

The difference is easy to feel once you’ve named it. An assistant responds to a request, does one task, and waits for the next instruction. It’s reactive by design. You’re the engine; it’s the tool you’re holding.

An agent works toward a goal. Instead of reacting once, it takes a big objective, breaks it into steps, and carries those steps out over time, without you guiding each stage. You’re no longer holding a tool. You’re describing an outcome and getting out of the way.

That second sentence is the whole shift. “Get out of the way” is what good delegation feels like with a person, and exactly what felt impossible with software until recently. The reason it’s possible now comes down to four capabilities that, on their own, are unremarkable. Together, they’re the difference between a tool and a teammate.

It remembers. An assistant forgets you the moment the window closes. An agent holds context: what you asked for earlier, what it already tried, and where to find the documents, notes, and records it needs to do the job. This is the colleague who’s been around long enough to know where things are kept, instead of the temp you have to re-brief every morning.

It plans. Hand a person a vague goal and they’ll quietly turn it into a sequence: first this, then that, check, adjust. An agent does the same. It takes “draft a competitive teardown of these three products” and decomposes it into the steps you’d have written on a sticky note, then works through them in order. You supplied the destination; it drew the route.

It acts. This is the one that surprises people. An assistant talks about the work. An agent does the work in the actual systems where the work lives. It can pull the data, fill the spreadsheet, send the email, and kick off the next process. The talking stops being the product. The talking becomes the means to a finished thing.

It keeps going. A vending machine gives you one item and stops. An agent continues to work until it reaches the goal: tracking its own progress, noticing when something breaks, and adjusting when the first attempt doesn’t hold. That persistence is what lets you say “handle this” instead of “do this one step, now wait.”

Memory, planning, action, persistence. None of them is impressive in isolation. Stack them and you get something you can hand a real piece of work to, which is the only thing delegation has ever required.

What actually changed

We’ve been told the skill of the moment is prompt-craft: the right phrasing, the magic words, the secret formatting that unlocks a better answer. There’s a small industry built on the idea that the better you operate the machine, the better your results.

That was true when the machine was a vending machine. It’s less true now and getting less true by the month. When the thing in front of you can plan and persist, the bottleneck stops being how well you push its buttons. It becomes how clearly you can say what you want. The constraint moves from the tool to you, and specifically to the part of you that knows what “good” looks like and can describe it to someone else.

Which means the valuable skill was never prompting. It was the older, less glamorous thing underneath: getting precise about outcomes. What does done look like? What should this avoid? What would make me reject the result? Anyone who has managed people has been practicing this for years. The surprise is that it now transfers to software, and that the transfer is where the real gains are hiding.

The failure is also familiar

Here’s the honest part, because pretending otherwise helps no one. Delegating to a person who doesn’t actually understand the goal produces confident garbage, delivered on time, looking finished. Agents do the same thing. They will pursue the wrong objective with total commitment and hand you something polished and wrong.

So the skill isn’t blind trust. It’s the same judgment a good manager already runs. Write a clear brief. Define “done” before you start. Then spot-check the result rather than the steps, because checking every step is just doing the work yourself with extra anxiety. If you can’t tell good output from bad in a given domain, you can’t delegate it yet. Not to a person, and not to an agent. That’s not a limit of the technology. That’s a limit of your own taste, and the fix is to develop the taste, not to write a longer prompt.

This is the quiet reason delegation compounds. Every time you force yourself to write down what you actually want, the brief gets reusable and your own thinking gets sharper. The clarity outlasts the task. You’re not accumulating prompts; you’re accumulating a clearer sense of what good work looks like, which pays forward into everything else you do. That clarity is intellectual capital in the most literal sense: it grows the more you’re made to spell it out.

One thing to try this week

Pick one recurring task you’d normally grind through yourself: the weekly summary, the first draft of a recurring report, or the research you do before a decision. This week, don’t prompt it step by step. Write it a brief instead, the way you’d write one for a sharp new hire on their first day:

• The goal, in one sentence.

• What “done” looks like, concretely.

• What to avoid and any constraints that matter.

• Where to find what it needs.

Hand the whole thing over at once and let it run. Then judge only the result against the “done” you defined before you started.

You’ll learn two things fast. You’ll find out whether the tool can carry that kind of work yet. And you’ll find out something more useful: how clearly you actually understand what you want. The first answer changes monthly. The second one is yours to keep.