Give the agent a resolved question.

The agent was never the bottleneck. What you hand it is.

IT data looks agent-ready. Alerts, incidents and changes are sitting there, structured, apparently waiting to be picked up. So most platforms point an agent at the pile and let it go find things. Evidence-first architecture does the correlation on the way in instead, so the agent opens with the relationships already resolved and spends its whole budget on judgment rather than on search.

This is an AI story that applies to most industries, and it is sharpest in IT, because our data arrives already looking like an answer. Alerts have fields. Incidents have states and timestamps. Changes have windows. Everything is structured and sitting still, which reads as the perfect setup for an agent to walk in and be useful on day one.

The output across the whole category is the evidence that it is not. Vanilla summaries, and matches labelled similar. If the data really were ready, the results would not all land in the same place regardless of which vendor's agent you point at it.

When I started working in this area, I built an AIOps toolset that was integrated with two legacy platforms. What came back was summaries that restated what I could already see, plus a list of similar records.

It was close, close enough and often enough to ship it, and that is the trap. This is not horseshoes. When close, or maybe useful, arrives wearing the same confidence as the uncommon true hit, you have already built re-checking the answer into the user's routine. The result is what feels like a broken clock, right twice a day, and even on those you feel the need to check it against your watch.

The reason is not that the agent is weak. It is that the architecture hands it two jobs and it is only good at one of them.

The first job is retrieval. Without a recorded map of what relates to what, an agent has to go and find the relationships at the moment you ask, and every hop it takes is an interpretation. That is agentic search playing Plinko with your question. Ask for a lasagna recipe and the bouncing is fine, any reasonable path lands somewhere edible. Ask which changes went in last Tuesday and whether any of them explain the error you just found, and a differently-bounced answer on the second asking is not a quirk, it is a system you cannot use to make a decision.

The second job is judgment, which is the part the model is actually excellent at. But by the time retrieval finishes, the clock has run and a real share of the context budget is already spent on finding rather than thinking. So the agent reaches its best work last, with the least room, holding whatever the search happened to return. Vanilla output is not the model underperforming. It is the model doing its second-best job with what the first job left behind.

Fair objection, and it deserves precision rather than a dodge. Most platforms in this space do carry some record of relationships. A service catalog, a dependency map, a configuration database. Those are real, and an agent reading one is better off than an agent reading none.

The useful question is which one each map answers. A declared graph answers what depends on what. Somebody drew it, and from that moment it describes how things were arranged on the day it was drawn. It does not decay loudly, it decays silently, and an agent reading a stale map answers with total confidence, which is the worst of both worlds. A trace-derived graph answers what called what. That one stays current by construction and is genuinely good, and it is scoped to whatever is instrumented well enough to be traced. A correlation engine answers what fires together, which the AIOps category has been doing for a decade.

None of those answer the question an operator is actually holding, which is what this operation does when this happens. What got checked first. What got ruled out. Which service someone went to before anyone declared anything. That is not a property of the systems at all, it is a property of how your team works, and it cannot be derived from topology or traces because it was never in them. It can only be recorded, by the work happening somewhere that keeps it. That is the layer Signal9 is built to accumulate, and it is the reason the sifting has to leave a record in the first place.

There is a second limit worth naming, and it applies to anyone deriving relationships from activity, us included. What you can correlate is bounded by what reaches you. A platform that sees only what it instruments builds a map of what it instruments. A platform that sees only what somebody already judged worth paging on builds a map of the page-worthy. Neither is wrong, both are partial, and the gaps are invisible from inside. The reason our front door takes plain email forwarding and any webhook shape it is handed is that the low-severity stream nobody would ever page on is precisely where the patterns live.

The fix is to move the correlation off the critical path. Correlate on the way in, not on the way out. That is the whole idea, and it has four working parts.

Identity resolves at capture. Every signal names the thing it fired on, and that thing becomes an entity the moment it appears, not when someone asks about it later. The inventory assembles itself from what actually fires.

Relationships are written as events, not inferred as guesses. This alert fired on that system, that system belongs to that service, this incident was fixed by that change. Each link is recorded when it happens, by the work that happened. Events are facts, and facts do not need to be re-derived per question.

