Ask how much of product discovery an agent can take over, and you'll get a number back. Half the work. Most of it. None of the part that counts. Everyone has a figure, and the figures don't agree, because the question is measuring the wrong thing. It counts steps. Discovery isn't a pile of steps an agent either can or can't perform. Every step in it is two different jobs wearing one name — and an agent is brilliant at one of them and barred from the other.
The two jobs are the labor and the gate. The labor is the producing: the research read, the problem statement drafted, the options laid out, the prototype built, the criteria written. The gate is the deciding: this is the problem we'll commit to, this is the direction, this evidence is enough to build on. Agents are already doing most of the labor. They own approximately none of the gates. Once you see discovery that way, the panicked question — how many of my steps does the machine take? — dissolves into a better one: which parts of my job were labor I can hand off, and which were judgment I was never supposed to delegate in the first place?
The node is the wrong unit
Take any node on the discovery loop and pull it apart. "Problem Definition" sounds like one task. It's two. There's the work of gathering the signal, clustering the complaints, drafting three candidate framings, and pressure-testing each for scope — and there's the decision of which framing the team will actually commit its quarter to. An agent can do the first today, faster and more thoroughly than a tired PM at 4 p.m. It cannot do the second, and not because it lacks the horsepower. It lacks the standing.
This is why "what percentage of discovery can agents do" produces nonsense answers. Measured as labor, the number is high and climbing. Measured as decisions, it's near zero and staying there. Both are true at once, because they're answers to different questions about the same node. The node was never the atom. The atom is labor-or-gate, and they come apart cleanly the moment you look.
What the agents can run
Walk the line and the pattern holds at every station.
At the front, signal is monitoring work — watch the metrics, mine the support tickets, cluster the inbound, surface the patterns a human would miss. An agent is good at it and getting better. Problem definition and solution design are generative: draft the framings, enumerate the option space, build the trade-off matrix, argue against each option in turn. This is squarely in an agent's strength. Designs and the prototype are production — interaction models, interface drafts, and a working, testable artifact built in the same environment engineering uses. The prototype node is the one product teams already hand to an agent without flinching; it's the heart of how this way of working started. And acceptance criteria are generation from validated intent, structured enough to be built against. An agent produces them readily; the hard part was never the writing.
That's most of the line. The labor across five of the seven nodes is already agent-dominated, and the trend on all seven points the same way.
The two that resist are the two that touch the outside world. Signal and validation both require contact with real people — customers who are annoyed, stakeholders who are unconvinced, users who do something nobody predicted. An agent can run an unmoderated test, synthesize the transcripts, and draft the readout against the four product risks. What it can't do is be in the room, feel which objection is the one that matters, or carry the political read that tells you a stakeholder said yes and meant no. The cap on those nodes isn't intelligence. It's access — to people, and to the standing to act on what they said.
What doesn't move
Now the other half of every node, the half the agents don't get.
Engineering has a trick product doesn't: a test. When a coding agent finishes, a suite of checks can decide, mechanically, whether the work is acceptable — does it pass, do the types hold, did anything regress. That verdict is real and it's cheap, which is exactly why engineering can push toward letting agents merge their own code with a human barely in the loop. There is a machine that says yes.
Discovery has no such machine. Nothing compiles a problem statement and reports whether it was the right problem. No suite confirms that the direction you chose beats the three you didn't, or that the evidence clears the bar to commit a team. The ground truth for discovery lives outside the repository entirely — in the market, in the customer, in whether the thing you build turns out to matter. You don't get that verdict for weeks, and by then you've already spent the engineering. So the decision to cross from discovery into delivery can't be automated the way a merge can. Someone has to own it, on incomplete evidence, and be accountable when it's wrong.
That someone is the gate. There are roughly three that decide everything: which problem the team commits to, which direction it builds, and whether the validation is enough to cross into delivery. Hand those to the agent and you haven't scaled your discovery — you've automated the one part that carried the weight and kept doing the part that was always cheap.
The line moves; the gates don't
The honest caveat is that the line is still moving, and it's moving toward the agent. Give these systems real browser and computer control and they'll run their own unmoderated studies, recruit their own test panels, and push even validation's labor off the human's plate. The fraction of discovery's grunt work an agent can do is heading toward all of it.
The ownership isn't moving at all, and it isn't a capability gap that a better model closes. It's structural. As long as discovery's ground truth lives in the world rather than in a test, the gate decision stays with a person who can be held to account for it. So the two counts diverge over time: the labor an agent can run climbs toward seven nodes out of seven, and the decisions an agent can own stays near zero. The same system you'd trust to run the entire line is the one you must not let hold a single gate. That sounds like a contradiction. It's just the difference between a job that has a test and a job that doesn't.
What to do now
Stop delegating discovery by the node. The node is the wrong unit, and "let the agent take problem definition" smuggles a gate decision into a labor handoff.
Separate the line from the gates, explicitly, on paper. For each node, write down which part is labor the agent runs and which part is the decision you keep. The act of separating them is most of the work; it's where you discover how much judgment was hiding inside tasks you thought of as production.
Put your scarce attention only at the gates. Three decisions carry the loop — the problem, the direction, the cross. Spend your hours there, in front of customers and stakeholders, and let the agent run the line between them. This is the discovery mirror of how the best engineering leads already operate: they don't watch the keystrokes, they hold the invariants.
Make the gate criteria legible before you need them. What makes a problem worth committing to? What evidence clears the bar to build? If those live only in your head, you can't staff the gate to anyone else, and you become the bottleneck the agents were supposed to relieve.
Staff for judgment, not for labor. A discovery team in this world isn't measured by how many artifacts it produces — the agent produces those. It's measured by the quality of the calls at three gates. Hire and promote for that, because that's the job now.
Agents run the line. Humans hold the gates. The mistake isn't trusting the machine with too much of the work — give it the whole line, it's earned it. The mistake is letting the speed of the line fool you into thinking the gates moved too. They didn't. There's no test for the right problem, and until there is, the decision to build it is still yours to answer for.
Source. This piece was triggered by Ryan Lopopolo (OpenAI), "Harness Engineering: How to Build Software When Humans Steer and Agents Execute," a talk delivered at AI Native DevCon and published on the AI Native Dev YouTube channel, June 19, 2026: youtube.com/watch?v=c8bE0cj7vHY. Lopopolo's argument that the human should hold "invariants and interfaces, not keystrokes" describes the delivery loop, where a test can render the verdict; the claim here is that discovery inverts the economics, because its verdict lives outside any test. The extension, and the labor-versus-gates framing, are my own. All characterizations of his remarks are drawn from that talk. I have no relationship with OpenAI, AI Native Dev, or the conference.