Imagine a product team starting its morning with a queue of changes prepared by AI agents overnight. The code is ready. Tests are green. Every change includes a confident explanation. The team still has to decide whether those changes solve the right problem, respect the agreed boundaries, and belong in the product.
That morning review is where I would begin designing an agentic operating model: the practical rules for assigning work, granting permission, evaluating evidence, and accepting responsibility. Before increasing how much agents can do, leaders need to decide what would make their work acceptable.
McKinsey’s August 2026 article offers a useful reason to examine this carefully. Its May survey included 334 product and engineering respondents. Among the 173 respondents at director level or above, only 25 percent reported what the researchers classified as meaningful AI acceleration: more than a quarter of their teams achieving productivity gains of at least twofold. These are reported outcomes, not a controlled demonstration that a particular management practice causes improvement. Source: McKinsey.
My reading is that organizations need a more precise way to discuss autonomy. “Our team uses agents” tells us very little about which decisions those agents may make. A team might allow an agent to edit documentation freely while requiring a named engineer to approve changes to customer data handling. Both assignments use the same technology. They call for different authority.
I would therefore attach autonomy to a specific assignment. Its boundaries should follow the consequences of that assignment, the evidence available to assess it, and the organization’s ability to recover when something goes wrong. A successful task earns a review of those boundaries; it does not automatically justify broader access.
Consider a hypothetical customer export bug. A customer reports that an export omits records when a selected date range crosses the end of a month. The desired result is concrete: the export contains the correct records for the requested period, and the customer can complete the task.
For an initial trial, I would let an agent inspect the relevant code, reproduce the issue using synthetic records, propose a narrow correction, and prepare a draft pull request. The assignment would exclude changing access rules, deleting records, or deploying to production. If the investigation points toward any of those actions, the agent would pause and explain why the original scope is insufficient.
Before execution, the responsible engineer and product owner would agree on examples that demonstrate the intended behavior. Those examples might cover month boundaries, an empty result, and records the requesting user must not receive. Establishing the expected results first gives reviewers a reference that does not depend entirely on the agent’s explanation of its own patch.
The handoff would include the reproduction, the proposed change, the checks actually run, their results, and anything still unresolved. A reviewer could then compare the evidence with the original assignment. A passing test would answer one question about behavior; the person responsible for release would still decide whether the evidence is sufficient for the change at hand.
This example suggests five questions I would put on every initial agent assignment: What outcome are we seeking? What may the agent change? What evidence must it return? Who owns acceptance? When must it stop? This is a proposed working checklist, and its usefulness should be tested on real work.
The checklist should make a decision easier. If completing it becomes a lengthy administrative exercise for a minor change, simplify it. Repeated tasks can reuse established boundaries and acceptance criteria. A sensitive change can demand additional evidence and specialist review. The amount of scrutiny should reflect what a failure could affect.
Review capacity also belongs in the design. For the export trial, I would set a limit on concurrent assignments and name the person who can accept each result. When work starts waiting for review, that queue becomes useful evidence about the operating model. The next improvement might be a clearer assignment, a better test fixture, or a different reviewer schedule. Adding another agent would require a reason.
To evaluate the trial, I would track elapsed time from an accepted bug report to a verified resolution, including time waiting for review. Alongside it, I would record reviewer effort, reopened work, customer confirmation where available, and the cost of execution and retries. Using comparable tasks and a consistent observation window would make the comparison more informative, although a small trial would still leave uncertainty.
That uncertainty should shape the next decision. If the patch arrives faster but requires substantially more investigation, keep the scope narrow and examine the handoff. If reviewers repeatedly reject changes for the same misunderstanding, revise the assignment and its examples. If work consistently meets the agreed criteria, consider expanding one permission and observing what changes. Record the conditions under which that permission should be withdrawn.
A practical starting point is one recurring problem, one accountable owner, and a boundary everyone can explain. Establish the current process, run the bounded trial, and review both accepted and rejected work. The rejected work may reveal an ambiguity or missing dependency that a successful demonstration never exposed.
The leadership decision is how much authority the organization can responsibly support for this task, today. I would expand that authority as evidence improves, while preserving a clear route to stop, correct, and reconsider. That is an operating model a team can inspect and improve, one assignment at a time.
If you are deciding where agent authority should begin and end in your own operation, explore INOSX AgentOS with those questions in mind. You can also visit INOSX and find more of my work at Mario Mayerle.
#AgenticAI #ProductDevelopment #AIGovernance #INOSX #AgentOS