By Mario Mayerle
Imagine a team arriving on Monday to find that its agents have produced twenty pull requests over the weekend. That sounds productive until someone asks which changes solve an agreed problem, which can be evaluated quickly, and which are ready to reach customers. The answers determine whether the team gained capacity or inherited a queue.
The operating question I would put in front of a product leader is simple: how much agent-generated work can your team accept with adequate evidence and a clear owner?
McKinsey’s August 2026 article offers a useful starting point. In a May survey of 334 product and engineering respondents, the director-and-above subset comprised 173 people. Within that subset, 25 percent reported that more than a quarter of their teams had achieved productivity gains of at least twofold; 30 percent reported declining team productivity. These are reported outcomes, not a controlled experiment establishing causality. Read the McKinsey article.
My reading is that leaders need a more useful unit of progress than an artifact produced. I would use an accepted change: work that addresses the intended problem, meets agreed conditions, and has an accountable decision behind its release.
Consider a hypothetical assignment: “Improve the account invitation experience.” An agent could interpret that as a visual redesign, a shorter form, new reminder emails, or a change to invitation expiry. Each interpretation could produce convincing work. Each would also create a different review burden.
Before delegating that task, I would narrow the problem to something observable: invited users cannot tell whether an invitation has expired. The assignment becomes “Make the expired-invitation state understandable and provide an approved recovery path.” That gives the agent a defined problem and gives the reviewer something specific to judge.
The brief should then name what may change. In this example, the agent could modify the interface text and the relevant view, while preserving invitation lifetime, account permissions, and email delivery behavior. If a useful fix requires changing one of those boundaries, the agent should return the dependency for a decision. This makes an unexpected discovery actionable without quietly enlarging the assignment.
I would also ask for a compact evidence package. It would show the original failure, the revised behavior, the checks performed, and anything still unverified. A reviewer should be able to understand the change without reconstructing the agent’s entire working session.
A proposed workflow: define the outcome and boundaries, execute within scope, inspect independent evidence, and make an accountable acceptance decision.
Evidence needs to challenge the work. Suppose the agent changes the expired-invitation screen and writes a test that checks whether its new text appears. That test can pass even if the screen offers a recovery action the user cannot complete. I would want a separate check of the full recovery path, including what happens when a user follows the link with an expired invitation.
For this assignment, useful evidence might include the expired state, the valid state, and the recovery result. Existing permission checks should still hold. The person accepting the change would compare those results with the brief, then decide whether the remaining uncertainty is acceptable. An attractive screenshot answers only part of that question.
This approach has a cost. Writing a brief, maintaining checks, and reviewing evidence take time. Requiring the same process for a spelling correction and a permissions change would waste attention. I would scale the evidence to the consequence of failure and the difficulty of reversing it. A team needs a lightweight path for small changes and a more demanding path when the stakes justify it.
The same discipline should apply to measurement. For an initial trial, I would select one recurring class of work, such as correcting clearly defined interface defects. Compare similar tasks and record the time from assignment to acceptance, human review effort, rework, and defects found after release. Record model and tool costs alongside human effort. Keep unfinished and rejected attempts in the record so that successful cases do not hide the cost of the rest.
A useful operational measure is total delivery cost per accepted change within that task class. It is imperfect: two changes can have different complexity and customer value. That is why I would avoid comparing unrelated work or treating a cheaper change as automatically more valuable. The measure helps expose whether faster generation actually reduces the effort required to deliver something acceptable.
The trial should also examine where work waits. If implementation gets faster while review time rises, the next investment may belong in clearer requirements, smaller changes, or better evidence presentation. Adding another agent would be a hypothesis to test, not the default response.
Over several comparable tasks, this produces a practical basis for delegation. A team can identify assignments that arrive with usable evidence and require little correction. It can also identify assignments that repeatedly return unresolved decisions. Those patterns should guide where autonomy expands and where the task definition needs more work.
For the next agent-assisted assignment, write down what would make the result acceptable before execution begins. Then inspect whether the returned work makes that decision easier. That is a concrete test of whether your team is building delivery capacity.
Source: McKinsey, “Beyond the copilot: Scaling the agentic product development life cycle,” August 21, 2026. The invitation example and suggested trial above are practical proposals, not findings from that research.
If you are defining how people and agents should share responsibility, explore the proposal behind INOSX AgentOS with your own acceptance criteria in mind. You can also visit INOSX and find more of my work at Mario Mayerle.
#AgenticAI #ProductDevelopment #EngineeringLeadership #INOSX #AgentOS