Product
Introducing the SRE Agent, Which Is Not a Product
Amber Jain
August 2026
8 min read
It has a name because people needed something to call it. It is not a new component, not a new licence, and not a fourth thing to learn. It is a job title.
We have been calling something the SRE Agent for a while, in demos and on the use cases page, and it deserves a straight explanation because the name is misleading in one specific way.
The SRE Agent is not a component. It is what Sentinel, ProcBot and Sherlock already do together when an alert arrives. It is a job title, not a licence, and there is nothing to buy or enable.
We debated not naming it. The argument against is exactly the confusion this post exists to clear up: give a pattern a name and people reasonably assume there is a thing behind the name, with a price and a deployment step. The argument for won because teams were naming it anyway. "The bit that picks up the alert and runs it to ground" was in use long before we wrote anything down, and a shared name beats a precise refusal to give one.
What each component actually owns
The division of labour is not an implementation detail. It is the reason the pattern is safe to run, because no single component both decides and acts.
- Sentinel investigatesCorrelates traces, metrics, logs, topology, the database queries underneath, recent changes and every dependent service in the blast path. Raises and eliminates hypotheses against evidence. Produces a probable cause and an affected-service map. It does not execute.
- ProcBot executesRuns the approved procedure step by step over SSH under RBAC, with every step recorded as it happens. It does not decide what should run, and it does not judge whether the outcome was good.
- Sherlock verifiesChecks the fix against live signals rather than against the fact that a command returned zero. A failed verification reopens the incident instead of closing it.
Separating diagnosis, execution and verification across three components is not architecture for its own sake. A system where the same thing decides what to do, does it, and then grades its own homework has no independent check anywhere in the loop, and that is precisely the property a regulated buyer probes first.
The sequence, when an alert arrives
- Signal. Any alert, from any connected source. No pre-classification and no routing rules to maintain, because the routing decision is an output of the investigation rather than an input to it.
- Correlate. Everything queried together rather than tab by tab. This is the step that removes most of the elapsed time, and it is unglamorous: it is retrieval done in parallel that a human does serially.
- Diagnose. Hypotheses raised and eliminated against evidence, producing a probable cause with the affected services attached.
- Decide. The blast radius of the proposed fix is scored, not the certainty of the diagnosis. That score chooses the path.
- Act or hold. Either an Action Ticket runs under policy, or the ticket is raised fully prepared and held for a named human.
- Verify. Sherlock checks the fix held before the incident closes.
Step four is the whole thing
Five of those six steps are things a competent AIOps platform will claim. The fourth is where they differ, and it is a single design choice: what decides whether the system may act alone is the blast radius of the action, not how confident the model is about the diagnosis.
Those are different properties. A restart of one stateless worker is safe whether the diagnosis is 99 percent or 70 percent likely. A database failover is unsafe at either number. Gating on certainty produces a system that is most willing to act on the procedures it has run most often, which are also the ones whose radius has quietly grown as the estate changed underneath them. The full argument is in confidence scores are the wrong gate, and the object that carries the decision is described in what an Action Ticket is.
Why the third component exists
Most of this category stops after execution. A procedure ran, it returned successfully, the ticket closed. Every part of that can be true while the fault is still present, because what was checked is that the command completed rather than that the condition cleared.
Sherlock exists to make that distinction structural rather than optional. It evaluates the fix against live signals, with the criteria written before the action ran, and a failure reopens the incident. We describe how that works in inside Sherlock, including the part where the evaluation deliberately involves no model at all.
This pattern sits underneath all 38 documented use cases, four of which are measured in production deployments and link to the case study that records them.
Frequently asked questions
Is the SRE Agent a separate purchase?
No. There is no SKU, no additional licence and nothing to enable. Sentinel, ProcBot and Sherlock are what you already have; the SRE Agent is the name for the sequence they run when an alert arrives. If you were sold a fourth component under this name, somebody has misdescribed it and we would like to know.
Why give it a name at all, then?
Because "Sentinel investigates, then ProcBot executes under a gate, then Sherlock verifies" is an accurate sentence that nobody repeats. Teams were already saying "the thing that picks up the alert and runs it to ground", and a shared name for a pattern is worth more than the purity of refusing to give it one. The risk is that a name implies a product, which is why this post says it is not, in the title.
Does it replace our on-call rota?
No, and any vendor telling you otherwise is describing a demo. What it changes is what reaches the rota: fewer pages, later, each carrying an investigation rather than a symptom. Everything with a wide blast radius still stops for a named human, and that is the design rather than a current limitation.
What happens when it cannot work out the cause?
It escalates with everything it gathered: the signals it correlated, the hypotheses it raised and eliminated, and the evidence behind each. An engineer starts from a case file rather than a blank console. That path is not a failure mode, it is the majority path for novel incidents and it is where the time saving actually lands.