What we learned building AI-assisted root cause analysis on customer support archives — and why we stopped giving the model the data.
Reader takeaway: The bottleneck in AI-assisted troubleshooting is not the model. It is what you put in front of it. Give an AI the files and you get an expensive guess. Give it the right tools and a map of where to look, and you get a root cause.
Every support organization opens its hardest cases the same way. A customer hits a problem and files a complaint — a few sentences describing what they saw, in their words. Attached to it is a bundle: a compressed archive of everything their system could produce. Nested archives inside nested archives. Configuration, counters, traces, application logs, crash dumps. Thousands of files, most of them irrelevant to this particular case, a handful of them decisive.
The whole job is bridging those two things. The complaint says what the customer noticed; the archive holds what the machine knows. Somewhere in it are the few lines that connect them.
The obvious thing to do with a large language model is to hand it the bundle. That instinct is where most AI troubleshooting projects begin, and it is also where most of them quietly stall.
Why "just give the AI the files" does not survive contact with a real case
Three things break at once.
It does not fit. A single support bundle routinely expands into thousands of extracted files. Even the largest context windows available today are measured in hundreds of thousands of tokens, and one real case can exceed that before you have written a single word of instruction.
The cost is unbounded and unpredictable. If the size of the input is the size of the customer's archive, you cannot forecast what a case costs to analyze. That is not a budgeting inconvenience — it is what stops a tool from being used daily by a support team, which is the only usage that matters.
Accuracy gets worse, not better. This is the part that surprises people. Filling a context window with mostly irrelevant data does not give the model more to work with; it dilutes the signal it needs. The model spends its attention on noise, and the answer comes back confident and vague.
So the file-dumping approach fails on all three axes at once: too big, too expensive, and less accurate than doing less.
What we built instead: the model gets tools, not data
Radware's Root Cause Studio inverts the flow. An engineer pastes the fileshare link and writes a short summary of the issue — the complaint, in two or three sentences. The system downloads the bundle, recursively extracts every nested archive, and builds a per-case search index. At that point the data is ready — and the AI has not seen a byte of it.
That short summary is doing more work than its size suggests. It is the only part of the input that states what we are actually looking for, and it costs a handful of tokens. It decides which part of the knowledge base the agent consults first and which files are worth opening at all — the difference between an investigation and an exploration. Skip it, and the tool has to search the archive just to work out what the case is about, which is precisely the expensive habit we set out to avoid.
What the AI receives is a toolbox: roughly two dozen tools for listing directories, locating files by name across every level in one call, inspecting a candidate file's size, format and time range, and searching extracted content. That catalog costs about 6,000 tokens per turn, and it is fixed. It does not grow with the size of the customer's archive.
The critical design rule is that no tool returns a whole file. Search comes back as line-level matches — file name, line number, the matching line — capped so that an over-broad query returns "narrow this" rather than a silent flood. The model greps; it never holds the archive. Our search engine already worked this way for human users, and the discipline in building the AI layer was exposing it as tool calls without regressing that property.
The system prompt carries the same rule as an operating principle: look before you search. Locate the file, inspect it, then query it. An empty result means "I searched the wrong file," not "the evidence is not there" — and the model is explicitly told not to answer a miss by widening the search to everything.
The knowledge base is the map, not the payload
Tools alone would still leave the model guessing about where to look. Knowing that a counter exists is not the same as knowing that this counter, at this threshold, alongside that log line, is the known signature of a specific failure. That knowledge lives in the people who work the cases — in our case, the Radware support engineers who have been resolving them for years.
We captured it as an integrated, Markdown-based knowledge base: guidelines per subsystem, known-issue signatures, normal-versus-abnormal baselines, investigation sequences, and — importantly — explicit links between related documents.
The linkage is what makes it efficient. The agent does not load the knowledge base. It asks for the highest-ranked snippets for the question actually in front of it, reads those, and follows a link to the next document only when the investigation has progressed far enough to need it. A full document is fetched only when a snippet is not enough. Related documents are bundled into reusable packs, so a known starting point loads in one call instead of ten.
The effect is that the model's context stays small and stays relevant, and it grows along the shape of the investigation rather than the shape of the archive. Figure 1 traces the whole flow, from the complaint to the answer.
Figure 1: From complaint to root cause. Extraction and indexing happen entirely outside the model. What enters the AI's context is the short issue summary, a fixed tool catalog, and the specific evidence each step calls for — never the archive itself.
Why this is a Radware architectural position, not a prompt trick
Two choices here are worth calling out, because they are where we diverge from the common path.
Every tool result passes through our own code. Several AI platforms now offer to connect the model directly to external data sources for you. It is convenient, and we deliberately did not use it. When results never pass back through our own layer, nothing we write can scope them, cap them, log them, or attribute their cost. Restricting a model to the right data has to be enforcement, not a hint in a prompt the model is free to ignore — particularly when the data in question is a customer's diagnostic bundle on a shared, multi-tenant deployment.
The investigation loop is bounded on purpose. A turn gets a fixed budget of tool round trips. Running out does not throw the work away: the model is required to answer from the evidence it has already gathered, cite it, and state plainly what it did not get to check. An honest partial answer with its sources attached is worth considerably more to a support engineer than a complete-sounding one without them.
Many existing approaches still start from "how much of this can we fit in the context window." We started from the opposite question: how little.
What the support engineer actually gets
A case that arrives as a complaint and an opaque archive comes back as a root cause with the file and line number behind every claim, the workaround or corrective action that follows from it, and a clear statement of what was checked and what was not. It arrives in minutes — and because the input is the investigation rather than the archive, a large case costs roughly what a small one does.
The generalizable lesson has very little to do with which model you pick. Most of the value came from the parts of the pipeline that run before the model is involved at all: the extraction, the index, and above all the codified expertise that tells the AI where to look next.
If you are evaluating AI for technical operations, that is the question worth asking your vendor. Not which model is behind it. Ask what enters the context window, who decides what goes in, and whether that decision is enforced or merely suggested.