AI Agents Require Operators, Not Just Builders. Get Ready.
Shipping products used to be the finish line. It's now the start.
Product management has long relied on running loops: build, ship, measure, iterate. PMs scoped a feature, shipped it, watched the numbers, evaluated what to build next. The key assumption in that loop was that the feature largely sat still: if you built an onboarding page, that page was the same two weeks later. If something upstream broke, it broke loudly — an error, a crash, a support queue lighting up. You went and fixed it. The work was a sequence of finished things, each handed off before the next began.
An agent doesn’t sit still.
If your product team was in the business of building metaphorical wooden toy ships, the AI agent is the equivalent of taking those ships out of the dry dock and launching them in the water, headed toward an open sea with constantly surging waves and uncertain weather. A ship cruising on a calm day might encounter a raging storm the next.
The core mission of the product team for the past several decades was to build. Build and ship. Ship, then build the next feature, and so it went. Yet building and operating are different relationships to the work. Operating means keeping a hand on the wheel: the ship is structurally complete, but without someone at the helm you can’t be sure it will survive.
And so AI is dragging the product manager’s job from the builder’s relationship toward the operator’s, because what you ship keeps running and keeps drifting.
The moment your team ships an AI agent, everything around it keeps moving. Customers ask it things no test anticipated: new intents, new edge cases, questions about a product line that became outdated last month and that nobody recalibrated it for. The model underneath it changes without asking you; the provider updates it quietly, and a thing that behaved one way on launch day behaves another way a month later, untouched by your hand. And every new capability you add doesn’t sit politely beside the old ones. It changes how the whole system behaves, because the parts interact.
What’s worse, agents fail quietly.
Deterministic software fails loudly. It throws an error, falls over in a way that trips an alarm and points at the line that broke. An agent degrades quietly. It keeps returning fluent, confident, plausible answers that are slowly getting worse, and every infrastructure light stays green while it does: latency fine, uptime fine, cost fine.
Instead of ship-and-measure and the occasional point-in-time feedback loop, the job becomes continuous evaluation. You don’t evaluate the agent once and move on. You watch it, because it will drift, and it will not tell you.
A team ships an external customer-support agent, the thing that reads an incoming ticket and answers it without a human. Launch day, it resolves sixty percent of tickets on its own. The demo is clean, the metrics are green, the deck goes up. The PM who built it proudly declares it done and moves to the next feature.
Six weeks later the dashboard still says sixty percent resolved. But the rate at which a human has to reopen a ticket the agent “resolved” and quietly redo it has doubled. Customers are getting confident, wrong answers about the product line that shipped last month, which no one had recontextualized the agent for.
You could object that none of this is new. Support teams have watched these systems for years, and the old rule-based bots failed too. True — but they failed the way machines fail. Something broke, in a specific place, for a traceable reason, and the same input failed the same way every time until you fixed it. An AI agent doesn’t fail the same way every time. There is no obvious break; the quality just thins, unevenly and quietly, for reasons that don’t resolve to a line someone can go find. The old systems failed like a snapped cable. These drift like a current.
For most of software’s history, the riskier the system, the harder you froze it: you don’t push weekly updates to an x-ray machine or a rocket; you certify a finished artifact and ship it, precisely because lives ride on it not changing. Agents break that bargain. Companies might license and freeze a fixed version of the model, but they can’t freeze the world the model runs against. The inputs are effectively infinite, and certification can only test the slice you thought to write down. This means the highest-stakes deployments are the ones where the vigil stops being good practice and becomes the only safety you have.
Build is an event. Operate is a vigil.
The PM who operates agents has stopped waiting for an alarm and started reading an instrument — and when a system can’t break loudly, the instrument is the only thing standing between you and a slow, invisible decline. It’s the whole reason drift gauges stop being a nice-to-have.
The daily focus changes as well. A builder opens the laptop and asks what they’re making today. When a builder gets faster, they ship more features — and applying a builder’s mindset to AI is exactly what produced the term “AI slop.” An operator opens the laptop and asks what their system is doing today, and where it’s starting to drift. When an operator gets faster, a living system holds together under more load.
The ship your team launched is already past the breakwater. It is well-built; that was the outcome of your skilled team of builders. But the sea it’s in changes by the hour, and the only thing between a good crossing and a wreck is whether someone is at the helm — reading the water, correcting for a drift no instrument will announce on its own. Sailing the ship is the objective of the decade ahead, and the product managers who understand the difference will keep their ships off the rocks. The ones still admiring the hull they built won’t notice the water until it’s over the deck.
Next in this series: You can hand off a finished artifact and walk away, but you can’t walk away from a system that’s still alive. Managing the operators — why leading the people who run these systems is a different job than running the systems, and the one the last decade of org design left us worst prepared for.