Operations agent

Nobody asked a question.

At 2:14am a freezer in a back room went above its safe temperature. No dashboard was open. No engineer was awake. There was no chat window with a blinking cursor, no "hey, what's affected?" waiting to be typed. There was just a number rising past a line it should not cross.

By 2:15am the problem had a clear shape. The freezer was F-02. F-02 sits in the Paris store. Nine open orders in Paris needed the cold stock it kept. That was roughly fourteen thousand dollars of revenue about to spoil. All of that was flagged, with a suggested fix, before the first person heard about it.

Something did that. It was not a person, and it was not a query someone ran. It was an agent that never stopped watching, and moved the moment the data moved.

An agent that watches instead of waits

Every agent you have met so far waited. You asked, it answered, then it went quiet. That is a pull: the work only starts when a person pulls on it with a question. Useful, but it does nothing between questions.

An operations agent changes what starts it. It is a push. The live data pushes on it. New data arrives, a value crosses a line you drew, and the agent starts working on its own, with nobody in the loop yet. The 2:14am breach (the freezer going over its limit) had no question in front of it. There was nothing to answer, so a question-answering agent would have missed it completely.

The reasoning inside is the same reasoning a question-answering agent uses. What changes is who starts it and when. And once you take the person out of the front of the loop, the loop has to close itself.

The loop is the whole thing

Watch, notice, work out what it means, do something about it, then go back to watching. Four moves, and none of them is optional. Drop the last one and you have a fancy thermometer. Drop the tracing and you have a threshold alarm that alerts a human at 2am and hopes they can work it out while half asleep.

Call the four moves monitor, detect, decide, act. Monitor is the watching. Detect is the moment a value crosses the line. Decide is the part that earns the word "agent": it works out what the anomaly means for everything downstream. Act is the recommendation or the change that follows. Then it is back to monitoring, because the loop has no end. It is not a task you run. It is a thing that is always on.

A reading does not stay a reading

Here is the move that makes it more than an alarm. A raw breach on its own means little. "F-02 is at −3" tells you almost nothing by itself. What matters is what that reading touches, and that lives in the relationships, not in the reading.

So the agent follows the links. F-02 is in a store. That store has open orders. Those orders have a value. One hop at a time, a warm freezer becomes a store, becomes nine orders, becomes revenue at risk. Same event, carried across the model until it says something a human actually cares about. This is the traversal you already know, pointed at a live anomaly instead of a typed question.

Set off the breach and step through it yourself.

Notice what each hop did. It did not add data. It added meaning, by borrowing it from the neighbors. That is the difference between an operations agent and a monitor: the monitor knows the freezer is warm, and the agent knows the Paris store is about to lose money.

The operations agent in Fabric

In Microsoft Fabric, a data agent is an AI agent grounded in your data. An operations agent is that same idea pointed at live data and given something to do about it. It watches streaming rows landing in OneLake against monitors you define, and when a value trips one, it does not just fire. Give it an ontology to reason over, the same knowledge graph a data agent queries, and it traces the impact from the reading out to what is really at risk, then recommends or takes a governed action. That is the monitor-detect-decide-act loop, running on your model.

The tracing is the part worth a close look. Because it reasons across concepts on the graph, a freezer breach does not stay a freezer breach. The agent walks it to the store, to the open orders, to the revenue, the same traversal that answers a question in the data agent, now started by an anomaly instead of a person. One low-level reading becomes a business-level fact, and when it is grounded on the ontology graph, the impact path follows real relationships in your model rather than a guess.

Now the honest limit, because the product does not actually require any of that. An operations agent needs one of two things: an eventhouse or an ontology. Point one at a KQL database with no ontology item and no knowledge graph behind it, and it still runs the loop: it watches, it detects, it recommends. What it cannot do is the walk. Without the graph a warm freezer stays a warm freezer, and working out that Paris is the store and nine orders are at risk goes back to being a human's job at 2am. So the ontology is not what makes it an agent. It is what gives the agent somewhere to walk, and that is the whole difference between an alert and an answer.

It is worth looking at what a monitor's rule actually checks, because one choice inside it decides how often you get alerted. While the agent is active it re-runs the rule's query every five minutes, and that timing is fixed, not a dial you turn. So the real question is what counts as the condition being met on each of those checks. Fabric splits that into two kinds. A state condition is met any time the current value meets it. A transition condition is met only at the moment the value changes from not meeting it to meeting it, including a jump up from a missing reading.

Point both at the same freezer limit and see how different they are. Is above is a state condition, so every five minutes the freezer still reads warm, it is met again, and it keeps firing for as long as the door stays open. Crosses above is a transition, so it is met once, at the check where the temperature first goes over the line, then it stays quiet even while the freezer is still warm. Same threshold, two completely different alerts. Use Is above when you want a repeated alert that keeps going until someone acts, and Crosses above when you want one clean signal per event. Get that backwards and you have built either an alarm that fires once and then goes silent, or an inbox nobody reads.

Two honesty notes, because Fabric IQ is in preview. First, the exact set of actions an agent may take, and how tightly they are governed, is still being decided, so treat the "act" step as recommend-and-govern rather than a promise of specific automatic actions. Second, the lab you are about to open is true to the reasoning but not to the full machinery: it runs real graph traversal and real rules, and it can replay a bundled telemetry recording, where a time cursor re-checks the monitors as it moves, rather than a continuous live stream. The loop is honest. The clock is a recording.

The one trap

Do not mistake a monitor for an operations agent. A monitor fires when a number crosses a line. That is the detect step, and only that step. It knows the freezer is warm and it knows nothing else. An operations agent is the whole loop wrapped around that monitor: it takes that same reading and reasons it across the graph until it can say who loses money and what to do next. If your "agent" alerts a human with a raw reading and lets them work out what is affected, you built an alarm and called it an agent.

That reasoning is what makes the last step safe to hand over. Once an agent can decide, the only question left is what it is allowed to do, and that is not left to chance. It is written down. Next: actions and rules, the layer that says which moves the agent may make, and who allows them.