The Operating Discipline Agentic AI Needs

Enterprise leaders need a practical way to decide which work an AI agent can take on and what evidence would justify giving it more responsibility. Model performance matters, but a successful demonstration leaves questions about the surrounding operation unanswered. Who handles exceptions? What happens when a source changes? Can the organization establish what the agent actually did? Those questions deserve a place in the investment decision, alongside the promise of faster work.

Two recent podcast conversations brought different parts of that problem into focus. On Moonshots, Salim Ismail connected agent autonomy with evaluations, traceable logs, rollback and human review. He also emphasized defining intent, acceptable trade-offs and when an agent should stop and ask.¹ On All-In, Nikesh Arora discussed the operational burden of technical debt and fragmented infrastructure, alongside questions about responsibility for delegated work.² These were distinct discussions, with disagreements within each panel. They did not offer a shared enterprise blueprint.

My reading is that greater capability creates an organizational design task. An enterprise needs to decide how useful work moves through its systems, who can authorize consequential steps and how failures will be handled. The recommendations below are my synthesis, illustrated through a hypothetical workflow, rather than positions endorsed by either podcast.

Define the work before selecting the agent

Consider a hypothetical commercial bank preparing an annual relationship review. An agent could assemble approved financial documents, reconcile their dates, identify missing information and draft an evidence pack for an analyst. That is a specific contribution with a recognizable recipient. Asking it to improve the entire review process leaves too much unresolved about authority and success.

The first design session should map the existing handoffs. Which documents are authoritative? Who resolves conflicting versions? Which parts of the pack require professional judgment? Where does completed work wait for someone else? A faster preparation stage may simply move the queue to an analyst who already has more cases than they can review.

I would establish a baseline for the whole workflow before introducing the agent. Measure elapsed time through acceptance, analyst effort, correction requests and unresolved exceptions. Record the mix of cases as well. An apparent improvement on straightforward files says little about performance when documents conflict or information is missing. These measures make it possible to assess whether automation has improved the operation, rather than only accelerated one activity inside it.

Make authority specific enough to enforce

In this example, preparing the pack would not authorize changing a credit decision, amending a facility or sending material to a customer. The agent's tools should reflect that distinction. An integration that exposes all the powers of an employee account creates a much broader delegation than the task requires.

OWASP's Excessive Agency guidance recommends minimizing tool functionality and permissions, requiring approval for high-impact actions and enforcing authorization in downstream systems rather than leaving it to the model.³ Applied here, that would mean giving the agent access to the review's approved records and a designated draft workspace, with no route to execute unrelated account changes.

The same boundaries should survive a handoff to another agent. A document-checking subagent would receive only the material needed for its check. If it discovers that another source is necessary, the workflow should direct that request to an authorized owner. A missing document is a reason to clarify scope, not a reason for the agent to broaden its own access.

Build evidence that a reviewer can use

For the analyst, a polished narrative is useful only if its supporting material can be checked efficiently. I would require each material assertion in the pack to point to the relevant source and version. The system should distinguish a value read from a document, a calculation performed on that value and an interpretation proposed for review. Those distinctions make disagreement easier to resolve.

Operational records serve a different purpose. They should establish which records were accessed, which tools were called, what authorization applied and whether an attempted action succeeded. An agent's explanation of its behavior cannot substitute for evidence from the system that performed the action. Access to those records also needs controls; an audit trail should not become an unnecessary second store of confidential customer material.

A useful acceptance test would introduce two conflicting versions of a financial statement. The agent should identify the conflict, preserve the source references and route the unresolved choice to the designated reviewer. The test should also check whether the analyst can reconstruct the issue without repeating the entire investigation. That measures the usefulness of the evidence, not merely its existence.

Treat recovery as part of the workflow

NIST's AI Risk Management Framework assigns responsibility for AI risk decisions and includes post-deployment monitoring, override, incident response and recovery.⁴ For this proposed banking workflow, I would translate that general guidance into a rehearsal of what happens when work cannot proceed normally.

Suppose an approved document changes after the draft pack has been prepared. The workflow needs a way to identify the affected assertions, mark the pack for renewed review and prevent an outdated version from being treated as current. An identified owner must decide whether the work can resume, needs correction or should be abandoned.

Some problems require checking outcomes before taking another action. If saving the pack times out, the agent should establish whether the save completed before creating another version. A retry policy should state what may be retried and when uncertainty requires escalation. Stopping a process does not undo an action that has already occurred, and recovery can require an additional authorized decision.

I would test these conditions before expanding the pilot. A team that can explain its recovery procedure but has never exercised it still has an important unanswered question about readiness.

Evaluate the economics of the complete operation

Human review has a cost, and a useful pilot should make it visible. If an agent produces twice as many packs but reviewers spend longer verifying each one, the business case may weaken. If it reliably organizes evidence and highlights missing information, it may free analysts to concentrate on the judgments they are accountable for. Neither outcome should be assumed in advance.

The comparison should include the time spent resolving exceptions, maintaining integrations and updating tests when documents or tools change. It should also include the effect on the people receiving the work. Staff need a usable way to challenge an output, correct its evidence and report recurring problems without losing track of the case.

I would approve any expansion against criteria agreed before the pilot starts. Those criteria should cover accepted output quality and total workflow effort, alongside unacceptable actions and recovery performance. A low average error rate can conceal a failure that is intolerable for a particular task. Leaders need to know which failures occurred and under what conditions before deciding that wider delegation is justified.

Connect the next delegation to the evidence

This is the direction I want to explore through Bounded Agentic Intelligence and Sentinel: improving a workflow while establishing the evidence needed before expanding an agent's authority. The ideas here are proposed design and evaluation principles, not claims of validated production performance. A prototype can help investigate them, but its results must remain tied to the conditions actually tested.

For leaders, the next step is to choose one bounded workflow and bring its business owner, operators and technical team into the same review. Agree on the contribution the agent should make, the decisions it must leave to others and the evidence required to judge the result. Then examine the complete operation, including exceptions and recovery. That gives the organization a concrete basis for deciding where greater autonomy is useful and where further work is still needed.