An agentic AI operating model is the set of decisions that says who owns an AI agent, what counts as success, how much the agent may do on its own, how it changes over the years, and who carries the legal duties. Seven of them belong before the first agent takes over a process.
Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, and gives three reasons: escalating costs, unclear business value and inadequate risk controls (press release, 25 June 2025). A better model fixes none of the three. They are decisions nobody took before the budget went out.
The difference to the copilots most companies run today is that an agent acts. It plans steps, calls systems and changes records, where a copilot drafts something for a person to accept. As long as a human executes every step, unclear ownership costs little. Once the agent executes, every open question about responsibility, limits and liability becomes a question about something that has already happened.
MIT Sloan Management Review and BCG surveyed 2,102 executives for "The Emerging Agentic Enterprise" (November 2025). 76% of them see agentic AI as more like a coworker than a tool, and 66% of organisations with extensive adoption expect their operating model to change, against 42% of those with no plans to adopt. One of the study's recommendations is to build centralised governance infrastructure before deploying autonomous agents (PDF).
That is the operating model, and models, vendors and pilots will change on top of it for years. In practice it comes down to seven decisions per process.
The seven decisions at a glance
| Decision | The question the board answers | Settled when |
|---|---|---|
| Value and stop | What counts as evidence that it works, and which number by when means stop? | the metric, the baseline and the stop date are written down |
| Ownership | Who owns the agent and can switch it off alone? | a named person has that authority, at any hour |
| Autonomy and safeguards | Which level of autonomy per task, and where does reversibility end? | every task has a level, every irreversible step a human gate |
| The process you run today | Does the agent, with its safeguards, beat what you actually do now? | the current process is measured, not remembered |
| Evolution | How does the agent change over the years without being rebuilt? | every change passes fixed test cases before it goes live, there is a way back, and the end of support is planned |
| Governance and obligations | Who carries which duty under the AI Act, the CRA and the Machinery Regulation? | each duty has an owner before the architecture is fixed |
| Partner and exit | Build, buy or platform, against which specification, with which way out? | the specification exists before the selection, the contract can be exited in stages |
Value and stop: decide what counts as evidence first
The metrics a company already has were built for a different unit of work. An agent that triages service requests for a machine builder can close more tickets and still leave unplanned downtime where it was. If tickets closed is the yardstick, the project reports success while the customer sees no difference.
So the first decision is what will count as evidence, measured how, and against which baseline. The second half is the one that gets skipped: which number, by which date, means the pilot stops. Without it, a pilot that does not hold up gets extended instead of ended, and that is how the escalating costs in Gartner's list come about.
Ownership: one person who can switch it off
Every agent needs a named person who is accountable for what it does. MIT CISR describes a telecoms operator where no AI agent is deployed without a named business owner accountable for its outcomes (Designing Decision Rights for AI, June 2026).
The test is narrower than a job description: can this person switch the agent off, alone, at three in the morning? If switching it off needs a ticket to IT and a meeting, the company has appointed a coordinator, and the agent runs unowned whenever something goes wrong at night.
Autonomy and safeguards: the gate goes where reversibility ends
Autonomy is set per agent and per task, on a scale from constrained to autonomous, alongside four safeguards: hard constraints, verification of the output, reversibility built into the design, and an escalation path. MIT CISR comes at it from the decision side: it sorts decisions by ambiguity and risk and gives each type a mode, automate, manage, enable or lead.
The criterion I would keep if everything else went: put the human gate exactly where reversibility ends. Not where the risk feels highest, and not where the model looks weakest, because both move with the news. In the Ergon pilot I run for small businesses in Greece, the agents draft copy and rebuild unpublished pages without asking anyone. They prepare a tax submission and never file one, however confident they are, because filing cannot be undone.
In industry, reversible has to mean the consequence can be undone, not the transaction. A parameter change on a connected machine can be rolled back. A shift of out-of-tolerance parts that has reached the customer cannot.
The process you run today is the yardstick
The fair comparison is the agent with its safeguards against the process you actually run, not the agent against perfection. The current process is rarely as good as people remember. It leaves no audit trail and it depends on who was on shift.
The comparison cuts both ways, which is why it holds up in front of a board. It also forces the company to say where the agent is worse. Without it, the status quo wins by default, because it is the only option nobody ever measures.
Evolution: the agent has to outlast its first model
The model an agent runs on today will be replaced while the agent is still in service. Providers retire model versions on a published schedule and change their interfaces, and a newer version can answer the same request differently. An agent built around one model gets rebuilt when that model goes, and if the model is swapped without a test, the agent in production is no longer the one that was signed off.
So the fifth decision is how the agent changes without being rebuilt. The model, the instructions and the tools the agent calls carry versions. A fixed set of test cases, drawn from the process measured before the pilot, has to pass after every change before it goes live. There is a way back to the last version that passed, and a planned end of support. The connections to data and systems belong to the company and are built so that a change of provider replaces the model, not the integration.
Industry already expects this of connected products. A device in the field is updated over the air, in stages, with a way back if an update fails, and under the Cyber Resilience Act within a support period stated when the product is sold (ten checks for an IoT stack under the CRA). The decisions about an update path are cheapest before the first campaign (why OTA stops being optional), and the same holds for the first agent. For AI models on edge devices, that discipline barely exists yet (edge AI model lifecycle management).
Governance and obligations: who carries which duty
Which duties apply depends on the company's role and the agent's purpose. Under the AI Act, whoever develops an AI system, or has it developed, and places it on the market or puts it into service under their own name, including for its own use, is a provider, with obligations that differ from those of a deployer who only uses it, and an agent in a high-risk use has obligations that an agent in purchasing does not. If the agent becomes part of a connected product, the Cyber Resilience Act adds the manufacturer's security duties for that product. And under the Machinery Regulation, which applies from 20 January 2027, safety components and machinery whose safety functions rely on self-evolving, machine-learning behaviour need a conformity assessment by a notified body (Annex I, Part A).
None of this should arrive as a blocker in the last sprint. Each duty gets an owner before the architecture is fixed. In European industry, where the customer carries the liability if a supplier cannot show how a decision was made, governance that can be audited is something to sell.
Partner and exit: specification first, a way out in the contract
Build, buy or platform is decided per process, on three questions: how close the process is to the core of the business, which data and systems the agent has to reach, and what the company will still be able to change in three years.
The specification comes before the selection, and the acceptance is signed by someone who earns nothing from the contract. A pre-study done for free by the integrator who will later sell the implementation is paid for out of that implementation. The contract should allow an exit in stages, so that a pilot that misses its stop number ends without the company being locked into the platform it ran on.
What comes out of it
The result of the seven decisions is a board paper, not an architecture document. It says whether agentic AI pays for this process, build or buy, who owns the agent, where the human gates sit, what the stop criterion is, how the agent is changed and retired, and who carries which duty. A reasoned no is one of the possible results, and often the cheapest.
I work through these seven decisions with industrial companies and investors as a four-week audit, before any partner is selected: agentic AI consulting. Where the questions come from: what I took away from the MIT programme on agentic AI.