Every team is about to learn the three categories of AI agents. That’s table stakes. The moat is deciding which events get which category.
Hamza Farooq and Jaya Rajwani named those shapes cleanly in Not all AI agents are created equal: deterministic automation is the hardcoded workflow, ReAct is the single agent reasoning and acting in a loop with tools, and multi-agent networks are coordinated systems of specialists. Useful vocabulary, and it is going to become commodity vocabulary fast.
Event economics
The harder problem sits upstream of the architecture choice: deciding which events warrant which shape. Most systems pick one tier and apply it everywhere. Either everything gets cheap deterministic treatment, and the system misses the nuance on the handful of events that actually mattered, or everything gets the full ReAct loop, and you burn money and latency on events where neither was justified. Both are ways of not making the decision.
It is easy to see why teams land there. The architecture choice is visible, it has a name, and you make it once. The routing decision is invisible by comparison, so it gets made by default and nobody has to sign their name to it.
The useful move is routing. Run deterministic by default, escalate to a ReAct loop when signals cross a threshold, and escalate to a multi-agent investigation when the event class demands cross-domain correlation.
The unit of that decision is the event class. A pipeline is a coarser thing: it usually carries several classes at once, and they are rarely worth the same amount to you. Decide the tier once at the pipeline level and every event flowing through it inherits the same budget, whether it is routine or the one signal you would have wanted a person to look at.
Turns of the crank
The way to think about the budget is turns of the crank. A crank is one pass of the machinery over an event: enrich it, reason about it, call a tool, correlate it against something else. Each class gets a number of cranks, decided before the expensive machinery moves rather than discovered while it runs.
A low-value event gets one crank: enrichment, tagging, and a log line. A mid-value event gets two or three, enough for a ReAct loop to check context and call tools. A high-value event gets the full investigation, with multiple agents, multiple sources, and an audit trail.
The hard part is that you are budgeting the class before you know what any particular instance of it turns out to be, so you will sometimes underspend on the one that deserved more.
Alert fatigue is a routing failure
Observability has already run this experiment on a smaller version of the same problem. Alerting is routing: every signal gets classified, and the classification decides whether it reaches a person or lands in a log. Teams that never made that classification deliberately still ended up with one, and the cost of that shows up in the numbers.
In Splunk’s State of Observability 2025, a survey of 1,855 ITOps and engineering professionals, 43% said they spend too much time responding to alerts, 73% reported outages caused by ignored or suppressed alerts, and 54% said the quality of their alert detections has the greatest effect on their observability ROI.
Detection quality is a routing question. It is the decision about which signals deserve investigation and which deserve a line in a log, made ahead of time, per class of signal. A CPU spike on a dev box should not get the same treatment as latency across a payment path, and the first two numbers are what it costs when they do.
Agent orchestration is the same decision with money and latency attached.
The Intent Gap, one layer up
I have written about the Intent Gap as a generation problem: the distance between what a developer meant and what the AI produced (Quality In, Quality Out, then The Intent Gap).
Orchestration has its own version of it. The gap there is between what you wanted to know about an event and how much agent you spent answering it. Over-invest and you paid ReAct prices to produce a log line. Under-invest and you tagged an incident instead of investigating it. In both cases the amount of process applied was set by something other than what the event was worth.
That is the principle behind risk evaluation in AI-aided development, pointed at a different decision. There, the weight of the review process has to match the blast radius of the change. Here, the weight of the investigation has to match the value of the event.
What the routing layer does
The routing layer itself is small. What matters is that it sits somewhere explicit rather than being implied by whichever pipeline an event happened to land in. It classifies the event, decides the crank budget, records the decision, and gives a human a way to audit an escalation after the fact.
That last part is easy to skip and hard to add later. A routing rule nobody can inspect is a routing rule that rarely gets tuned.
If you want to find out whether you have one, open the event streams your agents already touch and pick the five most common event classes. For each one, answer three questions: what is this event worth, how many cranks does it deserve, and who owns the routing decision when it turns out to be wrong.
The moat isn’t the agent. It’s the judgment about when to invest in one.