Operations | Monitoring | ITSM | DevOps | Cloud

The latest News and Information on Service Reliability Engineering and related technologies.

Building AI SRE Agents, Part 2: Leave the Laptop, Earn Trust

Moving the agent off your machine and pointing it at real clusters — read-only, in shadow mode — then climbing a trust ladder toward carefully scoped action. This is the second article in a three-part series on taking an AI SRE agent from a weekend experiment to enterprise production. Part 1 built a local agent on a throwaway cluster: read-only, propose-only, refined against a small eval set, with portable skills and no production write access.

Why AURA Scratchpad Is Rad: Bound the AI SRE Agent Context Window

A big tool result does not have to be a big context cost. AURA moves it to disk and hands the model a pointer plus the tools to navigate what is there. A large MCP tool result can consume or overflow an agent's context window, and on a third-party server you do not control how much comes back. Scratchpad breaks the link between how big a tool result is and how much context it costs: the full output goes to disk, and only the slice the model asks for ever enters the window. Errors always pass through inline, so the model can react to them.

Multi-Agent Orchestration for SRE: AURA Runs a Model per Specialist

Give one agent every tool and every incident is a question of trust. This one hands each job to a worker that can only reach what that job needs. One AURA configuration defines a coordinator and three specialist workers. Qdrant stores the runbooks, Prometheus measures workload health, and Kubernetes provides inspection and remediation, and each of the three is wired to one worker.

Run an AI SRE Agent Entirely Inside AWS with Bedrock and S3: AURA

An on-call question returns the threshold and the escalation owner from your own runbooks, and the answer comes back without a call to anyone outside. AURA runs against Bedrock as its model provider, using Claude Sonnet 5 served by AWS in the same region. Authentication is the normal AWS credential chain: a profile on a laptop, an IAM role in EKS.

What an AI SRE agent actually finds when you point it at a broken Kubernetes cluster

‍ Most of the AI features that shipped into observability tools this year summarize alerts. You get a paragraph that restates the dashboard you were already looking at, and the agent never reads the cluster itself, because giving it cluster access is a security conversation nobody wanted to start. This walkthrough starts it.

No Custom Adapter: AI SRE Agent AURA Debugs Product Catalog in Dash0

The platform shows you which service is failing and which paths it touches, and stops there. Point AURA at the same telemetry and the cause comes back too. Dash0 shows the product catalog service in a failed state across the selected window, with errors on the path from the frontend service.

Kubernetes AI SRE Agent Finds a Crash Loop Nobody Asked About: AURA

You ask for a routine health check and expect a clean baseline. What came back was a pod that had restarted 788 times, unrelated to the question. AURA is connected to a Kubernetes cluster and to Prometheus through read-only MCP servers, running as one coordinator with two specialized workers. The prompt is one sentence: check the health of the cluster, and confirm whether all the pods are running. What comes back is not a baseline. AURA names the state as CrashLoopBackOff and attaches the restart count to it.

Observe Opaque Services With OpenTelemetry eBPF + proxymock

Every SRE team operates services it cannot see into: a vendor binary, an inherited legacy deployment, a container whose owning team dissolved two reorgs ago. The routes are undocumented, the dependencies are unknown, and when a request takes 130 milliseconds nobody can say whether that time is application work or a wait across a network boundary.