An alert fires because a checkout service has started returning HTTP 500 errors.
An AI SRE begins investigating. It needs to determine which service is failing, which version is deployed, whether anything changed recently, what the logs and traces show, what probably caused the failure, and whether to restart the service or roll it back.
It is tempting to give all of that work to an LLM.
That is also where the architecture starts going wrong.
Some parts of incident investigation genuinely require reasoning. An LLM can help correlate a deployment with a latency spike, interpret an unfamiliar exception, or compare two competing root-cause hypotheses.
Other questions have exact answers.
Which commit is deployed? Which team owns the service? Is the error budget exhausted? Does the current identity have permission to restart the workload? These facts should come from authoritative systems, not probabilistic inference.
As AI SRE agents become more capable of querying production systems and participating in incident response, the important architectural question is no longer simply whether an LLM can investigate an incident.
It is which parts of the investigation should require an LLM at all.
A production AI SRE should use deterministic software where the answer can be established exactly and use LLM reasoning where uncertainty actually exists.
The Problem With an LLM-First AI SRE
The simplest AI SRE architecture looks appealing:
Alert
|
v
LLM --------> Metrics
| ----------> Logs
| ----------> Traces
| ----------> Kubernetes
| ----------> Git
| ----------> Incident history
v
Diagnosis
|
v
Action
The model receives an alert, decides which tools to call, interprets the results, produces a diagnosis, and possibly chooses a remediation.
This can work impressively in a controlled demo.
Production incidents are less forgiving.
Consider a model attempting to query a metric called:
checkout_connection_pool_active
The real metric is:
checkout_db_pool_active_connections
The query returns nothing.
The LLM now has at least two possible interpretations. The metric does not exist, or the query was wrong.
If there is no deterministic validation between the model and the observability system, the agent may confidently choose the first explanation and continue its investigation using a false assumption.
This is not theoretical as an architectural failure mode. Recent analysis of multi-agent systems for infrastructure observability describes how an agent can issue an incorrect metric query, receive an empty response, and interpret that response as evidence that the metric itself does not exist.
The larger problem is that an LLM can blur three very different things:
A fact retrieved from a system, an inference made from evidence, and an assumption created because evidence is missing.
For incident response, those distinctions matter.
An AI SRE should not infer a deployment SHA when the deployment platform already knows it. It should not decide whether a production restart is authorized when an access-control policy can answer the question exactly. It should not assume a query is valid when its schema can be checked before execution.
Better prompting can reduce some mistakes. Architecture can eliminate entire classes of them.
Divide Incident Response Into Deterministic and Probabilistic Work
A useful design exercise is to take every task performed during an incident and ask one question:
Could this operation be reliably expressed as a lookup, schema, policy, threshold, state machine, or executable test?
If the answer is yes, the LLM probably should not be the primary authority for that operation.
Consider a typical production investigation:
| Incident task | Best owner | Reason |
|---|
| Identify service owner | Deterministic | Service catalog already contains the answer |
| Retrieve deployed commit | Deterministic | Deployment system contains the exact state |
| Check SLO threshold | Deterministic | Mathematical evaluation |
| Validate log or metric query | Deterministic | Schema can be checked |
| Retrieve logs and traces | Tooling | Execution does not require reasoning |
| Correlate unusual signals | LLM | Requires contextual interpretation |
| Interpret an unfamiliar exception | LLM | Semantic reasoning is useful |
| Generate competing root-cause hypotheses | LLM | Requires inference from incomplete evidence |
| Verify infrastructure permissions | Deterministic | Policy decision |
| Check whether evidence contradicts a hypothesis | Hybrid | Reasoning plus explicit verification |
| Execute production remediation | Deterministic or human-gated | High-consequence operation |
This division does not make the AI SRE less capable. It gives the model a smaller and better-defined job.
The model should reason about what operational facts mean. It should not be responsible for inventing those facts.
A Hybrid Architecture for AI SRE
A safer architecture puts deterministic controls both before and after LLM reasoning.
+-------------------+
| Alert |
+---------+---------+
|
v
+-----------------------------+
| Deterministic Enrichment |
| Service / Owner |
| Environment |
| Deployment SHA |
| Recent Changes |
| SLO State |
+-------------+---------------+
|
v
+-----------------------------+
| Evidence Retrieval |
| Logs, Metrics, Traces |
| Events, Runtime State |
+-------------+---------------+
|
v
+-------------------+
| LLM Reasoning |
| Correlate |
| Hypothesize |
| Explain |
+---------+---------+
|
v
+-----------------------------+
| Deterministic Verification |
| Query validation |
| Evidence checks |
| Policy evaluation |
| Permission boundaries |
+-------------+---------------+
|
v
Human / Action Gate
The first deterministic layer enriches the incident with facts that should not require interpretation.
Instead of prompting an LLM to work out which deployment caused the problem, the system can provide:
{
"service": "checkout-api",
"environment": "production",
"deployment_sha": "a83f9c2",
"deployment_time": "14:03:17Z",
"incident_start": "14:07:42Z",
"owner": "checkout-platform"
}
The evidence layer then retrieves the logs, metrics, and traces relevant to that incident.
Only then does the LLM perform the work it is actually good at: correlating signals, interpreting unstructured information, finding relationships, and generating hypotheses.
The final layer is equally important.
The LLM produces a hypothesis. It should not be allowed to turn its own hypothesis into a verified fact.
That requires a verification step outside the reasoning loop.
A Worked Example: The Database Is Slow, but Is It the Root Cause?
Consider an API that begins returning intermittent 500 errors four minutes after a deployment.
The initial telemetry looks suspicious:
14:03 Deployment a83f9c2 completed
14:07 HTTP 500 rate begins increasing
14:08 Database latency increases
14:09 Checkout error rate reaches 7.8%
14:10 CPU remains normal
A model looking at this evidence might generate a reasonable hypothesis:
Increased database latency indicates connection pool exhaustion, causing checkout requests to fail.
The explanation sounds plausible. That does not make it true.
Start With Facts
The deterministic enrichment layer establishes the production context:
Service: checkout-api
Environment: production
Version: a83f9c2
Deployment time: 14:03 UTC
Incident start: 14:07 UTC
Owner: Checkout Platform
None of these values needs to pass through probabilistic reasoning.
Retrieve the Available Evidence
The investigation layer retrieves failed request traces, matching application errors, database pool metrics, the deployment diff, and recent infrastructure events.
The LLM now sees three important facts.
The failures started shortly after the application deployment. Almost every failed request executes the same validation path. Database latency increased at roughly the same time.
That produces at least two viable hypotheses:
- H1: Database connection pool exhaustion is causing requests to fail.
- H2: The new application code is allowing unexpected request state to reach the database layer.
The important step is what happens next.
The system should not ask the model to choose whichever explanation sounds more likely. It should determine what evidence would falsify or support each hypothesis.
For H1, that might mean checking active and maximum connection counts.
For H2, the missing piece might be the value of a request field at a specific line in the validation path.
When the Evidence Does Not Exist Yet
This is where incident investigation sometimes hits the limit of conventional observability.
Logs only contain values the application was instructed to record. Traces record instrumented operations and context. Metrics aggregate measurements chosen in advance.
If the variable needed to confirm a hypothesis was never captured, the LLM cannot recover it by reasoning harder.
The correct response to missing evidence is to obtain better evidence.
One approach is bounded runtime instrumentation. For example, a production debugging system such as HyperProbe can place a temporary read-only probe at a specific line and capture runtime state when live traffic reaches it. The important architectural property here is not the product itself. It is that the investigation gains new evidence without allowing the reasoning model to modify application state.
Suppose the capture returns:
customer.region = null
connectionPool.active = 34
connectionPool.max = 100
The investigation has changed materially.
The database pool is nowhere near exhaustion. The first hypothesis can be rejected.
The unexpected null value, combined with the deployment diff and failing code path, now provides evidence for the second hypothesis.
This is a better incident-response pattern than asking an LLM to repeatedly reinterpret the same incomplete telemetry.
It also highlights an important distinction between AI reasoning and observability: an agent can only reason from evidence that exists.
The same principle should apply whenever an AI SRE interacts with production systems.
An LLM can decide that querying a particular metric would help the investigation. It does not follow that the raw model output should be executed directly.
A validation layer can first check whether the requested tool exists, required parameters are present, the metric or field is valid, the requested time range is permitted, and the caller has access to the target environment.
This becomes more important as agents gain access to more systems. DZone's coverage of tool-call observability makes the related point that teams need visibility into which tools an agent invoked, what parameters were provided, whether those calls succeeded, and whether access controls were respected.
For an AI SRE, I would go one step further.
Tool calls should not only be observable after execution. Where possible, they should be validated before execution.
Suppose the model generates:
{
"tool": "query_prometheus",
"metric": "checkout_connection_pool_active",
"range": "15m"
}
A deterministic metric registry can reject the nonexistent metric before the query reaches Prometheus.
The LLM receives:
{
"status": "invalid_metric",
"suggested_matches": [
"checkout_db_pool_active_connections"
]
}
Now the model is reasoning from a known validation failure rather than an ambiguous empty result.
Separate Diagnosis From Authority
Production access is another place where prompting is a poor substitute for deterministic controls.
Telling an agent, “Never restart production unless absolutely necessary,” is not an authorization system.
A better design divides actions by consequence.
Reading telemetry may be fully automatic. Capturing bounded diagnostic evidence may be permitted under policy. Restarting a staging workload might be automatic. Restarting a production service could require approval. Database mutations might always remain behind an explicit human gate.
The actual thresholds will vary by organization. The architectural principle does not.
The model can recommend an action.
A separate system decides whether that action is authorized.
This is where human-in-the-loop approval gates become more useful than placing a human behind every single AI operation. Human review should concentrate on consequential or ambiguous actions rather than routine evidence gathering.
An investigation agent that requires approval every time it reads a log will create new toil. An agent that can restart a stateful database because the prompt described it as “safe” has the opposite problem.
The LLM Still Has an Important Job
A hybrid architecture is not an argument against using LLMs in SRE.
Quite the opposite.
Incidents routinely produce large amounts of heterogeneous and partially structured evidence. A human might need to move between logs, dashboards, traces, deployment histories, runbooks, source code, and previous incidents before forming a plausible explanation.
LLMs can be effective at synthesizing that context.
They can recognize relationships across signals, interpret unfamiliar errors, search previous incident reports, generate competing hypotheses, identify what evidence is still missing, and explain a complex investigation to the on-call engineer.
These are probabilistic tasks.
The distinction can be summarized simply:
Deterministic systems are good at answering what is true when the truth is encoded somewhere. LLMs are useful for reasoning about what those facts might mean.
An effective AI SRE needs both.
Even agentic SRE architectures that allow systems to observe, reason, and act still depend on strong guardrails and observability around that reasoning.
The goal should not be maximum autonomy. The goal should be useful autonomy inside explicit operational boundaries.
Verify the Architecture With Operational Metrics
A hybrid design should also be evaluated differently from a chatbot.
Response quality alone is not sufficient.
An SRE team should be able to measure whether an agent generated invalid tool calls, retrieved evidence relevant to the actual failure, made claims unsupported by telemetry, attempted actions beyond its permissions, or required unnecessary calls before reaching a useful hypothesis.
For example:
| Metric | What it tells you |
|---|
| Invalid tool-call rate | Whether the agent understands its operational interfaces |
| Evidence precision | Whether retrieved signals actually support the investigation |
| Unsupported-claim rate | How often conclusions outrun available evidence |
| Time to confirmed hypothesis | Whether the system reduces investigation time |
| Tool calls per incident | How efficiently it investigates |
| Unsafe action attempts | Whether policy boundaries are working |
| Root-cause accuracy | Whether the final diagnosis matches known outcomes |
This is also why end-to-end observability for agents and workflows matters. If an AI SRE reaches the wrong conclusion, engineers need to reconstruct the investigation: which context was provided, which tools were called, what each tool returned, what hypothesis was generated, and why the workflow proceeded to the next step.
Without that trace, debugging the AI SRE itself becomes another production incident.
Use AI for Uncertainty and Software for Certainty
The interesting question in AI SRE is not how many operational tasks can be handed to an LLM.
It is where probabilistic reasoning creates enough value to justify probabilistic behavior.
Service ownership, deployed versions, access policies, thresholds, schemas, and permissions already have deterministic representations. Keep them deterministic.
Use the LLM where SRE work genuinely requires interpretation: correlating signals, understanding unstructured evidence, generating hypotheses, comparing explanations, and deciding what evidence to gather next.
Then verify its conclusions outside the model.
And when the available telemetry cannot confirm a diagnosis, do not ask the LLM to become more confident. Gather the missing evidence.
That architecture may look less autonomous than an LLM connected directly to every production tool.
In practice, it is much closer to what reliability engineering has always been about: allowing flexible reasoning where it helps while making critical behavior predictable where it matters.