Numbers carry their own scope. Every count states what it counted and over what window, so an answer cannot quietly blend one question's population with another question's clock.

The agent receives the resolved set, not the conclusion. There is still real work in front of it, weighing, discarding, deciding what all of it means, and that work is exactly what it should be spending the budget on. What it no longer does is gather. It opens with what search would have had to go find, already resolved, more accurate and cheaper than any per-question hunt would have returned it.

Notice what that does and does not promise. The model's read can still vary, because judgment varies. Hand the same evidence to two qualified engineers and you may get two assessments, and hand it to the same engineer next week and you may get a third. That is not a defect, it is what reasoning is. Arithmetic is one plus two. Reasoning is what does three mean.

What must not vary is what was being judged. Search-first gives you two datasets and two decisions, and the variance compounds somewhere you cannot see it. Evidence-first gives you one dataset and two decisions. Different conclusions from the same evidence is a second opinion. Different conclusions from different evidence is a coin flip.

There is a design tradeoff here, and it is the fair objection to everything above. Correlating on the way in means committing to which relationships matter before anyone asks a question. Search never commits, and that is exactly why it can follow a path nobody anticipated.

That commitment is cheap in this domain for one reason. Operations runs on a small, stable vocabulary of relationships. Fired on. Belongs to. Preceded. Caused by. Fixed by. That list has not moved in twenty years and it is not about to, so writing those links as they happen forecloses almost nothing. This is not an open semantic space where early commitment would cost you the interesting questions. It is a handful of edges that operations has always needed and has always rebuilt by hand, per incident, in somebody's head.

This is also the expensive way to build, and that is exactly why the category defaults to the other one. Search over an existing store can ship in weeks, on top of a platform that was designed to record work rather than understand it. Evidence-first means the platform has to be built to organize as it captures, which is a foundation decision, not a feature you add in a sprint.

So the honest version is not that anyone chose badly. My own AIOps toolset made exactly this choice, for exactly this reason. The platforms underneath it recorded work rather than related it, so search was the only door available, and I spent my time trying to make the agent sharper when the agent was never the part that was short. I was failing to hand it what it needed.

A platform designed for record-keeping can only reach its AI through retrieval, and retrieval has a ceiling that no amount of prompt work raises. The architecture decides the ceiling. The agent just meets it.

Signal9 was built on the expensive side of this line, because it is the side where the answers are worth having. Identity resolves at capture in the ICDB, relationships accumulate as evidence from the work itself, every number carries its scope, and the agents open with all of it in hand. The result is not a smarter agent than anyone else's. It is the same class of agent, handed the evidence instead of a search bar.

And full disclosure, agentic search exists in Signal9 too. When the resolved evidence runs thin, an agent can go looking, the way any agent can. It is just not the start, not the primary, not even routinely in the path. Their primary path is our fallback.

What is agentic search and why does it struggle in ITSM? Agentic search lets an AI agent find its own context at question time by searching your records and documents. It struggles in operations because the relationships that matter, which change touched which service, which alert preceded which incident, are not in the text. The agent infers them per question, so answers are non-deterministic and the context budget goes to searching instead of reasoning.

Why do AI agents in incident management give generic answers? Because the architecture makes them do retrieval before judgment. By the time an agent has assembled context by searching, much of its budget is spent and what it holds is a set of textually similar records rather than causally related ones. The generic summary is the best available output from that input, not a limitation of the model.

What is evidence-first architecture? An approach where the platform resolves identity and records relationships as operational activity happens, rather than having an AI agent search for them when a question is asked. Correlate on the way in, not on the way out. The agent then opens with the relationships already resolved and spends its full budget on judgment. The model's read may still vary, judgment does, but what was being judged never does, which is the variance that actually matters.

How is Signal9's AI different? Signal9 organizes operational evidence continuously, so entities, relationships and outcomes are recorded as the work happens. Its agents start from that resolved set instead of searching for context, answers show the evidence they rest on, and a tool is allowed to say there is not enough history rather than produce a confident guess.