Most operations teams receive more alerts than they can read. Inventory below safety stock, a supplier shipment running late, a cost centre trending over budget, a machine running hot: each arrives as an email or a red tile, and each asks a busy person to stop, investigate and decide what to do. Many are opened late, and some are never opened at all. The alert did its job. The process around it did not.

AI agents change the shape of that work. Instead of notifying, an agent can detect the exception, gather the evidence, propose the next step and open a task for the person who owns the decision. That person still decides. What disappears is the digging that made the alert so easy to ignore.

From notification to a prepared decision

The difference between an alert and an agent is what arrives with it. A useful exception package answers four questions before anyone has to ask them.

  1. What happened, measured against the expected range for that item and that time of year, not just a fixed threshold.
  2. Why it probably happened, with the evidence attached: the order, the shipment, the change order or the sensor readings behind it.
  3. What to do next, as a proposed action with its likely effect: expedite, rebalance stock, call the supplier, query the change order.
  4. Who owns it, and by when, as a task in the system the owner already works in, not a message lost in an inbox.

The earlier the exception is caught, the more options the owner has. A cost overrun spotted while the month is still open can be managed; the same overrun discovered at the close can only be explained.

Exhibit: an alert that arrives early, with the evidence and the first thing to check.

One exception, one task

Alert systems tend to fire once per symptom. A late supplier produces a late-shipment alert, a stock-out warning for each affected item and a service warning for each customer order at risk, all landing in different inboxes. An agent should do the opposite: group related signals into a single exception, find the cause they share and open one task with one owner. Fewer, better tasks are what make people trust the queue.

Where to start

Pick an exception that happens often, costs money when it is missed, and has a clear owner and a known playbook. Stock-outs on high-volume items, late inbound shipments, supplier invoices on hold and maintenance on critical assets are typical candidates. Avoid starting where the right response depends on negotiation or judgment that nobody has written down; the agent will have nothing to propose.

Write the playbook before building anything: the signals that define the exception, the evidence a good analyst would gather, the actions available and who may approve each one. That document becomes the agent’s instructions and the first test of whether the process is ready for automation. It also applies a principle that holds for any control tower: exceptions are routed, not reported.

Then run the agent in the background for a few weeks. It prepares its packages and proposals while the team works as before, and the owners compare its proposals with what they actually did. The comparison shows whether the playbook is right before anyone depends on it, and it gives you a baseline to measure against.

Guardrails that earn the agent more room

Start with an agent that prepares and proposes, and a person who approves. Actions that are reversible and low in value, such as reordering a standard part within agreed limits, can later run without approval. Actions that commit significant money, change a commitment to a customer or touch safety stay with a person. The agent works with the permissions of the role it serves, never more, and every source it reads and every action it proposes is logged.

The foundations are the same as for any AI that reads business data: certified definitions, access by role and documented gaps, as set out in our readiness checklist. An agent that proposes the wrong action from the wrong number does more harm than an alert nobody reads.

Measure the loop, not the alerts

Counting alerts says nothing about whether anything happened. Track the time from detection to first action, the share of exceptions acted on within the agreed time, the share of proposals owners accept as they stand, and the false alarms they dismiss. Then track the outcome the exception exists to protect: fill rate, on-time delivery, spend against budget, unplanned downtime.

Acceptance is the most telling of these measures. When owners accept most proposals unchanged, the agent is ready for more autonomy on that kind of exception. When they rewrite them, the playbook or the data needs work, and the rewritten proposals show exactly where.

Exhibit: exceptions by outcome each month, before and after the agent began preparing each task.

The daily meeting changes

Over time, the daily operations meeting changes character. Instead of walking through a list of red tiles, the team reviews the exceptions that were resolved, the ones still open and the proposals owners rejected, and why. Rejected proposals are the richest source of improvement: each one points to a gap in the playbook, the data or the agent’s instructions.

Closing those gaps one exception type at a time is how an operation moves from watching its numbers to acting on them. The agent does not replace the people who run the operation. It gives them back the time they spent finding out what happened, so they can spend it deciding what to do.