Who Owns Machine Work? The Operating Model for Agentic AI

An agent becomes an operating-model decision when it can act

An onboarding agent can finish work faster and still leave a customer with the wrong configuration, an unauthorized promise or more support work. Software can now change customer records, contact customers, alter pricing or commercial workflows, trigger transactions, deploy or modify systems and consume budget. Once it can act for the company, the company is delegating authority. Leadership must decide which outcomes improve, which commitments are permitted and who carries the consequence.

An AI assistant prepares an answer. An AI agent can interpret a goal, choose steps, use tools and act across systems. The executive question is therefore: How does the company operate when software starts performing consequential work?

That is the purpose of an Agentic AI operating model: assign the business outcome, bound delegated authority and make the resulting machine work worth operating.

Agentic AI creates machine work. Machine work needs a human owner.

The objective is better products, customer outcomes and operating economics—not the largest possible agent estate. Controls should support that result in proportion to the consequences of action.

An agent is not a digital employee

The language of “digital workers” is attractive because it makes a new technology feel familiar. It is also misleading.

A person enters an organization through employment, management, policies, access controls and established accountability. An agent does not arrive with any of these relationships. It receives a technical identity, permissions, instructions, tools, models and data connections because people designed and authorized them.

OpenAI's practical guide to building agents defines agents as systems that independently accomplish tasks on a user's behalf and distinguishes them from applications where a model merely produces an answer. The operating distinction matters: an agent can execute a workflow through tools, rather than only recommend a next step.

Autonomy is delegated authority, not a product feature. The company decides what software may do under uncertainty.

Calling an agent a worker can hide the most important fact: the machine cannot hold corporate accountability. It can execute work, but a human executive or business owner remains responsible for why that work exists, what result it should produce and which consequences are acceptable.

An agent may own a task state. It cannot own the business consequence.

Someone must own the customer and operating result

Companies can build an agent before they have decided who owns it.

Technology may own the platform. A business function may request the use case. Security may set controls. Legal or Risk may review it. Finance may fund it. A vendor may operate part of the stack. When performance degrades or an action causes harm, each party can point to a different boundary.

That is not shared ownership. It is fragmented accountability.

Microsoft's agent-identity architecture illustrates how the technical control plane is evolving: named owners, scoped permissions and access lifecycles in Microsoft Entra Agent ID. Google describes an agent registry, agent identity, policy enforcement and monitored gateways for governed agentic workloads. NIST's AI Agent Standards Initiative explicitly includes agent security and identity in its standards agenda.

These are important control-plane developments. They do not decide who is accountable for a commercial, customer or operational outcome. A registry can identify an agent; it cannot own the business outcome.

A 2026 IBM survey of 2,000 technology executives reported that two-thirds were accountable for AI systems they did not fully control. The survey highlights a management problem: an executive cannot reliably own a customer or operating result without authority over the systems producing it.

Six decisions before software acts for the company

An enterprise does not need a separate operating model for every agent. It needs one coherent way to answer six decisions whenever software receives material authority.

Decision	What must the executive know?	Design consequence
Outcome	Who owns the customer and business result?	One accountable business owner and a defined success measure
Authority	What may software commit the company to?	The smallest sufficient authority; explicit approval boundaries
Identity	Whose delegated authority produced this action?	Attributable actions and permissions with a lifecycle
Evidence	Does the complete workflow work and create value?	Test outcomes, failures and customer consequences—not just outputs
Intervention	Who can interrupt, recover and keep the business running?	Practical escalation, recovery and shutdown rights
Economics	Is the result better after all operating costs?	Full cost per successful business outcome against a simpler alternative

The six decisions reinforce one another. A named owner without observable actions cannot govern. Strong monitoring without an authority boundary only records uncontrolled behavior. A safe system without viable economics is still a poor operating decision.

Outcome: name one accountable business owner

Every material agent needs one person accountable for the customer and business result—not merely for the software running successfully. That owner must be able to change the workflow, its success measure and the decision to continue. Technology operates the platform; it does not inherit every business outcome the platform touches.

