July 2, 2026·Architecture

Why explaining the problem isn't the same as being trusted to fix it

agentic-aiaction-systemsactivatoroperational-stategovernance

Picture a dispatcher at 9:12 on a Tuesday morning. A truck carrying inventory for three downstream distribution centers should have checked in twenty minutes ago. It hasn't. The telematics feed shows nothing, which is itself the signal: the truck is stuck behind a highway closure. By lunch, three stores will be short on the exact SKUs their weekend promotion depends on.

The company has a copilot for this. Ask it why truck 447 is late and it handles the easy part well: it pulls the telematics history and confirms the truck hasn't checked in for twenty minutes. Connecting that silence to the highway closure is a different kind of question. That requires joining two systems nobody wired together. The copilot gets there inconsistently, sometimes catching the connection, sometimes leaving a person to notice the pattern and say so out loud. Ask it to fix the problem instead: reroute the downstream replenishment, weigh a partial air-freight order against waiting, notify the affected stores before the next cutoff. It stops being useful. Not because the model can't reason through the tradeoff, but because nothing in the system ever gave it the standing to act on the answer, right or not.

That gap between answering and acting is where most of what gets called agentic AI this year will fail. It won't fail loudly. It will fail the way infrastructure always fails: quietly and in production, long after the demo, when someone finally asks the agent to do the thing instead of describing it.

Notify is not the same as act

Fabric's Activator is a good example of this confusion, not because it's a weak product, but because it does its actual job well enough that it's easy to mistake for something bigger. Activator watches a condition and fires: a threshold breach, a KQL query result, a report value crossing a line. It turns that into a Teams message, an email, a flag on a dashboard. That's genuinely useful, and it's a real improvement over a human staring at a report waiting for something to change.

But it's still tier one: the system detects, notifies, and stops. A human still has to decide, and a human still has to execute. The dispatcher still has to read the alert, weigh the reroute against the air-freight cost, and pick up the phone.

Tier two looks different. Detect the same condition. Check it against a governed picture of what's actually happening right now: downstream orders, store commitments, carrier capacity. Then execute the reroute within limits someone deliberately signed off on, and log why, so the decision can be audited later.

Almost nothing shipping today operates at tier two. Most of what gets marketed as an agent is tier one with better copy.

Notify versus execute: two tiers responding to the same condition

Why a smarter model doesn't close the gap

The natural assumption is that tier one becomes tier two once the model gets good enough: put a more capable LLM behind Activator's trigger, and eventually it starts making the call itself. It doesn't. The thing missing isn't reasoning quality. It's two things no model upgrade provides.

First, it needs a live and trustworthy representation of what's happening right now, not a semantic model built for last quarter's board deck or a document retrieved three weeks ago. Second, it needs a governed grant of authority to act: an explicit answer to whether the agent may reroute a shipment and under what conditions. Someone has to be accountable if it's wrong.

You can wire a more capable model behind a threshold rule and it will still just be a very articulate notification. The upgrade path from tier one to tier two runs through architecture, not model choice, and it stacks as four dependent layers rather than one smarter component:

Anatomy of tier two: four dependent layers, state, policy, execution, and audit

In the shipment scenario, the state layer might be a KQL database like Eventhouse, tracking downstream orders, store commitments, and carrier capacity as they change. It could just as easily be a different real-time store. The pattern doesn't depend on which one you pick, it depends on whether the three layers above it exist at all.

The execution layer already has more than one concrete answer. Fabric's Operations Agent reached general availability this year and is built for policy-driven action, not just detection. Microsoft's Foundry Agent Service reached GA around the same time for its own agent estate. Google's Vertex AI Agent Builder, recently folded into the Gemini Enterprise Agent Platform, is building toward the same layer. Which vendor you pick matters less than whether that layer exists at all.

The audit layer is the one most teams build last and get wrong first, mostly because it's tempting to treat it as a log line instead of a queryable operational stream. I covered a concrete pattern for that in OpenTelemetry Monitoring for AI Agents Using Microsoft Fabric: every model call as a structured span, landed in the same kind of real-time store, so the audit trail is something the platform can query and act on, not something a person greps through after the fact.

Skip any one of these four layers and you're back to tier one, no matter how capable the model behind it sounds in a demo.

The audit worth running on your own stack

If you're evaluating something your team is calling an agent, the model's benchmark score is the wrong first question. Ask instead whether it answers or executes. If it only answers questions, that's fine: name it accurately and stop expecting it to behave like something it isn't. If someone wants it to execute, ask what state it's bound to, and whether that state is live or a snapshot. Then ask who granted it authority to act, under what limits, and how you'd find out if it acted wrongly. If any of those three questions doesn't have a real answer, the model didn't fail you. You are solving the wrong problem with the wrong tool.

The wave of agent failures coming over the next year won't be a model problem, and treating it like one will waste a year of engineering effort on the wrong layer. The question worth asking isn't whether your agent is smart enough. It's whether anyone gave it the standing, and the state, to act at all.

Sources

← All writing