AI in operations: how much autonomy per process
The right question is not which AI to use. It is how much autonomy to give it in each flow. A model that only reads and summarizes needs one kind of control. One that writes to your database and replies to a customer needs another. Apply the same control to both and you throttle the first while exposing yourself on the second.
Why did AI in your company stop at marketing?
Because it came in through the person, not the process. Someone opened a chat model, wrote a better piece of copy in ten minutes, and the rest of the company repeated the gesture. That is a real gain. It is just not an operational one.
The distinction matters more than it sounds. Time saved is individual: it belongs to whoever used the tool that afternoon. Productivity is the operation's, and it depends on the process existing outside somebody's head. A company where the digital operation lives in one person's memory can put AI on top of it and accelerate that person without changing the company.
That is the blind spot. AI adopted person by person produces a collection of faster individuals and the same throughput. AI adopted flow by flow changes what the operation can absorb without adding people — but it requires the flow to be written down first, which is the part nobody enjoys.
How much autonomy can each flow carry?
Gartner classifies AI agents into four autonomy levels, and each level is a different trust boundary. The translation into a smaller operation is direct.
At the first level the AI only observes. Read-only access, results visible only to whoever asked. Summarizing a contract, finding information, explaining a report. The risk is data exposure and a wrong answer, so the control stays light: scope of access, authentication, usage logging.
At the second it suggests. It produces a draft, a recommendation or a proposed action, and a person executes. It still writes to nothing. Here a risk appears that almost nobody budgets for: automation bias. After a few weeks of being right, the team stops checking. The control becomes accuracy testing and training whoever reviews.
At the third it acts with approval. It writes data, sends a message or changes a setting, always after someone says yes. That works while the approval is a real decision. Under deadline pressure it becomes a click, and the click gives the feeling of safety without the safety.
At the fourth it acts alone, within defined limits, and a person reviews exceptions and the aggregate log. That level demands the most: continuous monitoring, limits imposed in code, fast rollback, an automatic cut-off when a threshold is breached, and an owner with a name.
The mistake that kills projects is not choosing the wrong level. It is applying the same control to all four. According to Gartner analyst Shiva Varma, companies treat agent governance as binary: everything locked, or everything open. Over-restricting the simple agent delays delivery and pushes the team toward tools outside the perimeter, with no logging at all. Over-permitting the autonomous agent raises operational and compliance risk. That confusion is what sustains the 40% projection through 2027.
When does a fixed rule work better?
When the input is structured and the criterion fits in a sentence. In that case a rule is cheaper, runs identically every time, can be tested up front and explained afterwards. If an order above a threshold needs director approval, that is a condition, not a judgment.
AI earns its place where the input is messy or the criterion is hard to enumerate. Reading a customer email and extracting what they want. Classifying a ticket into fifteen categories. Comparing a product description against an invoice. These are tasks where writing every rule costs more than training and checking.
There is a difference that matters in an audit. A traditional system fails deterministically: the same input returns the same output, and you reproduce the problem in order to fix it. An agentic system behaves differently, sensitive to context and harder to debug. Where a process has to be reproducible for a regulator, a customer or a contract, that is not a detail.
And there is the bill. Gartner projects that the cost of inference per agentic workflow grows more than fivefold through 2028, even as token prices fall, because each generation of capability consumes more tokens. Compared with a basic chatbot, routing the task to a reasoning model costs at least five times more. According to analyst Will Sommer, defaulting to generic autonomous intelligence leads to uncapped costs. A deterministic automation has a predictable cost per run: you measure once and project the budget from volume. In an agentic flow, cost per run varies with the path the model chooses, and the projection needs a range, not a single number.
A practical example
The scenario below is hypothetical, built to show how the split works. No real client is described here.
A 40-person services company receives around 300 quote requests a month, scattered across email and messaging apps. Today one person reads everything, types it into the system, calculates the price in a spreadsheet and replies. It takes an average of 18 minutes per request, and she is the only one who knows the calculation end to end.
The split by nature of the task looks like this. Extracting customer, service, deadline and quantity from the message is judgment over messy text, so that is AI at the suggest level, with the person confirming on screen. Calculating the price is a rule: price table, volume discount bands, minimum margin. That becomes code, not a model. Generating and sending the proposal is an action with external effect, so it starts at act with approval.
The promotion criterion gets written before anything is switched on. For example: four consecutive weeks with extraction accuracy above 97% and no proposal sent with a wrong price, and sending proposals below a defined value starts running on its own, with an automatic cut-off if two errors appear in the same week. Without that number defined up front, promotion becomes a feeling.
How to move up a level without blowing the budget
Six steps, in order.
Pick a flow with measured volume and measured pain. How many times a month, how many minutes each, who does it. Without that number, there is no return to calculate later.
Separate what is a rule from what is judgment, task by task. That is the architecture decision for the whole project, and it comes before choosing a vendor or a model.
Start at suggest, even when automating looks obvious. The first weeks reveal the odd cases nobody remembered to mention.
Write the numeric criterion for promotion and for demotion. What accuracy, measured over how long, and what sends the flow back down a level.
Define what stops execution and who owns it. A breached threshold has to halt the flow on its own, and a person has to be accountable for its behavior.
Measure cost per run from day one. A flow costing a few cents per request at 300 requests a month is cheap. The same flow at 30,000 requests is a budget line nobody approved.
The order matters more than the tool chosen at the end. That was the approach when turning process consulting into a document management product in the Repap On case, and when moving contract management out of Airtable into a bespoke ERP in the SuperVida project. Neither started with the technology.
Frequently asked questions
How do I know whether AI in operations has a financial return?
Compare it against the number you measured beforehand, not against a vendor's promise. Monthly volume times time per run times cost of the hour gives the flow's current cost. After switching on, add the inference cost per run, the review time that remains and the maintenance. If you cannot assemble that calculation, the problem is not the AI, it is the absence of process measurement.
I don't have a qualified team to implement this. Does that rule it out?
No, but it changes what you contract. The hard work is not connecting the model, it is deciding the autonomy level of each task, writing down the rules that stay rules, and defining what stops the flow. The people who operate the process take part in that definition. The technical part can be executed by an external team, as long as the promotion criterion and the flow's owner stay in-house.
Will integration with what I already use be complicated?
That depends less on the AI and more on what your current tools expose. Before choosing a model, check whether the system the data has to land in has an API, whether history can be exported, and where the source of truth for each piece of information lives. An AI flow that writes to two different places creates the same numerical divergence you already had, only faster.
Autonomy is an architecture decision
None of these choices is about which model to buy. They are choices about where human judgment needs to sit inside the flow, and that answer changes from task to task within the same process.
If the open question today is where AI enters your operation and with how much autonomy, the Operational Architecture Diagnostic is a 30-minute conversation to map your flows and separate what is a rule from what is judgment.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No strings attached.
Book a diagnostic