An SRE agent stops starting from scratch: it writes detectors and playbooks, resolving recurring faults 2.1x faster
Synopsis
SDO, an operator agent for Kubernetes applications, distills each resolved incident into reusable operational memory: parameterized playbooks that record diagnosis and repair steps, non-LLM detectors that decide from cluster state which playbook applies, and an architecture summary that binds playbook roles to the current application. Across 11 open-source microservice applications, SDO cuts resolution time on recurring faults by 52%, with median resolution falling from 584 s to 282 s and tokens from 5.4M to 2.2M; when deploying applications from source, operational memory reduces deployment time and token use by 47.5%.
Interpretation
An operations agent now turns incidents it has handled into reusable operational memory instead of re-deriving causes for every event. Earlier LLM operations agents worked per incident and discarded their working context afterwards; they could not tell when an application was degraded, needed a human or an external alert to trigger them, and still investigated similar faults from scratch. Across 11 open-source microservice applications, SDO cuts resolution time on recurring faults by 52%, with median resolution falling from 584 s to 282 s and tokens from 5.4M to 2.2M, resolving 2.1x faster with 2.5x fewer tokens.
The memory consists of three readable, version-controlled artifact types, and detectors decide cheaply in steady state when to invoke which playbook. Storing raw incident histories in a vector store or letting the model retrieve them itself recalls records with similar symptoms but different root causes, and retrieval cost grows linearly with the number of incidents. On a fixed playbook corpus, detector retrieval reaches precision 0.48 and recall 0.73, close to model-driven retrieval at 0.53 and 0.77, but takes 10.8 s and zero tokens per retrieval versus 483.4 s and 148k tokens.
Deploying applications from source into Kubernetes is folded into the same memory, so deployment experience carries across applications. Without operational memory, the deployment agent repeatedly rediscovers service roles and build commands while chasing build and dependency errors, and long sessions exhaust the context window. Across 11 open-source applications, deployment with operational memory reduces deployment time and token use by 47.5% and iterations by 2.5; an independent health judge raises externally validated deployments from 4/11 to 11/11.
Perspective
The results target microservice applications running on Kubernetes, evaluated on 11 open-source applications, with the incident-resolution experiments using four of them over a deterministic 200-incident stream and the deployment experiment using all 11. Detectors are written as Go code against a fixed interface, and playbooks and the architecture summary live as version-controlled files in the application repository, so the setting is a deployment with a source repository and readable cluster state.
On novel faults with no overlap, detectors fired in 9 of 30 incidents, yet every surfaced playbook was a false positive that the agent had to inspect and discard; median token use was 17.7% higher than the memoryless configuration, with similar resolution time and accuracy. Memory was frozen during the test runs, so agents could not prune mis-firing detectors as they would in live operation.