Operations agent

What is an operations agent?

An operations agent is an AI agent that watches your operational data all day, notices when something drifts out of line, works out why, and then does something about it inside the system where the work lives. It raises a purchase order, reschedules a delivery, opens a ticket, or tells a planner what it found and what it would do. It runs on the always-on pattern described in the ambient agent entry; this entry is about what that pattern looks like when the stream is your warehouse, your machines or your order book.

The data it watches is the data your operations already produce: stock levels per article, the order backlog, sensor readings from machines and cold rooms, delivery ETAs from carriers, payment status on invoices, open service tickets. None of that is new. What is new is that the thing looking at it can hold several of those signals together, compare them with what happened last month, and pick an action from a list you wrote.

Picture the planner who walks through the warehouse at seven in the morning, looks at the empty shelf, checks whether an order is already on its way, remembers that this article always sells out before a bank holiday, and then either phones the supplier or decides to wait. An operations agent does that walk every five minutes, for every shelf, and writes down what it decided and why.

The loop: detect, diagnose, decide, act, report

Every operations agent runs the same five steps, whatever vendor built it.

1. Detect
   A rule fires: stock under the reorder point, a delivery ETA that slipped past the promised date, a motor temperature that crosses a threshold. In Microsoft Fabric the operations agent runs a query for each rule every five minutes and distinguishes a state (the value is above 80) from a transition (the value just crossed 80), so you choose whether to react to being in a state or to entering it.

2. Diagnose
   The agent gathers the context a person would gather. Is there already a purchase order for this article? Did one customer place an unusually large order this morning, or has demand been climbing for three weeks? Has this machine shown the same pattern before a breakdown? This is where it differs from a threshold: it reads history and related records, not just the number that tripped.

3. Decide
   It picks one action from the catalogue you gave it, or decides that no action is right and says so. The choice is constrained: it cannot invent an action that is not on the list.

4. Act
   Depending on the approval rule attached to the action, it executes at once, or it sends the proposal to a person and waits. In Fabric the default is a Teams message with the finding and the recommended action; when the recipient approves, the agent runs the action.

5. Report
   Every run leaves a record: what fired, what the agent looked at, what it chose, whether a person approved, what happened. That record is the raw material for the weekly review further down.

The action catalogue

The most useful design decision you will make is to give the agent a fixed list of allowed actions, each with parameters and an approval rule, and nothing else. In Fabric each action has a name, a description and an optional list of parameters, and the agent uses the description to decide which action fits the condition. The actions themselves are Fabric items such as a notebook or a pipeline, or a Power Automate flow that reaches into the system you actually want to change.

A catalogue for a small distribution company might look like this.

• Raise a purchase order at the default supplier, with article, quantity and requested date as parameters. Automatic when the order value stays under a threshold and the quantity does not exceed a set number of weeks of sales; otherwise proposed for approval.

• Reschedule a delivery to the next available slot and inform the customer. Automatic for one slip per order; a second slip goes to a person.

• Open a service ticket with the diagnosis attached. Always automatic, because a ticket is cheap and reversible.

• Notify a planner with the finding, the context and the action the agent would have taken. The safe default for anything not covered above.

• Do nothing, and log why. Explicitly on the list, so silence is a decision you can audit rather than a gap.

Everything the agent may touch is on that list, and everything on the list has a rule that says when it may run alone. That is what makes the agent governable: you tune the rules, not the model.

Operations agent versus an alert rule, and versus a scheduled flow

Versus an alert rule: what happens after detection?

An alert rule and an operations agent detect the same things. Fabric Activator, for instance, evaluates conditions like value below threshold, becomes, decreases or exits range on every event, and fires an email, a Teams message, a pipeline or a Power Automate flow when the condition is met. Up to the moment of detection the two are the same.

The difference is what comes next. An alert rule hands the situation to a person, or starts one fixed action, every time. It does not know that a purchase order is already open, that the spike is a single customer, or that the last three alerts on this machine were false. So it either fires too often and gets ignored, or is tuned so narrow that it misses the case that mattered. An operations agent reads that context after detection and chooses. The alert rule is the first step of the agent's loop with the other four steps removed.

Versus a scheduled flow: who chooses the action?

A flow that runs every night, finds articles under the reorder point and creates a purchase order for each one is not an operations agent, even though it acts on operational data. You chose the action when you drew the flow, and it applies the same action to every row. The agent chooses per case: reorder this one, wait on that one because stock is on its way, tell the planner about the third because the supplier's lead time doubled. The flow is the right tool when one action fits every case. The agent earns its place when it does not.

How vendors package it

The pattern is turning up across the operations software market. Four examples, with dates, because this moves quickly.

