Delegating to agents is a management skill, not a prompting skill

It’s 9:14pm and four terminals are waiting on me. Agent in window one has asked whether to regenerate the migration or roll forward. Agent in window two wants to know if it should use the new auth helper or the old one. Agent in window three has been blocked for eleven minutes because I forgot to tell it what the acceptance criteria actually were. Agent in window four has opened a pull request I haven’t looked at.

I’m not a better prompter than I was six months ago. I’m a worse manager than I realized I’d need to become.

The skill we named wrong

The dominant narrative of 2024–2025 was that working with AI coding tools is a prompting skill. Write the right instruction, get the right output. A whole genre of blog posts, courses, and Twitter threads formed around the craft of the single-turn instruction. Be specific. Include examples. Use delimiters. Ask for structure.

All of that is true and most of it is trivial. The people stuck are not stuck on prompting. They’re stuck on the thing that starts happening in month three: agents in parallel, tasks with dependencies, context that needs to be handed off, decisions that need to be remembered, accountability when something breaks at 2am.

Prompting is typing. Delegation is management. Most prompt-engineering advice — the kind that optimizes for cleverness inside a single message — is operationally bad management advice.

What management actually teaches

I’ve run projects in B2B SaaS for 20+ years, most of it at one B2B and B2C vendor. The single biggest variable in whether a quarter shipped was not the team’s technical skill. It was how clearly each person knew what was theirs. Role clarity beats instruction quality every time.

The management craft is four moves, in this order, before any work starts:

Role clarity

Each agent gets one job, defined narrowly enough that a stranger could describe what it owns in one sentence. This agent ships code to a branch and opens a PR. It does not deploy. It does not write tests for features it didn’t implement. It does not answer questions the PM should answer.

The mistake is assuming a general-purpose agent is lower-overhead than a specific one. It’s the opposite. A general agent asks you more questions because nothing has been decided upstream. A specific agent carries the decisions in its role.

Handoff before output

The best engineering managers I’ve worked with spent the first ten minutes of a task not telling the engineer what to do, but telling them what was already known. Who’d looked at this before. What had been tried. Which constraints were real and which were inherited. Why we were doing this now and not three months ago.

The same is true for agents. The prompt that lists the constraints — even the constraints you don’t think the agent will hit — is worth ten prompts that list the desired behavior. Output is downstream of context. Handoff is the management of context.

Accountability

When the payments flow breaks in production at 3am, who picks up the page? In a managed team this is decided before any code is written. It has to be, because the 3am response time is too slow to figure out.

In an agent-augmented workflow the same question applies to the code the agent wrote. I own what I merged. The agent doesn’t own anything, because the agent has no skin and cannot be paged. If I’m not willing to be the accountable party for the diff, I should not be merging the diff. The delegation is clarifying — it tells me when I’m actually still the one doing the work, and when I’m cosplaying delegation while shedding responsibility.

Cadence

How often do you check in? Four agents running in parallel is not a higher productivity state than one. It’s a management load with an exponent. The good managers I worked with knew exactly how often their most junior reports needed to be unblocked, and they protected that cadence like a meeting.

My rule now: no more than two agents in parallel unless the tasks are fully independent (different repos, different decisions, zero shared context). Three starts feeling like a team; four is a team without a manager.

What the prompt-engineering literature gets wrong

Most of what gets published about prompting is a management anti-pattern applied to single-turn messages. Write detailed instructions for everything. Demand exhaustive outputs. Specify every edge case up front. Force the model to justify itself.

In a human context, a manager who worked this way would be micromanaging. They’d be slow, their team would be frustrated, and the work would be worse than if the manager had set a clear outcome, communicated the constraints, and trusted the person to come back with questions. That — a clear outcome, a named constraint, a named owner, a named checkpoint — is delegation. The fact that it works on humans and on Claude with roughly the same grammar is not a coincidence.

The prompt that looks most like a managerial brief is the one that works. Not the clever one. Not the longest. Not the one with the most examples. The one that reads like a well-run Monday morning.

The Monday morning test

Before I send an agent a non-trivial task I ask myself, on one deep breath: if I were giving this to a capable mid-level engineer on their first Monday, what would the handoff sound like?

The answer usually includes things I would have skipped in a prompt. The name of the PM who will review it. The customer who asked for it. The one code path I’ve already decided we’re not touching. The deploy window. The Slack channel where the questions should land. Things I know, and that the agent cannot possibly infer, because the agent has no map of the organization it’s working inside.

When I write that version, the agent ships. When I skip it and write the clever prompt, the agent ships something technically correct and operationally wrong, and my Monday evening gets longer.

The question I should have asked years ago

The engineers I coach who move fastest in agentic workflows are the ones who ran teams — even small ones. They already learned that the binding constraint on velocity is clarity of ownership, not individual IQ. They already learned that a clear brief beats a brilliant instruction. They already learned to write outcomes and leave paths open.

The engineers who struggle are often the best individual contributors — the ones for whom typing was always the faster path. The management muscle they never had to grow is the exact muscle agentic work demands.

20+ years of project management — scoping, sequencing, keeping the handoffs clean — turned out to be better preparation for working with agents than ten years of solo coding would have been. I didn’t plan that. It’s a little funny. It’s also the clearest signal I know of where the craft is moving.

---

At 9:47pm I closed three of the four terminals. The remaining agent has a one-sentence task, a named owner (me), a clear constraint (don’t touch the migration), and a checkpoint in twenty minutes. It’s shipping. I’m reading. This is what delegation feels like when it works — quieter than prompting, slower at the sentence level, and faster at the week level.