At six in the morning, before Claire Vo has looked at her phone, an agent named Polly has already read her email, checked her calendar, and queued up her day. By the time she sits down with coffee, a second agent has reminded her husband about spirit day at school and a third is most of the way through a sales email. Nine agents and counting, running pieces of her businesses while she sleeps. She describes the experience in a line that sounds like relief: she doesn't find it "much different than managing a remote team."

Hold onto that sentence, because a lot of Product Leaders are about to take it literally — if you can lead people, you can lead agents, the skill you already have is the skill the next decade needs — and the ones who do will spend eighteen months discovering they quietly took on a second job, did it badly, and let the first one rot while they weren't looking.

The resemblance is real. That's what makes the mistake easy.

The frame transfers. The craft doesn't.

Strip both jobs down to instincts and they rhyme. Managing a high-agency PM and directing an agent fleet both reward the same managerial reflexes: lead with intent instead of instruction, calibrate trust and widen scope as it's earned, verify by exception rather than redoing the work, decompose an ambiguous problem into mandates clean enough to hand off. A leader who has those reflexes will feel them fire in both settings. That's the part of Vo's line that's true, and it's why the analogy lands.

But those instincts are maybe forty percent of either job. The other sixty percent is craft, and the craft pulls in opposite directions. One job is relational, slow, and tolerant of ambiguity. The other is specification-heavy, continuous, and unforgiving of it. Calling them the same job because the instincts overlap is like calling a software engineer and a site reliability engineer the same person because they both know the codebase — one builds the system, the other keeps it running. The overlap is real. The work is not the same work.

Three places it diverges hard.

Verification runs the other way

With a high-agency human, the entire point of seniority is that you check less over time. You hire a strong PM precisely so you can stop reviewing their decisions. Trust compounds, oversight relaxes, and a manager who keeps re-checking a proven senior is the problem, not the safeguard.

Agents invert this. Trust doesn't accumulate — a hundred correct actions tell you nothing about the hundred-and-first. There's no learning carryover between today's good judgment and tomorrow's, no instinct about its own limits, no hesitation in front of a decision it should have flagged, no shame to make a near-miss sting. So oversight can't decay with familiarity. It has to be built — sampling, acceptance criteria, automated checks — and it grows with volume rather than shrinking with trust. Human management trends toward less supervision per unit of trust. Agent management trends toward more-systematized supervision per unit of scale. These are not the same muscle. One is learning when to let go. The other is learning never to.

This is the same argument I made in "The PM Who Never Wrote a Test," now turned up a level. Generation was never the hard part. Consumption is — trusting, checking, and absorbing what gets produced. A fleet doesn't relieve that load. It manufactures it, faster than a person who relaxed their guard the way they'd relax it with a good hire can keep up.

The human half of the job is the whole job — and agents don't have it

Most of what makes managing people hard has no analog in a fleet. Motivation. Morale. Growth. Psychological safety. The politics of three strong-willed PMs who each think they're right. None of it applies to an agent, which has no career to nurture, no ego to manage, and no Tuesday where it's just having a bad day. Delete that entire surface and a huge fraction of the leadership job evaporates.

But the fleet demands things a human team never does. A high-agency human you can under-specify on purpose — hand them a vague mandate and trust judgment, context, and culture to fill the gap. Do that to an agent and it fills the gap confidently and wrong. So the work that disappeared on the human side reappears, transformed, on the agent side: explicit written context where a person would have inferred it, permission scoping where a person would have used discretion, observability where a person would have just told you something felt off. That's not people leadership. That's platform engineering — and the leader who walked in expecting the former is unprepared for the latter.

Failure is bounded by permissions, not conscience

A human PM's worst day is bounded by competence and conscience. They can be wrong, but they know what they don't know, and they won't email the company's financials to a stranger because a website told them to. An agent's worst day is bounded only by what you let it touch. The horror stories aren't exotic — a deleted inbox, a wrecked calendar, a deploy to production nobody asked for. The cap on the damage isn't judgment. It's the token you handed over.

That single fact moves fleet management out of the people-leadership discipline entirely and into the neighborhood of security and operations. You don't manage blast radius by coaching. You manage it by scoping, by read-only-until-proven, by threat-modeling the prompt injection that arrives the moment your agent reads an email or a web page. None of those are skills a Product Leader was hired for, and none of them get better with the empathy that makes them good at the human job.

One leader, three jobs

So can a single Product Leader hold all of it in an ordinary week? In the short term, yes — the fleet is small, the function doesn't exist yet, and a strong leader will absorb it the way strong leaders absorb everything. But it's unstable, for two reasons that compound: cadence, and a third job hiding underneath the first two.

Start with cadence — though not the way it's usually told. A leader switching registers all day is nothing new: board-prep alignment in the morning, a hard 1:1 after lunch, a budget review after that. Juggling modes across a layered org is the job, and good leaders are selected for it. What's new isn't the variety, it's the rhythm. A human org produces discrete artifacts that arrive on a human cadence and wait for your next meeting; you can batch your attention to them. A fleet doesn't wait. It produces a continuous stream of output to verify and a continuous stream of breakage to repair — crons fail, context drifts, an agent forgets a thing it knew yesterday — and none of it queues politely for your one-on-ones. The load isn't hard because it's unfamiliar. It's hard because it never stops and never batches into the meeting-shaped week management is built around.

