Source: LangChain — 2026-08-05
Summary
LangChain built and open-sourced an autonomous SRE agent for Kubernetes, using its Deep Agents framework to triage cluster health, diagnose incidents, and propose remediations — while gating every write action behind a human-in-the-loop approval. The system is designed to cut time-to-triage and time-to-remediation without letting the agent make unsupervised changes to production infrastructure. The full implementation is open source at langchain-samples/sre-agent.
Key Takeaways
- The agent has unrestricted read access to the entire cluster (pods, logs, events, metrics) but zero unsupervised write access — every mutating action (scaling a deployment, restarting a rollout, patching an HPA) is gated by an explicit human-in-the-loop interrupt.
- It's built on LangChain's Deep Agents framework, which supports long-running, multi-step investigation rather than a single-shot "diagnose and respond" prompt.
- Every agent run is traced through LangSmith, and the team built evals specifically to measure triage accuracy and remediation correctness before trusting the agent with real incidents.
- The design choice to separate "diagnose" (autonomous) from "act" (human-gated) is presented as the actual product decision that made the agent viable for production SRE work, not a bolt-on safety feature.
Reel Script
Hook: An AI agent that can read every log, pod, and metric in your Kubernetes cluster — but is physically incapable of restarting a single deployment without your sign-off. That's not a limitation. That's the entire design.
Core Concept: LangChain built this SRE agent to solve the actual bottleneck in incident response, which isn't fixing things — it's figuring out what's broken in the first place. The agent runs on their Deep Agents framework, which just means it can take dozens of investigative steps in a row — pull logs, cross-reference events, check recent deploys — instead of guessing from one snapshot. Think of it like a junior engineer who never gets tired of grepping through logs at 3am. But here's the actual architecture decision that matters: they split the agent's permissions into two tiers. Read access is unrestricted — it can see anything in the cluster. Write access — scaling a deployment, restarting a rollout, patching an autoscaler — is hard-gated behind a human-in-the-loop interrupt. The agent literally cannot execute a mutating command without a person clicking approve.
Hands-On: Picture the actual flow: an alert fires, the agent starts pulling pod events and container logs in parallel, cross-references them against the last few deployments, and builds a hypothesis — say, a memory limit that's too low after a recent config change. It then proposes a specific fix, like bumping the HPA's max replicas or patching a resource limit. That proposal sits in a queue. A human sees the diagnosis, the proposed patch, and the reasoning trace — because every single step is logged through LangSmith — and either approves it or overrides it. Nothing gets applied to the cluster until that click happens. That's the pattern worth stealing for your own agents: separate the loop that investigates from the loop that acts, and put a hard permission boundary between them, not a prompt that just asks the model to "be careful."
Takeaway: This is the actual shape production agentic tooling should take right now — full autonomy on read and reasoning, zero autonomy on anything that touches state, until you've built the trust and the evals to justify loosening that gate. If you're building an ops agent and you haven't drawn that line explicitly in your permission model, you're one hallucinated diagnosis away from a bad night. Go read their repo before you build your own.