Becoming an AI-Era PM 09 | From Executor to Orchestrator: Your New Job Is Conducting a Fleet of Agents

Start with how the most productive people work now.

They run several agents at once — each with its own context window, its own slice to own, its own file scope, all running asynchronously; the human sits above it, splitting the work, handing it out, coming back a while later to sign it off, no longer watching one AI edit code line by line in real time. Addy Osmani draws the two modes apart cleanly: in one you’re the conductor, driving a single agent in real time, and your own head is the ceiling; in the other you’re the orchestrator, holding a fleet of agents, planning, dispatching, and coming back periodically to check — your throughput no longer capped by your own bandwidth.

That’s good news for product managers. Because “orchestration” is exactly the PM’s old trade — break a big goal into tasks, hand them to different people, watch each one’s boundaries, then sign off and merge at the end. It’s just that the thing you used to orchestrate was people, and now there’s a fleet of agents in the mix too. The mechanical part of the coordination (chasing status, restating requirements, aligning formats) gets handed off to the agents; the judgment part of orchestration stays with you — and it’s worth more now. Below are four moves you can run.

1. Stop following one agent start to finish

The most common waste is treating AI like an intern you have to watch the whole time: send a line, wait for it to finish, glance at it, send the next. Your attention is its ceiling, and you can only push one thing forward at a time.

The orchestrator flips it: if a task splits into three chunks that don’t depend on each other, spin up three agents at once, give each a chunk, and let them run in parallel. You go from “babysitting one in real time” to “collecting three every so often.” It feels wrong the first time, because you have to let go of the itch that every step needs your eyes on it — but that’s exactly where your throughput multiplies.

2. Split the work into parallel chunks with non-overlapping boundaries

The first craft of orchestration is splitting. How well you split decides directly whether this fleet of agents helps you or just gets in your way.

A chunk you can hand off in parallel has to meet two conditions: no dependency (A doesn’t wait on B’s result) and non-overlapping boundaries (two agents won’t be editing the same thing at once and colliding). Building a feature, say, you can split it into “the backend endpoint,” “the frontend page,” and “the tests for this piece” and hand each to an agent; but “design the database first, then write the endpoint that depends on it” can’t go in parallel — that has to run in sequence. Before you split, ask: can these two chunks each be finished on their own? If not, don’t force the parallel.

3. Give every chunk a clear spec

This is the most make-or-break link in orchestration, and it’s the amplified version of the thing from piece five. Addy Osmani puts it bluntly: a vague instruction gets amplified into a whole fleet of agents’ worth of mistakes; a precise one, into a whole fleet’s worth of precise implementations.

Drive one agent, hand it a fuzzy instruction, it gets one thing wrong, and you fix it on the spot. Dispatch five at once, each holding the same fuzzy instruction, and that’s five ways off track — by the time you come back to collect, all five need redoing. So before you hand out work, apply that piece-five toolkit — swap adjectives for numbers, spell out every state, list the boundaries and the “what not to do” — then send them off one by one. The more you dispatch, the more the precision of the spec gets multiplied, toward the right direction or the wrong one.

4. Your job becomes splitting, signing off, and stitching together

Once the agents take over “build the thing,” what’s left in your hands is three heavier jobs: split the work right at the start, hand out clear boundaries in the middle, and at the end pull the chunks back in, sign them off, and stitch them into a whole.

The easiest mistake here is getting itchy and jumping in to do something an agent could perfectly well have done — the moment you sink into the implementation details of one chunk, the whole orchestration stalls. The orchestrator has to stay “above”: watching whether each chunk comes back right (use the move from piece eight — make it lay out its plan first, then you verify), fitting them together and checking whether the whole thing holds. Your value isn’t measured by which chunk you wrote by hand; it’s measured by whether the thing this fleet of agents delivers, taken together, actually stands up.

One thing you can do today: pick a task you’re about to start that can be split, try cutting it into two or three chunks that don’t depend on each other, spin up an agent for each, and do only three things yourself — split, spec, collect. Feel, just once, the difference between “pushing three things forward at once” and “running them one after another.”

Further reading

• Addy Osmani, “The future of agentic coding: conductors to orchestrators” (conductor vs. orchestrator, precise specs multiplied): https://addyosmani.com/blog/future-agentic-coding/
• Piece 05 in this series, “When the Requirement Is Fuzzy, AI Fills the Gaps for You — Badly” (the precision of the spec): /en/blog/say-it-clearly/
• Piece 08 in this series, “AI Can’t Find the Real Problem for You” (make it lay out its plan before you sign off): /en/blog/find-the-real-problem/