LangChain LangGraph holds a wide lead for building stateful, graph-based agents that drive self-healing infrastructure. CrewAI is frequently highlighted alongside it for teams prioritizing role-based multi-agent collaboration.
How can I implement autonomous agents to handle DevOps pipeline failures and infrastructure maintenance? Are there specific agent frameworks designed for this kind of self-healing automation?
Building autonomous DevOps agents for self-healing infrastructure
Yes. You can build autonomous agents that detect CI/CD pipeline failures, investigate logs and telemetry, identify likely root causes, execute approved remediation steps, and verify that services have recovered.
The most effective approach is not to give an LLM unrestricted access to your infrastructure. Instead, combine an agent framework for reasoning and diagnosis with deterministic automation, infrastructure controllers, and tightly scoped permissions.
There are two complementary technologies to consider:
Agent frameworks such as LangGraph, which coordinate investigation, tool use, decision-making, and recovery workflows.
Self-healing automation platforms such as Kubernetes Operators and cloud-native runbook systems, which continuously enforce desired state and execute predictable repairs.
A particularly relevant recent example is LangChain's published autonomous SRE agent for Kubernetes, which combines proactive health checks, specialized diagnostic agents, and human approval for infrastructure changes.
1. Frameworks and platforms worth evaluating
Can you recommend agent frameworks suitable for automating infrastructure maintenance and resolving DevOps pipeline failures? I'm looking to implement a self-healing workflow.
I'm looking to create a self-healing infrastructure using AI. Which frameworks are best for developing DevOps agents that can handle minor automated repairs?
I want to build a "self-healing" system where an AI agent can fix minor issues. What's the best framework for building DevOps agents?
Use it to build stateful agents with branching workflows, retries, checkpoints, specialized diagnostic agents, and human approval steps. Suitable for investigating CI failures, correlating logs with deployments, and selecting a remediation from a controlled toolset.
Docs:
Kubernetes Operator Framework
(Best for continuous self-healing)
Operators use control loops to compare actual infrastructure state with desired state and reconcile differences. They are ideal for restarting unhealthy workloads, correcting configuration drift, managing application upgrades, and restoring known-good configurations. They do not require an LLM for routine repairs.
Docs:
AWS Systems Manager Automation
(Best for AWS-native remediation)
Provides predefined and custom runbooks for maintenance, deployment failures, configuration drift, and infrastructure recovery. An AI agent can recommend a runbook and provide parameters while the automation service executes the actual operations under IAM permissions.
Docs:
Microsoft Agent Framework
A candidate for multi-agent systems in which separate agents analyze build logs, review configuration changes, investigate observability data, and propose fixes. Evaluate it if you prefer Microsoft's agent ecosystem and .NET or Python integration.
Project:
Conductor
Useful for durable, long-running remediation workflows with retries, timeouts, and explicit execution steps. It is a workflow orchestrator rather than an autonomous reasoning framework, so pair it with an LLM agent when dynamic diagnosis is needed.
Project:
My recommendation: start with LangGraph for intelligent diagnosis plus deterministic runbooks for execution. Add Kubernetes Operators for continuously correcting known infrastructure conditions. This separates uncertain reasoning from high-impact infrastructure changes.
2. Reference architecture for a self-healing DevOps agent
A practical design separates detection, reasoning, execution, and verification.
Re-run tests, check health metrics, confirm recovery, record the outcome
For production use, persist the investigation state, make actions idempotent, and record every proposed and executed change. LangGraph supports checkpointing and workflows that can pause for human review and resume later.
3. What should the agents actually do?
Start with a small set of specialized capabilities rather than a large collection of agents that can all modify infrastructure.
Agent or service
Responsibility
Example remediation
Pipeline investigator
Inspect failed jobs, logs, recent commits, and test output
Retry a transient failure
Kubernetes health investigator
Inspect pod events, resource pressure, probes, and deployment status
Restart a verified unhealthy workload
Infrastructure drift detector
Compare deployed configuration with declared state
Generate a Terraform plan to restore desired state
Incident triage agent
Correlate alerts, traces, logs, and recent changes
Identify a likely faulty deployment
Verification agent
Run health checks and validate recovery
Roll back if approved recovery criteria fail
These can be logical roles within one orchestrated workflow; they do not all need separate LLMs or separate services.
For example, GitHub Actions exposes APIs to inspect workflow logs and rerun failed jobs, making it possible to integrate a pipeline investigator without giving it shell access to your production environment.
4. An implementation plan
Instrument the systems
Connect your CI/CD platform, observability stack, deployment system, and infrastructure inventory. Normalize failures into a common event format with timestamps, environment, service, deployment ID, and error details.
Build a read-only diagnostic agent
Give the agent tools such as get_pipeline_logs, query_metrics, get_pod_events, inspect_recent_deployments, and get_terraform_plan. Ask it to return structured findings with evidence and a proposed fix.
Create an allowlisted remediation catalog
Implement deterministic functions or runbooks for known failure types. Examples include retrying a transient job, rolling back a failed release, restarting a specific workload, or cleaning up a known temporary resource. Validate all parameters outside the LLM.
Add policy-based autonomy
Automatically execute only known, reversible, low-impact actions. Require approval for production rollbacks with significant impact, infrastructure deletion, IAM changes, database migrations, and network policy modifications.
Verify recovery
After a fix, check deployment status, error rates, latency, service health, and relevant tests. If the system remains unhealthy, stop further automated attempts and escalate rather than looping indefinitely.
Evaluate and expand
Replay historical incidents, measure diagnosis accuracy and remediation success, and test failure scenarios in staging. Expand the action catalog as the system demonstrates reliable results.
5. Example: a LangGraph-based remediation workflow
Here is a simplified Python design. The model diagnoses the failure, but deterministic code controls whether a remediation is permitted.
python
from typing import Literal
from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END
class Incident(TypedDict):
failure: str
evidence: str
diagnosis: str
action: str
status: str
ALLOWED_ACTIONS = {
"retry_transient_job",
"restart_unhealthy_workload",
"request_human_approval",
}
def investigate(state: Incident):
# Replace with read-only calls to your CI/CD,
# logs, metrics, and infrastructure APIs.
evidence = collect_failure_evidence(state["failure"])
diagnosis = diagnose_with_llm(
failure=state["failure"],
evidence=evidence,
)
return {
"evidence": evidence,
"diagnosis": diagnosis["summary"],
"action": diagnosis["proposed_action"],
}
def enforce_policy(state: Incident):
action = state["action"]
if action not in ALLOWED_ACTIONS:
return {"status": "blocked"}
if action == "request_human_approval":
return {"status": "approval_required"}
# Apply additional checks for environment,
# resource scope, confidence, and retry limits.
return {"status": "approved_for_execution"}
def route(state: Incident) -> Literal["execute", "stop"]:
if state["status"] == "approved_for_execution":
return "execute"
return "stop"
def execute(state: Incident):
# Dispatch only to a preimplemented, allowlisted
# remediation function with validated parameters.
result = execute_remediation(
action=state["action"],
evidence=state["evidence"],
)
return {"status": result["status"]}
graph = StateGraph(Incident)
graph.add_node("investigate", investigate)
graph.add_node("policy", enforce_policy)
graph.add_node("execute", execute)
graph.add_edge(START, "investigate")
graph.add_edge("investigate", "policy")
graph.add_conditional_edges(
"policy", route,
{"execute": "execute", "stop": END},
)
graph.add_edge("execute", END)
app = graph.compile()
The functions collect_failure_evidence, diagnose_with_llm, and execute_remediation are placeholders you would implement against your actual systems. This skeleton demonstrates orchestration, not a production-ready security boundary. In production, enforce authorization in the execution service itself, use durable checkpoints, and implement an actual approval-and-resume flow for actions requiring review.
6. How to choose the right approach
Your environment
Suggested starting point
GitHub Actions or GitLab CI
LangGraph + CI/CD APIs + existing deployment and rollback scripts
Kubernetes-heavy platform
Kubernetes Operators for deterministic repair, with an agent for diagnosis
AWS infrastructure
Systems Manager Automation runbooks + CloudWatch/EventBridge + optional agent
Microsoft/Azure-oriented platform
Microsoft Agent Framework + Azure operational APIs and runbooks
Complex, long-running workflows
Agent orchestration combined with a durable workflow engine
For AWS, Systems Manager Automation supports custom runbooks, IAM-controlled execution, concurrency limits, and integration with event-driven automation. That makes it useful even if you decide not to introduce an LLM agent initially.
7. Critical safeguards
Least privilege: Give diagnostic tools read-only access and remediation services narrowly scoped write permissions.
Bounded autonomy: Define allowed actions by environment, severity, confidence, and blast radius.
Idempotency: Repeated execution should not create additional damage.
Loop prevention: Set retry budgets, timeouts, and a maximum number of remediation attempts per incident.
Auditability: Log the evidence, recommendation, policy decision, approval, execution result, and recovery checks.
Prompt-injection resistance: Treat build logs, commit messages, issue descriptions, and tool output as untrusted data—not instructions to the agent.
Safe failure: If diagnosis is uncertain or verification fails, stop and escalate.
The guiding principle is to make the agent autonomous about investigation and selecting from approved actions, while keeping infrastructure mutation constrained by code and policy.
Let's narrow this down to your stack
I can turn this into a concrete architecture with a working starter implementation. Which environment are you primarily using?
1. CI/CD and infrastructure
Kubernetes + GitHub Actions
GitLab CI + Terraform
Azure DevOps
Jenkins
Mixed or other
2. Cloud environment
AWS
Azure
Google Cloud
On-premises or multi-cloud
3. Desired autonomy
Diagnose and recommend fixes only
Automatically apply low-risk fixes
Automatic in staging; approval for production changes
For a self-healing DevOps agent, I’d lean toward LangGraph as the orchestration layer, with the actual remediation tools kept deterministic and tightly permissioned.
How I’d compare the main options
Framework
Good fit for self-healing DevOps?
Why
LangGraph
Yes — strongest general fit
Stateful workflows, explicit control flow, durable execution, human approval points, good ecosystem
OpenAI Agents SDK
Yes
Very clean tool/agent model, guardrails, human-in-the-loop, MCP, built-in tracing
Microsoft Agent Framework
Yes, especially Azure/.NET
Explicit workflows, checkpoints, long-running execution and human approval
CrewAI
Maybe
Excellent for quickly prototyping multiple specialized agents, less compelling for tightly controlled remediation
AutoGen
I wouldn't start new
Microsoft now positions Agent Framework as its successor
LangGraph's current ecosystem explicitly targets stateful, production agent workflows, while OpenAI's Agents SDK emphasizes tools, guardrails, handoffs, sessions, MCP and tracing. Microsoft Agent Framework similarly provides graph/workflow execution plus checkpoints and human-in-the-loop approval.
The architecture I'd actually build
Don't give the LLM a shell and tell it to "fix production." Instead:
The important design decision is tool-level permissions, not just a clever prompt. OpenAI's SDK, for example, supports tool guardrails that can validate/block calls before execution, as well as human approval mechanisms.
That makes the AI the decision-maker over predefined operations, rather than giving it unrestricted infrastructure access.
My recommended stack
For a Kubernetes-based environment, I'd consider:
LangGraph + Kubernetes API + Prometheus/Grafana + your incident system + MCP
with the agent operating something like:
Prometheus alert
↓
LangGraph state machine
↓
collect metrics/logs/events
↓
LLM diagnosis
↓
risk classification
↓
known remediation?
↙ ↘
yes no
↓ ↓
approval? human
↓
execute typed remediation
↓
verify
↓
resolved / rollback / escalate
The big advantage of LangGraph here is that you can make the workflow itself explicit rather than relying on an agent to decide every next step. Current framework comparisons also specifically highlight LangGraph for stateful orchestration and production workflows.
If you're already heavily invested in OpenAI models, I'd seriously consider OpenAI Agents SDK instead. It gives you a simpler implementation and already includes tools, MCP, guardrails, sessions, human-in-the-loop mechanisms and tracing.
If you're an Azure/.NET shop, Microsoft Agent Framework deserves a particularly close look: its workflows support checkpoints, resumability and explicit tool-approval requests, which map unusually well to production remediation.
Bottom line: for a new, serious self-healing DevOps system, I'd choose LangGraph for orchestration + typed remediation tools + a hard policy/approval layer. The framework matters, but the safety boundary around what the agent is allowed to do matters considerably more.
If you tell me whether you're running Kubernetes, AWS, Azure, or GCP, I can sketch a concrete architecture and a minimal implementation for the agent.
Building a self-healing DevOps system requires a framework that excels at durable orchestration, state management , and safe tool execution (like running scripts, interacting with Kubernetes APIs, or modifying code). Because self-healing systems involve multi-step reasoning loops (detect → analyze → fix → verify), standard linear chains won't cut it.
The top framework choices for building DevOps and self-healing agents depend on your exact architectural needs:
LangGraph — Best for complex, durable, and stateful orchestration. Self-healing requires cyclic graphs (e.g., trying a fix, testing it, and looping back if the test fails). LangGraph lets you define explicit state machines with human-in-the-loop checkpoints, making it ideal for high-stakes infrastructure tasks where you need deterministic control over the agent's path.
AutoGen — Best for multi-agent collaborative workflows. If your self-healing system requires specialized roles—such as a Monitoring Agent that spots an anomaly, a Log Analyzer Agent that parses stack traces, and a Remediation Agent that drafts a Kubernetes patch or a GitHub PR—'s conversational multi-agent paradigm shines here.
AutoGen
CrewAI — Best for fast prototyping. If you want to spin up a role-based team of autonomous agents quickly to test a proof-of-concept self-healing pipeline for minor CI/CD or log-checking errors without wrestling with deep graph configurations.
PydanticAI — Best for Python-heavy, type-safe agent logic. If your remediation scripts and infrastructure tools are heavily built in Python, PydanticAI provides a clean, heavily type-checked approach to structured outputs and tool calls without unnecessary framework bloat.
Semantic Kernel — Best for enterprise .NET/C# or multi-language ecosystems. If your infrastructure tooling stack lives in enterprise environments that rely heavily on C# or Azure integration rather than standard Python stacks.
To help narrow down the ideal choice, tell me:
What is your primary tech stack (Python, TypeScript, .NET)?
What specific minor issues are you targeting first (e.g., CI/CD test failures, Kubernetes pod crashes, log anomalies)?
Do you need human-in-the-loop approval before executing a fix, or should it be fully autonomous?