This extends AI Should Redesign Work Before It Redesigns Headcount: define the work and its outcome first. With agents, the workflow owner also owns the consequences of delegated action.

Authority: define an envelope, not a vague purpose

“Support customer service” is a purpose, not permission to act. Define which data the agent may read, records it may change, customers it may contact and budgets it may consume—and where approval is required.

Reading a knowledge base is different from issuing a refund. Preparing code is different from deploying it. The boundary should narrow as consequence, irreversibility or uncertainty rises.

The smallest sufficient authority is usually better than maximum autonomy. Earn autonomy per action class, rather than grant it as a general agent status.

Identity: make machine action attributable

Shared credentials can blur who performed an action. Enterprise AI agents need distinct, scoped identities and action records linking execution to the agent version, model, tools, permissions, user context and responsible owner. A human's credentials should not make machine execution appear to be that person's decision.

When the purpose ends or the owner, permissions or dependencies change, access must expire or be reauthorized. Registries and identity platforms support this lifecycle; the company still owns the delegation. Attribution connects architecture to operating responsibility.

Evidence: evaluate the system, not the demonstration

A convincing demo does not prove customer value or operating readiness. Evaluate complete workflows against the intended business outcome and a baseline: successful execution, prohibited actions, exceptions, reliability, customer effects, review effort and cost. Include edge cases and adversarial conditions inside the defined authority boundary.

The Industrial AI Production Readiness Model applies the same production logic. For agents, evaluation continues after launch because actions and dependencies keep changing. The question is whether the current authority still produces acceptable outcomes—not whether one model score looks good.

Intervention: design the right to interrupt

Human oversight must change an outcome or reduce risk proportionately. A reviewer without context, response time or authority adds delay rather than control. Use approval where judgment matters; use deterministic limits, monitoring and sampling where low-consequence actions justify lighter intervention.

Name who receives exceptions, who can revoke permissions or stop execution, and how affected customer work continues. Recovery may mean rollback, correction or a manual fallback; some commitments cannot be undone. A human in the loop is useful only when the human can make a difference.

Economics: measure cost per successful outcome

Token price is not agent economics. Measure full cost per successful business outcome, including model and platform use, integration, monitoring, human review, retries, exceptions, incidents and eventual replacement. Divide the total cost of operating the workflow—including failed attempts—by completed outcomes that meet the business and quality criteria.

AWS's guidance on per-request cost in agentic workloads makes the visibility problem concrete: monthly token totals do not reveal individual request cost. The executive decision goes further: compare the full outcome economics with human work or simpler automation, including customer effects and scarce review capacity.

This extends the Technology Value Economics Model. An agent that completes tasks cheaply but creates rework or delays customers has not proved its value.

Hypothetical example: B2B SaaS customer onboarding

Consider an illustrative B2B SaaS workflow. A customer requests an account configuration change to connect a data feed and activate a workspace. An agent can inspect CRM, contract and product context, choose the next step, update approved onboarding fields, send routine instructions, open an internal engineering task and consume compute budget. The same sequence can shorten time to value—or create an unsupported customer commitment and leave Operations to repair it.

The six decisions change the design:

Outcome: The Head of Customer Success owns successful activation and the customer result. Completion means a working, accepted configuration with the required checks—not merely a closed ticket.
Authority: The agent may read the approved account context, update named onboarding fields and send instructions from approved material. Contract changes, discounts, refunds, production deployments and privileged access require the relevant human approval. Compute use has an enforced budget; reaching it suspends further execution and routes the case to an owner.
Identity: A scoped agent identity links each action to the account, workflow run, configuration version and responsible owner. It does not borrow an account manager's credentials or gain access to other customers' data.
Evidence: Tests cover missing data, conflicting contract terms, duplicate requests, failed integrations and misleading input. Live measures track accepted activations, time to value, customer corrections and exceptions against the previous workflow. Faster ticket closure alone is insufficient.
Intervention: Ambiguous entitlements, security concerns or repeated integration failures route to Customer Success and the responsible technical team. The owner can stop the run and revoke access; the human team continues onboarding from the recorded state. Customer-facing commitments need correction where rollback is impossible.
Economics: Compare total workflow cost with accepted activations. Include failed runs, model and tool use, integration upkeep, monitoring, human approvals, customer corrections and exception handling. Compare with the existing human or deterministic workflow at equivalent quality.