Microsoft Fabric. The operations agent became generally available in June 2026 as an item in Real-Time Intelligence. It monitors an eventhouse or a Fabric IQ ontology, and Microsoft describes the intent as monitoring live data, detecting anomalies and taking governed action. Each agent gets its own identity in Microsoft Entra, separate from the person who built it, and runs with that person's delegated permissions. You describe the goal in a chat, Copilot turns it into rules and queries you can inspect, and a Start and Stop button on the toolbar controls the agent. A preview feature added in July 2026 runs a root-cause investigation after an anomaly and posts the findings in Teams.

SAP. SAP's Production Planning and Operations Agent, announced in October 2025, automates the prerequisite checks for releasing production orders: material, capacity and scheduling. In April 2026 SAP described it as making recommendations, such as alternative components or rescheduling options, that planners review and approve, with general availability planned for the second quarter of 2026. At Sapphire in May 2026 SAP summed up its supply chain agents as designed to sense events, analyse impact and take guided action within defined business guardrails.

Celonis. Celonis starts from process mining. Its Orchestration Engine coordinates workflows involving AI agents, human tasks and system automations, with trigger events from the process digital twin starting the sequence. In 2026 Celonis said over 100 customers were using it that way, and its Agent Tools let an outside agent pull operational context and run fixed processes rather than improvise.

UiPath. UiPath Maestro models the whole process as a BPMN diagram in which agents reason, robots do the system-to-system work and people take the judgement calls, with the decision logic in DMN tables that are versioned and audited next to the model. Operations staff can suspend, resume, retry, rewind or skip steps in a running instance.

Each vendor puts the reasoning in a different place. The governance questions below apply to all of them.

A stock-and-reorder agent for a wholesaler

A wholesaler with 3,000 articles has about 100 that carry most of the volume. A purchaser spends the first hour of every day on those 100, and some still slip. Here is what an operations agent for that hour needs.

The data. Current stock per article, updated on every movement or at least nightly. Open purchase orders with expected receipt dates. Open sales orders and backorders. Per supplier: lead time, minimum order quantity, current price. Sales per article for the last 13 weeks, so the agent can see a trend as well as this week. That is five tables, and most ERPs expose all five.

The rules. A reorder point per article, calculated as average daily sales over the lead time plus a safety margin, recalculated weekly. A detection when stock minus backorders drops under that point. A diagnosis step that checks whether an open purchase order already covers the gap, whether the drop comes from one large order, and whether the supplier's lead time has changed recently.

The approval line. The agent may raise a purchase order on its own when the order value is under 2,000 euro, the quantity is at most four weeks of average sales, and the supplier and price match the last order. Above that, or for any article the agent has not reordered before, it proposes and waits. Two caps sit on top: at most 15 automatic orders per day, and at most 10,000 euro of automatic orders per day. When either cap is hit, the agent switches to proposing for the rest of the day and tells the purchaser.

The weekly review. Half an hour on Friday with the log open. How many detections this week, how many became automatic orders, how many proposals, how many of those the purchaser changed or rejected. A rejection rate near zero after a few months does not mean the agent is perfect; it may mean nobody is reading the proposals. Ten minutes on the articles the agent chose to leave alone, because that is where a missed sale hides. Then adjust the thresholds, not the prompt.

With 100 fast movers, a dozen detections a week is a reasonable expectation, so the purchaser reviews around 50 decisions a month instead of checking 100 articles every morning. The time saved is real, but the bigger change is that every reorder decision now has a written reason.

What has to be in place before it may act

An agent that only notifies needs little of this. An agent that writes to your ERP needs all of it, before the first automatic action, not after the first incident.

Its own identity. The agent authenticates as itself, not as the purchaser who set it up, so you can see its actions apart from human ones and switch it off without touching anyone's account. Fabric provisions an Entra agent identity per operations agent for exactly this reason.

An action allowlist. The catalogue above, enforced by the platform rather than by the instructions. If the only tools wired in are raise order, reschedule, open ticket and notify, a bad prompt or a poisoned input cannot make it do anything else.

Spend and volume caps. A ceiling per action, per day and per week, in money and in count, with the agent falling back to proposing when it hits one. The cap is what turns a wrong rule into a bad afternoon instead of a bad quarter.

An audit log with the reasoning. What it did, what it looked at and why it chose that action, in language the purchaser can read on Friday. Without the reasoning the weekly review is guesswork, and without the review the thresholds never improve.

A stop that works. A button that halts the loop, drops queued actions and disables the triggers, tried once before you need it. The agent kill switch entry covers what that stop has to reach.

One more, easy to forget: the agent is only as good as its feed. A stock table that updates nightly gives you a nightly agent whatever the rule interval says, and a sensor that drops out looks, to a naive rule, like a machine that stopped overheating. Check how fresh every source is, and let the agent say so when one goes quiet.