AI Agent for Evidence-Based Diagnosis
Diagnosis goes wrong when the first plausible explanation becomes the only one investigated. This agent reads the logs, the symptoms and your runbooks, and returns several candidate causes ranked by the evidence behind them — each with the one test that would confirm or eliminate it.
What is an AI troubleshooting agent?
An AI troubleshooting agent is a governed software worker that diagnoses technical faults from evidence. It collects the relevant log extracts, metric movements and configuration state around a fault window, matches them against runbooks and past incidents, and returns ranked candidate causes each paired with a test that would confirm or eliminate it.
What it does
What it is not
The first explanation that fits becomes the only one tested
Under time pressure, diagnosis collapses into the first hypothesis that matches the symptom. Two hours later it turns out to have been a coincidence, the evidence that would have ruled it out in five minutes was in a log nobody opened, and the actual cause was the third thing anyone would have thought of.
Logs are too large to read
The decisive line is in a file with two million others, and grep only helps if you already know what you are looking for.
Correlation reads as causation
Something changed shortly before the fault, so it becomes the explanation, and the real trigger goes uninvestigated.
Runbooks cover the known cases
The procedure exists for faults that have happened before, and the current one is a variation nobody has written up.
Nobody records what was eliminated
The next engineer on shift repeats the checks the last one already did, because only the conclusion was written down.
Differential diagnosis, with the evidence attached
Evidence
Find The Lines That Matter
Across logs, metrics and config.
Log extracts, metric movements, configuration state and recent changes are gathered around the fault window and reduced to the entries that actually bear on the symptom, quoted with their timestamp and source file rather than paraphrased.
- Evidence gathered around the fault window
- Log lines quoted, not summarised away
- Source file and timestamp kept
- Absence of an expected entry is evidence too
With source and time
Hypotheses
Several Candidates, Ranked
And what would disprove each.
Rather than returning one answer, the agent produces a ranked differential: each candidate cause with the evidence supporting it, the evidence that argues against it, and the single cheapest observation that would settle whether it is the one.
Each falsifiable
Runbooks
Your Procedures, Matched To This Fault
Including the near misses.
Runbooks and past incident records are matched against the current symptom pattern, and where the fault resembles a documented case without matching it exactly, the agent says which parts of the procedure apply and which assumption does not hold.
Including partial fits
How the AI Troubleshooting Agent runs a task
- STEP 01
Pin down the symptom
The reported behaviour is turned into an observable statement with a time window, an affected component and a comparison case, because a fault described as slowness cannot be investigated until it is expressed as something measurable.
Symptom framingWindow selection - STEP 02
Collect the evidence
Logs, traces, metric series, configuration state and the change record for the window are retrieved, and the entries that discriminate between possible causes are separated from the far larger volume that does not.
Log retrievalTrace fetchChange lookup - STEP 03
Build the differential
Candidate causes are generated from the evidence, from runbook entries for this component, and from past incidents with a comparable signature, then ranked by how much of the observed evidence each one actually accounts for.
Hypothesis generationRunbook matching - STEP 04
Name the discriminating test
For each candidate the agent identifies the cheapest observation that would separate it from the others — a specific log query, a metric to compare, a configuration value to read — and states what each outcome would mean.
Test selectionOutcome mapping - STEP 05
Record the eliminations
As tests are performed and results returned, ruled-out candidates are written into the ticket with the evidence that eliminated them, so the record of what is no longer worth investigating survives the shift change.
Elimination logTicket update
Systems the AI Troubleshooting Agent connects to
Evidence sources
Analysis
Inputs, outputs and runtime
- Ingests
- Symptom descriptionFault time windowApplication and system logsMetric seriesRunbooks and past incidents
- Produces
- Ranked candidate causesQuoted supporting evidenceDiscriminating test per candidateEliminated causes listRunbook fit assessment
- Triggered by
- Escalated ticketEngineer requestIncident bridge question
- Human oversight
- Engineers run tests and apply any fix
- Models
- Open-weight LLMs you host — Llama, Qwen or Mistral class
- Typical latency
- Minutes for a bounded fault window
- Deployment
- On-premise or sovereign cloud with egress control
- Data residency
- Logs are analysed where they already sit
Where the Troubleshooting Agent pays back
Intermittent Fault Analysis
Find what the failing occurrences share and what distinguishes them from the successful ones in the same window.
Post-Deployment Regressions
Compare behaviour either side of a release and isolate which change is consistent with the observed failure signature.
Performance Degradation
Separate saturation, contention and a slow dependency using the metric and log evidence rather than the usual assumption.
Escalation Preparation
Give third-line or a vendor a package with the symptom, the evidence and everything already eliminated.
Shift Handover
Pass on what has been ruled out and why, so the incoming engineer does not repeat four hours of checks.
Runbook Gap Discovery
Surface the faults where no procedure matched, which is the list the documentation team should be working from.
AI Troubleshooting Agent vs chatbots and SaaS copilots
Asking a general model about a symptom returns the most frequent cause of that symptom across the internet, which is a prior, not a diagnosis — and priors are exactly what mislead an engineer at three in the morning.
| Generic chatbot | SaaS copilot | VDF AI | |
|---|---|---|---|
| Evidence used | General knowledge | What you paste | Your logs for that window |
| Number of causes | One confident answer | One suggestion | A ranked differential |
| Citations | None | Rarely | Quoted lines with timestamps |
| Next step | Try the common fix | Generic advice | The cheapest discriminating test |
| Eliminations | Not tracked | Not tracked | Recorded against the ticket |
| Applies the fix | Suggests freely | Sometimes executes | Never — engineers act |
| Log exposure | Pasted to vendor | Vendor tenancy | Stays in your environment |
Governance and controls
Log data is the most sensitive operational material most organisations hold without treating it as sensitive: it contains credentials people pasted by accident, customer identifiers in error payloads, and a complete map of internal naming.
Read-only diagnosis
No command execution on live systems
Secret redaction
Credentials in logs masked on read
Evidence citation
Every claim names its log source
Uncertainty stated
Weak hypotheses are labelled as weak
Scoped log access
Only systems the engineer may see
Fix requires approval
Proposed actions go to an engineer
Evidence it leaves behind
What changes after rollout
Who runs the AI Troubleshooting Agent
Second-line engineer
Starts from a differential rather than a hunch, and spends the first twenty minutes running the test that separates two candidates instead of pursuing whichever explanation came to mind first.
On-call engineer at 3am
Gets the relevant log extracts already pulled and quoted, which removes the part of night-shift diagnosis most likely to go wrong: searching enormous files while tired and under pressure to restore service.
Problem manager
Sees which faults had no matching runbook and which hypotheses keep recurring across unrelated incidents, turning problem management into something driven by recorded evidence rather than by which incident was loudest.
Questions about the AI Troubleshooting Agent
What is an AI troubleshooting agent?
It is an agent that performs evidence-based diagnosis: gathering log extracts, metric movements and configuration state around a fault, matching them against your runbooks and past incidents, and returning ranked candidate causes with the test that would settle each.
How is an AI troubleshooting agent different from a generic chatbot?
A chatbot offers the most common cause of a symptom in general. This agent reads your actual logs from the actual window, quotes the lines it relied on, and tells you which of its candidates the evidence argues against.
Can an AI troubleshooting agent run on-premise on system log and runbook data?
Yes. Logs contain hostnames, account identifiers, query fragments and sometimes customer data in error payloads, so the analysis runs where those logs already live rather than being uploaded anywhere.
What does an AI troubleshooting agent produce, and in what format?
A ranked differential: each candidate cause with quoted supporting evidence, contradicting evidence, a discriminating test, plus the runbook fit and an explicit list of what has been eliminated.
Where does an AI troubleshooting agent fit in a governed AI programme?
It diagnoses and stops. Applying a fix, restarting a service or changing configuration is executed by an engineer through your change process, and coordination of a live outage belongs to the incident response agent.
Can it run diagnostic commands on a server itself?
No. It reads logs, metrics, traces and configuration through read-only interfaces and proposes the command an engineer should run, together with what each possible output would mean. Granting a diagnostic agent shell access on production is how a troubleshooting tool becomes an outage: the boundary is deliberate and is enforced by the connection, not by instruction.
What if the evidence supports two causes equally?
Then it reports both at equal confidence and concentrates on the discriminating test, which is the useful output in that situation. Forcing a single answer where the evidence does not support one is the failure mode that costs the most time, because the resulting confidence stops anyone checking the alternative.
How does it handle logs containing credentials or personal data?
Secrets and obvious credential patterns are masked as the logs are read, and personal data in error payloads is handled under the same access rules as the source system — the agent cannot widen who can see a log line by quoting it. Evidence citations reference the location and timestamp, so a reviewer with the right access can always go back to the original.
Does it work on systems that have no runbook at all?
Yes, and that is a common case. Without a runbook it relies on the evidence, comparable past incidents, and the structure of the component, and it states plainly that no documented procedure matched. Those cases are also reported as runbook gaps, which over time turns undocumented diagnosis into a prioritised documentation backlog.
Where does it stop and the incident response agent begin?
This agent answers what is wrong; the incident response agent runs the outage around that question. During a major incident both are usually active — one building the differential for the engineers on the bridge, the other maintaining the timeline, correlating changes and drafting updates. Outside an incident this agent is used on its own for escalated tickets and problem records.
Start the next diagnosis from evidence
See the AI Troubleshooting Agent build a ranked differential from your own logs.