The operating choice is then concrete: delegate routine coordination, retain human ownership of customer commitments and expand authority only where outcomes and economics justify it.

AgentOps should make management decisions possible

AgentOps is often described as the tooling layer for tracing, evaluating and monitoring agents. That is necessary but incomplete.

Operations becomes useful when its evidence supports decisions:

Should this agent retain its current authority?
Which failure patterns require a narrower boundary?
Is the owner resolving exceptions or accumulating hidden manual work?
Is cost per successful outcome improving?
Has a model, tool, data source or vendor change invalidated prior evidence?
Should the agent be expanded, redesigned, paused or retired?

The OECD's 2026 practitioner interviews in Agentic AI in organisations examine deployment and governance as organizational practices. The operating question is how those practices support accountable decisions as agents move into real workflows.

AgentOps should therefore not become another technical dashboard disconnected from line management. It is the evidence system through which business owners, Technology, Security, Risk and Finance govern machine work together.

Central control can also become a failure mode

The answer to uncontrolled agents is not unlimited centralization.

A single committee approving every experiment will slow learning and drive teams toward unregistered tools. A universal control standard can impose the burden of a high-consequence financial agent on a bounded internal assistant. A large platform programme can start before the company has one valuable workflow to operate.

Governance should establish a common minimum—inventory, ownership, identity, authority, evidence and intervention—then scale controls by consequence. Low-risk experiments can operate inside restricted sandboxes. Higher-authority agents need stronger proof and more independent control. The organization should centralize reusable capabilities and policy, not every product decision.

The operating model must make safe experimentation easier than shadow deployment.

When this model does not apply

Not every system marketed as an agent performs machine work.

If a tool drafts text for a person, cannot access material data, cannot act outside its interface and leaves the human as the active decision-maker, ordinary application, data-protection and AI-use controls may be enough. If a workflow is stable and rule-based, deterministic automation may be safer, cheaper and easier to explain. If the consequence of error is high and reliable controls are unavailable, the company should not delegate the action.

An agent is also a poor choice when:

the outcome cannot be defined well enough to evaluate;
required authority would create an unacceptable blast radius;
exceptions are frequent but hard to detect;
human review consumes the entire theoretical gain;
the workflow lacks reliable data or system interfaces;
the business cannot name an owner willing to carry the consequence;
simpler software can produce the same outcome more reliably.

The point of the model is not to legitimize more agents. It is to make a disciplined no-agent decision possible.

Questions the executive team should resolve

Before a material agent moves into production, the executive team should be able to answer:

Which business outcome has one named owner?
Which actions are delegated, prohibited or approval-bound?
Which identity performs each action, and who sponsors it?
What production evidence justifies the current autonomy level?
Which failures are prevented, detected, reversible and tolerable?
Who receives an exception, and who can stop the system?
What is the cost per successful outcome after review and failure cost?
Which dependency or model change triggers reauthorization?
When will the agent be retired if value does not materialize?

These are not questions for Technology alone. They connect product, operations, finance, security, risk and executive accountability. Answering them is part of the Technology Executive role because agent architecture now determines who—or what—can act inside the company.

Conclusion

Agentic AI creates machine work. Machine work needs a human owner. Autonomy is delegated authority. Grant the smallest sufficient authority. Measure full cost per successful business outcome.

Those five principles turn an attractive demonstration into an operating decision: delegate routine work where it improves customer outcomes and economics, keep a human responsible for the result, and retain the ability to intervene. Simpler automation or human judgment remains the better choice when it delivers the same outcome more reliably.

Do not ask only whether an agent can perform the work. Ask who owns the result when it does.

Sources and model scope

The six-decision model is an executive synthesis. Sources are linked where used; the customer-onboarding workflow is hypothetical.

About Andrei Lisikov · Operating experience · AI work redesign · Industrial AI production readiness · Technology Value Economics Model