And "both" was always the wrong count. Set the fleet aside entirely: a Product Leader's first job was never managing PMs — it was alignment, getting a room of executives, peers, and the managers beneath them pointed the same way. I've argued elsewhere that this is the one piece of the work you cannot hand to a model — "You Can't Generate Alignment." Executives are professional slop-detectors; a fluent, AI-authored strategy doc reads to them as doesn't understand the problem and gets filed as noise. Alignment is made in the room, by a person, through judgment about who can hear what and when. It doesn't compress, it doesn't parallelize, and no fleet lifts it off your desk. So the honest count is three jobs, not two: generate alignment among humans, grow and direct the humans who report to you, and operate-and-verify the fleet — and the first two are precisely the ones the agents cannot relieve.

The obvious retort is delegation. Leaders have never carried everything themselves — that's what directors and group managers are for, and a VP runs a layered org precisely so no single person holds it all. True, and it's the right instinct. But delegation only dissolves the load when there's a layer to delegate into, and here only one of the three jobs has one. People-leadership pushes down the existing hierarchy, manager to manager, the way it always has. Alignment doesn't push down at all — it's level-locked: a director can't align the VP's peers, so you own the alignment at your own altitude and have no one below you to hand it to. And fleet operations is new work with no box on the chart to receive it — no director of fleet ops, no team that owns the verification harness, no one whose whole job is the always-on load. So it isn't delegated; it defaults to whoever is standing closest, usually the product leader, not because they should run it personally but because the org chart has nowhere else to put it. That's the unicorn the chart is quietly sketching — not a person heroic enough to do all three at once, but an org design that pretends the newest of the three jobs already has a home. It doesn't. There is no such animal.

The failure mode is predictable. Under that three-way split, the quiet jobs starve. Either the humans get a distracted manager, the alignment that needed a real conversation silently doesn't happen, or — more dangerously, because it's the easiest to miss — the fleet gets under-verified, and the wrong thing ships at volume before anyone notices. Which is the exact migration I described in "When Execution Becomes Abundant": when execution stops being the constraint, the constraint doesn't vanish, it moves — here, to the work of governing and verifying the fleet that does the executing. That's a function. It is not a thing a busy people-leader does in the cracks, on top of the room they still have to align.

Split the job

The org design answer is not a better leader — no amount of individual horsepower fills a seat that isn't on the chart. It's a different shape.

Don't centralize the fleet in the leader — push it down. The most realistic near-term structure is each high-agency PM running their own sub-fleet, so the Product Leader still manages humans who each manage agents. Leadership stays human-to-human, where the relational craft actually pays — and where the alignment work lives, the part no agent will run for you — and the agent-ops load distributes to the people closest to the work. The PM's job widens to include managing a hybrid team. The leader's job doesn't bifurcate; it stays recognizably itself.

Make verification an independent function with teeth. Whoever sets the intent should not be the only one confirming the agent honored it — that's marking your own homework at machine speed. This is the coherence-review function from "When Execution Becomes Abundant," generalized: a role that can sample fleet output against the product model, halt a work stream, and require a decision. Without the authority to stop things, it's documentation of drift, not a remedy for it.

Own the context as shared infrastructure. The agents' operating model — the soul, identity, and tools files Vo edits by hand; the gold-standard set; the pruning discipline that deletes stale context before it becomes a landmine — is an org asset, not a per-PM hobby. That's the product backplane under another name. Someone owns it, and ownership is a leadership-level decision because a change to shared context propagates to every active stream at once.

Name the role nobody's hiring for. There's a missing seat on most org charts: the owner of fleet operations — specification standards, the verification harness, permissioning, observability, cost. Engineering already invented this role once. Site reliability engineering — the discipline of keeping a running system alive, as opposed to building it — split off from software development when operating at scale became too different from building to stay one job. Product leadership is heading for the same split: setting product direction and operating the fleet that executes on it are diverging into two jobs, and only the first is currently staffed. Call the second one whatever you like; an engineer would call it the SRE of PMs.

The honest caveat

None of this has been run at scale, because fleets of this maturity managed alongside human product teams barely exist yet. These are structural answers to a structural fact — the resemblance between the two jobs is genuine and the divergence underneath it is genuine — but which functions prove load-bearing, which prove unnecessary, and where the real failure modes hide will be learned by doing it, not by reasoning from outside. What I'm confident in is the shape of the problem, not the precise furniture.

What I'd bet on is the direction. The Product Leaders who hear that running agents is not "much different than managing a remote team" and relax are taking on a new job — operations, verification, security, context governance — under the impression that it's a job they already know. But the plate was never one job, or even two. It's three: generate alignment, lead the humans, run the fleet — and the agents take none of the first two off it. They'll do all three at half strength, and the parts that fail first are the quiet ones: the alignment that never quite happens, the PM who needed an hour, while the fleet that's visibly on fire takes the day. The ones who pull away will be the ones who saw early that the fleet didn't make product leadership scale. It split the work into two tracks — a human one no agent will ever run for you, and a platform one nobody was hiring for — and built both before the under-verified work, or the un-aligned room, had a chance to cost them.

Managing agents isn't managing people. It's the other job, wearing the same title.

Source. The "nine agents" setup and the line about managing them are drawn from Claire Vo's power-user guide to OpenClaw — written by Vo and narrated by Lenny Rachitsky on Lenny's Reads, "OpenClaw: The complete guide to building, training, and living with your personal AI agent," YouTube, published April 1, 2026: youtube.com/watch?v=D-gqpIv-Mr0. Quotations are transcribed from that episode and lightly punctuated for readability. I have no relationship with Claire Vo, Lenny's Newsletter, or the makers of OpenClaw. References to "You Can't Generate Alignment," "When Execution Becomes Abundant," "The Best Context Isn't the Most Context," and "The PM Who Never Wrote a Test" are to my own essays in this series.