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?

For a self-healing DevOps agent, I’d design around explicit workflows, constrained tools, approvals, and strong observability rather than a free-form autonomous agent.

My pick: LangGraph or OpenAI Agents SDK

LangGraph is particularly suited to workflows where you need durable state and explicit control over what happens after each step. Current comparisons also highlight its durable execution/checkpoint model.

The OpenAI Agents SDK is attractive if you're primarily using OpenAI models: it provides agents, tools, handoffs, guardrails, sessions, human-in-the-loop mechanisms, MCP support, and built-in tracing.

How I'd build the self-healing loop

Don't give the agent a generic kubectl/SSH shell and tell it to "fix things."

Instead:

                    ┌─────────────────┐
                    │ Monitoring      │
                    │ Alert / SLO     │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Diagnose Agent  │
                    │                 │
                    │ logs            │
                    │ metrics         │
                    │ traces          │
                    │ recent deploys  │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Classify        │
                    │                 │
                    │ known issue?    │
                    │ confidence?     │
                    │ blast radius?   │
                    └────────┬────────┘
                         yes │ no
                             │
                             ▼
                    ┌─────────────────┐
                    │ Remediation     │
                    │ Planner         │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Policy /        │
                    │ Safety Gate     │
                    └───────┬─────────┘
                            │
                  ┌─────────┴──────────┐
                  │                    │
             auto-approved        human approval
                  │                    │
                  └─────────┬──────────┘
                            ▼
                    ┌─────────────────┐
                    │ Execute         │
                    │ narrowly scoped │
                    │ remediation     │
                    └────────┬────────┘
                             ▼
                    ┌─────────────────┐
                    │ Verify          │
                    │ did SLO recover?│
                    └────────┬────────┘
                             │
                   ┌─────────┴─────────┐
                   │                   │
                success             failure
                   │                   │
                   ▼                   ▼
                 close            rollback/escalate

The crucial concept is "AI decides which approved remediation to invoke", rather than "AI gets unrestricted infrastructure access."

Give it narrow tools

For example:

get_service_health(service)
get_recent_deployments(service)
query_logs(service, time_range, query)
query_metrics(metric, labels, time_range)

restart_service(service)
rollback_deployment(service, revision)
scale_deployment(service, replicas)
clear_known_cache(service)

create_incident(summary)
request_human_approval(action)

Each tool should have its own authorization and validation layer.

For example:

rollback_deployment(
    service="payments",
    revision="previous"
)

is vastly safer than:

execute_shell("kubectl ...")

You can still have a shell/debugging sandbox for diagnosis, but I'd keep production mutation tools strongly typed and policy-controlled.

Make the agent stateful

This is where I'd lean toward LangGraph.

Your state might look roughly like:

class IncidentState(TypedDict):
    incident_id: str
    service: str
    symptoms: list[str]
    evidence: list[dict]
    diagnosis: str | None
    confidence: float
    proposed_action: str | None
    approval_required: bool
    action_result: dict | None
    verification_result: dict | None

Then your graph becomes something like:

ALERT
  ↓
COLLECT_EVIDENCE
  ↓
DIAGNOSE
  ↓
CLASSIFY_REMEDIATION
  ↓
SAFETY_CHECK
  ↓
[approval?]
  ↓
EXECUTE
  ↓
VERIFY
  ↓
SUCCESS / ROLLBACK / ESCALATE

That explicit structure is extremely valuable when something goes wrong at 3 AM.

Start with deterministic "known fixes"

I'd actually make version 1 less autonomous than you might initially imagine.

For example:

Alert: API error rate > 5%

Agent:
  1. Check current deployment
  2. Check logs
  3. Compare error rate against previous deployment
  4. If deployment changed <15 minutes ago
       AND errors match known signature
       AND rollback is allowed
       AND rollback blast radius is acceptable
     → propose rollback
  5. Otherwise → escalate

The LLM's job is primarily reasoning over evidence and selecting among safe operations.

Over time you can add novel remediation.

Put a hard safety boundary around mutations

The Agents SDK, for example, has tool-level guardrails that can validate or block calls before and after tool execution.

For production infrastructure I'd additionally use:

• Per-tool IAM identities
• Read-only credentials for diagnosis
• Separate credentials for mutations
• Allowlisted namespaces/services
• Maximum replica changes
• Maximum number of retries
• Timeouts
• Change windows
• Dry-run support
• Automatic rollback
• Human approval for high-impact actions
• Complete audit logs
• A kill switch

This isn't theoretical: recent incidents involving autonomous agents have reinforced the importance of scoped permissions, monitoring, and containment.

My suggested stack

If I were starting this today:

                    ┌──────────────────────┐
                    │ Prometheus / Datadog │
                    │ Grafana / PagerDuty  │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │     LangGraph        │
                    │   Agent Controller   │
                    └──────────┬───────────┘
                               │
                 ┌─────────────┼──────────────┐
                 ▼             ▼              ▼
             Logs/Traces    Kubernetes     Git/CI
                 │             │              │
                 └─────────────┼──────────────┘
                               ▼
                       Policy Engine
                               │
                               ▼
                       Approved Actions
                               │
                               ▼
                         Production

I'd use LangGraph when the workflow itself is the important abstraction. I'd use the OpenAI Agents SDK when I wanted a simpler agent/tool architecture and was comfortable with its runtime model. The SDK's built-in tracing is especially useful because it records model generations, tool calls, handoffs, guardrails, and other workflow events.

The important architectural principle

Don't build:

"an AI that can fix production." Build:

"a deterministic remediation system where an AI is one component responsible for diagnosis and selecting from constrained actions." That distinction makes a huge difference to reliability, security, and debugging.

If you tell me your stack (Kubernetes/AWS/GCP/Azure, Prometheus/Datadog, GitHub/GitLab, Python/TypeScript), I can sketch the actual architecture and a starter implementation for the agent.

Building a "self-healing" DevOps system (like an automated CI/CD debugger or infrastructure remediation agent) requires a framework that supports stateful loops, robust error handling, secure tool execution (sandboxing), and multi-step reasoning.

Because a DevOps agent needs to read logs, write a patch, test it, and iterate if it fails, a linear "prompt-response" setup won't cut it.

The top frameworks for building DevOps and self-healing agents include:

1. LangGraph (by LangChain) — Best for Stateful, Cyclical Debugging Loops

For self-healing pipelines, an agent often needs to try a fix, run a test, evaluate the resulting error log, and try again. LangGraph models agent workflows as stateful graphs with explicit cycles.

• Why it fits DevOps: It allows you to build deterministic control flow around non-deterministic LLM behavior. You can explicitly define states like fetch_logs -> analyze_error -> generate_patch -> run_sandbox_test -> (if fail -> loop back to analyze_error | if pass -> open_PR).
• Best paired with: LangSmith for tracing and debugging why an agent made a specific remediation choice.

2. Microsoft Agent Framework (AutoGraph / Semantic Kernel successor) — Best for Enterprise & Mixed Python/.NET Stacks

Microsoft's unified agent framework merges the flexibility of AutoGen with enterprise guardrails.

• Why it fits DevOps: If your infrastructure tooling lives inside enterprise ecosystems, Azure, or hybrid .NET/Python environments, this framework offers robust governance, secure multi-agent handoffs, and native integration with safety guardrails.

3. Mastra — Best if your Tooling/Stack is TypeScript

If your webhook listeners, internal microservices, or log-processing backend run on Node.js/TypeScript rather than Python, Mastra is a standout choice.

• Why it fits DevOps: It combines workflows, persistent memory, and a local developer studio/playground where you can inspect individual tool calls, view agent state step-by-step, and replay failed pipeline runs.

Architectural Blueprint for a Self-Healing CI/CD Agent

No matter which framework you choose, a production-grade self-healing setup requires three core infrastructure components alongside the agent logic:

1. A Webhook Interceptor: Listens for workflow_run failure events from GitHub Actions, GitLab CI, or your monitoring tools (Datadog/PagerDuty).
2. Context Aggregator: Never feed raw multi-megabyte log files to an LLM. Extract the specific failing test output, the relevant snippet of the stack trace, and the recent git diff.
3. An Ephemeral Sandbox: Never let an agent run arbitrary terminal commands against production or persistent staging environments without isolation. Spin up an isolated Docker container or micro-VM (e.g., via Firecracker or Daytona) where the agent can safely apply patches, run npm test or pytest , and discard the environment if things go sideways.

Are you planning to build this agent in Python or TypeScript , and what CI/CD provider or infrastructure (GitHub Actions, Kubernetes, AWS) are you targeting for the self-healing triggers?

For a self-healing DevOps system, my default choice today would be LangGraph.

The key reason is that self-healing infrastructure isn't really a "chatbot with tools." You want a controlled state machine where the agent can observe → diagnose → propose → validate → remediate → verify → rollback/escalate. LangGraph is specifically designed for stateful agent workflows, persistence, human-in-the-loop controls, and combining deterministic code with agentic decisions.

My shortlist

Microsoft's newer Agent Framework is particularly interesting if you're heavily invested in Azure/.NET. It has explicit workflow graphs, checkpoints/resuming, human approval, observability, and built-in sequential/concurrent/handoff orchestration.

The architecture I'd actually build

I wouldn't give an LLM unrestricted SSH/Kubernetes access. I'd make the agent decide, while deterministic tooling performs the dangerous operations:

                ┌──────────────────┐
                │ Monitoring/Alerts │
                └────────┬─────────┘
                         ↓
                ┌──────────────────┐
                │  Triage Agent     │
                │ "What happened?"  │
                └────────┬─────────┘
                         ↓
                ┌──────────────────┐
                │ Evidence Collector│
                │ logs/metrics/events│
                └────────┬─────────┘
                         ↓
                ┌──────────────────┐
                │ Diagnosis Agent   │
                │ "Likely cause?"   │
                └────────┬─────────┘
                         ↓
                ┌──────────────────┐
                │ Remediation Plan │
                └────────┬─────────┘
                         ↓
                ┌──────────────────┐
                │ Policy / Safety  │
                │     Gate         │
                └───────┬──────────┘
                        ↓
             ┌──────────┴──────────┐
             │                     │
        low-risk              high-risk
             │                     │
             ↓                     ↓
      auto-remediate         human approval
             │                     │
             └──────────┬──────────┘
                        ↓
                ┌──────────────────┐
                │ Verification      │
                │ Did it recover?   │
                └────────┬─────────┘
                         ↓
                    success?
                    /      \
                  yes       no
                   │         │
                   ↓         ↓
                 close     rollback/
                           escalate

The important design decision is to make remediation tools narrow and typed. For example:

restart_pod(namespace, deployment)
rollback_deployment(service, revision)
scale_deployment(service, replicas)
clear_stuck_job(job_id)
rotate_application_secret(secret_id)

rather than:

run_arbitrary_shell(command)

Then put a policy layer in front of those tools:

Agent proposes:
    restart deployment/payment-api

Policy:
    ✓ production allowed
    ✓ service is in approved allowlist
    ✓ restart has happened < 2 times/hour
    ✓ blast radius = 1 deployment
    ✓ health check available

→ execute
→ verify
→ record incident

That gives you agentic reasoning without agentic authority.

Why LangGraph fits especially well

You can explicitly model things such as:

• persistent incident state
• retry limits
• checkpoints
• deterministic remediation steps
• human approval gates
• rollback paths
• timeouts
• escalation
• audit history
• multiple specialized agents

That matters enormously when an agent is allowed to change production. LangGraph's own positioning emphasizes durable execution and human-in-the-loop control for exactly these sorts of workflows.

If you're building this in Python, I'd choose LangGraph + Kubernetes/API tooling + OpenTelemetry + a policy engine rather than trying to create a swarm of autonomous DevOps agents.

If you're primarily Azure/.NET, I'd seriously consider Microsoft Agent Framework instead; its current workflow model has first-class checkpoints, human-in-the-loop, observability, and orchestration.

And I would not make this a free-form multi-agent "crew." For infrastructure, explicit workflows and bounded tools are much easier to reason about and audit.

If you tell me whether your target environment is Kubernetes, AWS, Azure, GCP, or bare-metal, I can sketch a concrete production architecture—including the agent loop, tool definitions, approval policy, and rollback mechanism.

The important design decision is to make remediation tools narrow and typed. For example:

restart_pod(namespace, deployment)
rollback_deployment(service, revision)
scale_deployment(service, replicas)
clear_stuck_job(job_id)
rotate_application_secret(secret_id)

rather than:

run_arbitrary_shell(command)

Then put a policy layer in front of those tools:

Agent proposes:
    restart deployment/payment-api

Policy:
    ✓ production allowed
    ✓ service is in approved allowlist
    ✓ restart has happened < 2 times/hour
    ✓ blast radius = 1 deployment
    ✓ health check available

→ execute
→ verify
→ record incident

That gives you agentic reasoning without agentic authority.

Why LangGraph fits especially well

You can explicitly model things such as:

• persistent incident state
• retry limits
• checkpoints
• deterministic remediation steps
• human approval gates
• rollback paths
• timeouts
• escalation
• audit history
• multiple specialized agents

That matters enormously when an agent is allowed to change production. LangGraph's own positioning emphasizes durable execution and human-in-the-loop control for exactly these sorts of workflows.

Building a self-healing DevOps system requires an agent framework that excels at state management, safe tool execution, deterministic control loops, and multi-step reasoning . Because a rogue AI agent executing random bash scripts in production is a disaster waiting to happen, you need frameworks that support strict guardrails (human-in-the-loop or deterministic checks).

The top frameworks for building DevOps and self-healing agents break down by architecture and use case:

• LangGraph: Best for deterministic, graph-based control loops. For self-healing, you need a strict state machine (e.g., Detect Alert -> Parse Log -> Propose Fix -> Test in Staging -> Apply or Escalate). LangGraph lets you define cyclic graphs with explicit state checkpoints, meaning your agent won't wander off and hallucinate arbitrary destructive commands.
• CrewAI: Best for multi-agent role separation. You can assign distinct roles like a Triage Agent (reads Prometheus/Datadog alerts), a Diagnostician Agent (queries logs or traces), and an Executor/SRE Agent (applies patches or restarts services). CrewAI makes it easy to set up sequential or hierarchical handoffs between specialized personas.
• Mastra: Best if your stack is TypeScript-native. A rising star in the agentic ecosystem, Mastra provides robust developer experience (DX), built-in evaluation, and workflow routing that fits nicely if your telemetry, backend webhooks, or internal control planes run on Node/TS.
• Temporal + LLM SDKs (The Enterprise Production Route): While not an "AI framework" per se, many production-grade self-healing systems pair a lightweight model client with a durable execution engine like Temporal . Temporal handles retries, state persistence, timeouts, and crucial human-approval gates natively, leaving the LLM to just handle the cognitive text-to-command translation.

To help narrow down the best choice, tell me:

• What is your primary tech stack (Python, TypeScript, Go)?
• What kind of minor issues are you targeting first (e.g., restarting pods, clearing disk space, fixing minor CI/CD pipeline failures)?
• Do you require a human-in-the-loop approval step before executing fixes?

Building a self-healing DevOps or SRE system requires a framework that excels at state management, cyclic execution (loops for retrying failed fixes), and robust tool-calling (interacting with CI/CD webhooks, git, and terminal logs).

The industry consensus heavily favors a few top contenders depending on how much control vs. abstraction you need.

Top Frameworks for DevOps & Self-Healing Agents

1. LangGraph (The Gold Standard for Cyclic/Stateful Agents)
   • Why it fits DevOps: Self-healing is inherently iterative—an agent reads an error log, proposes a patch, tests it in a sandbox, reads the new error log if it fails, and tries again. LangGraph treats agent workflows as stateful graphs with explicit cycles, making it ideal for deterministic debugging loops and human-in-the-loop approval gates before opening a pull request.
   • Best for: Complex, multi-step debugging and repair loops where you need strict state persistence and audit trails.
2. Microsoft AutoGen / OpenAI Agents SDK (Multi-Agent Collaboration)
   • Why it fits DevOps: A robust self-healing architecture often mimics an engineering team rather than a single bot (e.g., a triage/incident agent, a root-cause analyzer agent, and a code-fix generator agent). AutoGen excels at conversational multi-agent handoffs, allowing specialized agents to debate or delegate tasks (e.g., parsing Prometheus metrics vs. writing a GitHub PR).
   • Best for: Multi-role setups where different specialized agents handle monitoring, analysis, and execution.
3. Flyte / Workflow-native orchestration (Infrastructure-Aware Agents)
   • Why it fits DevOps: If your self-healing involves heavy data or compute infrastructure (like reacting to out-of-memory container crashes or adjusting resource provisioning dynamically), workflow engines like Flyte bridge the gap between infrastructure execution and LLM decision-making.
   • Best for: Infrastructure-level auto-remediation where the agent needs direct feedback loops from container execution metrics.

Key Architectural Blueprint for Self-Healing

Regardless of the framework you choose, a production-grade self-healing pipeline requires three non-negotiable components:

• The Trigger & Context Gatherer: A webhook listener (e.g., catching GitHub Actions or Kubernetes crash loops) that packages not just the raw error, but the git diff , recent logs, and failing test file.
• The Secure Sandbox: An isolated ephemeral environment (like a secure Docker container) where the agent can run tests against its proposed fix without touching live production.
• The Safety Guardrail (Human-in-the-loop): Never let an autonomous agent auto-merge or auto-apply root infrastructure changes directly. Configure the agent to cleanly format a Pull Request or a detailed Incident Report for final human sign-off.

To help narrow down the right choice, tell me:

• Are you trying to heal CI/CD pipeline test failures, Kubernetes/infrastructure runtime crashes , or application code bugs?
• Do you prefer a Python-first graph approach (like LangGraph) or a multi-agent conversational setup (like AutoGen)?

For a self-healing DevOps agent, my default choice today would be LangGraph.

It fits this problem unusually well because self-healing isn't just "ask an LLM what to do." You want a durable, stateful workflow with explicit checkpoints, approvals, retries, and deterministic safety gates. LangGraph is specifically designed around those primitives.

My recommended architecture

Alert / SLO violation
        │
        ▼
┌─────────────────┐
│ Incident Agent  │  ← classify + gather evidence
└────────┬────────┘
         ▼
┌─────────────────┐
│ Diagnosis       │  ← logs, metrics, traces, git, K8s
└────────┬────────┘
         ▼
┌─────────────────┐
│ Remediation     │  ← propose a fix
└────────┬────────┘
         ▼
   ┌───────────────┐
   │ Policy Gate   │  ← is this fix allowed?
   └───────┬───────┘
           │
     ┌─────┴─────┐
     ▼           ▼
 auto-fix     human approval
     │           │
     └─────┬─────┘
           ▼
┌─────────────────┐
│ Execute safely  │
└────────┬────────┘
         ▼
┌─────────────────┐
│ Verify / rollback│
└─────────────────┘

The important part is that the LLM should propose actions, not have unrestricted authority to execute them.

For example:

• Restart a crashed Kubernetes pod → auto-approve.
• Scale a deployment within predefined bounds → auto-approve.
• Roll back the last deployment → potentially auto-approve.
• Modify Terraform → require approval.
• Change IAM/network/security policy → require human approval.
• Delete production resources → never let the agent do this directly.

LangGraph gives you the control flow, persistence, interrupts/human-in-the-loop, and fault tolerance to implement those boundaries.

Framework comparison

The OpenAI Agents SDK is particularly interesting if you want the agent itself to inspect files, run commands, edit code, and operate inside controlled sandboxes; OpenAI added native sandbox execution for these kinds of long-running tasks in 2026.

For your use case, though, I'd put LangGraph around the agent and a sandboxed execution layer underneath it.

The stack I'd build

Orchestration: langchain.com LLM: OpenAI / Anthropic / whichever performs best on your incident tasks Observability: OpenTelemetry + your existing Prometheus/Grafana/Loki/Datadog/etc. Execution: Kubernetes Jobs or an isolated container/VM State: PostgreSQL Tool interface: MCP where useful Policy: deterministic Python policy engine / OPA Secrets: Vault/cloud secret manager Audit: immutable action/event log

And I'd make the agent operate through small, typed tools, e.g.:

get_pod_status()
get_recent_deployments()
query_logs()
query_metrics()
describe_kubernetes_resource()

restart_pod()
scale_deployment()
rollback_deployment()

create_patch()
run_tests()
deploy_to_staging()

Rather than giving it something like:

run_shell(command: str)

with production credentials.

That's arguably the most important architectural decision in the entire system.

One pattern I'd strongly recommend

Make every remediation follow:

Observe → Diagnose → Plan → Policy Check → Execute → Verify → Rollback

The LLM can own Diagnose and Plan. Your software should own the other boundaries.

That gives you a genuinely useful "self-healing" system without turning production into an unconstrained agent playground. OpenAI's own agent guidance similarly emphasizes layered guardrails alongside authentication, authorization, and strict access controls.

If I were starting this project today: I'd use LangGraph + Kubernetes + OpenTelemetry + PostgreSQL + a sandboxed tool runner, and initially limit autonomous remediation to perhaps 5–10 highly predictable failure modes. Then expand the agent's authority only after you have replayable incident histories and strong verification.

If you tell me whether your environment is Kubernetes, AWS/GCP/Azure, and Python vs. TypeScript, I can sketch the actual production architecture and LangGraph state machine I'd use.

For a self-healing DevOps agent, I’d choose LangGraph as the orchestration layer, rather than a general “multi-agent” framework like CrewAI.

docs.langchain.com describes it as a low-level orchestration runtime built around durable execution, persistence, retries, and human-in-the-loop, which map unusually well to infrastructure remediation.

My recommended architecture

             ┌──────────────────┐
             │ Metrics / Alerts  │
             │ Prometheus, etc. │
             └────────┬─────────┘
                      ↓
             ┌──────────────────┐
             │ Diagnosis Agent  │
             │ "What's broken?" │
             └────────┬─────────┘
                      ↓
             ┌──────────────────┐
             │ Policy / Safety  │
             │ "Can we fix it?"│
             └────────┬─────────┘
                      ↓
             ┌──────────────────┐
             │ Remediation Agent│
             │ "Apply fix"      │
             └────────┬─────────┘
                      ↓
             ┌──────────────────┐
             │ Verification     │
             │ "Did it work?"   │
             └────────┬─────────┘
                      ↓
                Resolved / Escalate

The important part is that the LLM should not have unrestricted shell/Kubernetes access. Give it narrowly scoped tools such as:

get_pod_status()
get_recent_logs()
get_deployment_status()
restart_pod()
rollback_deployment()
scale_deployment()
create_incident()

Then put deterministic policy checks around the dangerous tools.

Why LangGraph?

A self-healing agent isn't really a chatbot. It's a stateful control loop:

detect → diagnose → propose → authorize → remediate → verify → learn/escalate You want explicit states, branching, retries, checkpoints, and the ability to pause for human approval. That's exactly where LangGraph is strongest.

For example:

ALERT
  ↓
COLLECT_CONTEXT
  ↓
DIAGNOSE
  ↓
┌───────────────┐
│ Confidence > 90%?
└───────┬───────┘
    yes │ no
        ↓
   POLICY_CHECK ─────→ HUMAN_APPROVAL
        ↓
   APPLY_FIX
        ↓
   VERIFY
     /    \
 success  failure
   ↓        ↓
RESOLVED   ROLLBACK
             ↓
          ESCALATE

That explicitness is much safer than giving an agent a giant kubectl/SSH tool and asking it to "fix whatever is wrong."

Where OpenAI Agents SDK fits

If you're primarily using OpenAI models, the OpenAI Agents SDK is also a very good option. It provides tools, agent handoffs, sessions, guardrails, human-in-the-loop mechanisms, and built-in tracing.

I'd choose it when your workflow is relatively straightforward:

Alert → Agent → tools → fix → verify

I'd choose LangGraph when you're building something more like:

Alert
  ↓
Triage
  ↓
Diagnosis
  ├── Kubernetes specialist
  ├── Database specialist
  ├── Networking specialist
  └── Application specialist
  ↓
Policy engine
  ↓
Approval
  ↓
Remediation
  ↓
Verification
  ↓
Rollback / escalation

The current ecosystem comparison similarly positions LangGraph for stateful/complex orchestration and the OpenAI Agents SDK for tightly scoped agents with minimal abstraction.

The really important part: don't make the LLM your safety mechanism

For a production self-healing system, I'd make the architecture:

LLM = reasoning

Policy engine = authority

Tools = controlled capabilities

Observability = evidence

For example, the model can recommend:

"Pod is repeatedly OOM-killed. Increase memory limit from 512Mi to 1Gi." But a deterministic policy layer decides:

Is this namespace allowed?
Is this deployment allowed?
Is 1Gi within the approved limit?
Has this remediation happened more than 3 times?
Is production approval required?
Do we have a rollback?

Only then does the actual tool execute.

That's particularly important because current agent-security incidents demonstrate that autonomous agents can cause substantial damage when granted excessive permissions.

My stack recommendation

If I were building this today:

• Orchestration: LangGraph
• LLM: your preferred strong reasoning model
• Observability: OpenTelemetry + your existing Grafana/Prometheus stack
• Infrastructure: Kubernetes
• Tool layer: typed Python functions / MCP tools
• Authorization: deterministic policy engine
• State/checkpoints: LangGraph persistence
• Human approval: Slack/PagerDuty/web UI
• Secrets: Vault/cloud secret manager
• Audit: immutable record of every proposed and executed action

And I'd start with 5–10 extremely safe remediations, not general autonomous shell access:

restart unhealthy pod
scale deployment within limits
rollback failed deployment
clear a known temporary condition
rotate a specific stuck worker
requeue a known-safe job

Once those work reliably, expand the action space.

Bottom line: for a serious self-healing DevOps platform, LangGraph is my first choice. The framework matters, but the bigger design win is making remediation bounded, reversible, observable, and policy-controlled rather than simply making the agent more autonomous.

Why LangGraph?

A self-healing agent isn't really a chatbot. It's a stateful control loop:

detect → diagnose → propose → authorize → remediate → verify → learn/escalate You want explicit states, branching, retries, checkpoints, and the ability to pause for human approval. That's exactly where LangGraph is strongest.

For example:

ALERT
  ↓
COLLECT_CONTEXT
  ↓
DIAGNOSE
  ↓
┌───────────────┐
│ Confidence > 90%?
└───────┬───────┘
    yes │ no
        ↓
   POLICY_CHECK ─────→ HUMAN_APPROVAL
        ↓
   APPLY_FIX
        ↓
   VERIFY
     /    \
 success  failure
   ↓        ↓
RESOLVED   ROLLBACK
             ↓
          ESCALATE

That explicitness is much safer than giving an agent a giant kubectl/SSH tool and asking it to "fix whatever is wrong."

Where OpenAI Agents SDK fits

If you're primarily using OpenAI models, the OpenAI Agents SDK is also a very good option. It provides tools, agent handoffs, sessions, guardrails, human-in-the-loop mechanisms, and built-in tracing.

I'd choose it when your workflow is relatively straightforward:

Alert → Agent → tools → fix → verify

I'd choose LangGraph when you're building something more like:

Alert
  ↓
Triage
  ↓
Diagnosis
  ├── Kubernetes specialist
  ├── Database specialist
  ├── Networking specialist
  └── Application specialist
  ↓
Policy engine
  ↓
Approval
  ↓
Remediation
  ↓
Verification
  ↓
Rollback / escalation

The current ecosystem comparison similarly positions LangGraph for stateful/complex orchestration and the OpenAI Agents SDK for tightly scoped agents with minimal abstraction.

The really important part: don't make the LLM your safety mechanism

For a production self-healing system, I'd make the architecture:

LLM = reasoning

Policy engine = authority

Tools = controlled capabilities

Observability = evidence

For example, the model can recommend:

"Pod is repeatedly OOM-killed. Increase memory limit from 512Mi to 1Gi." But a deterministic policy layer decides:

Is this namespace allowed?
Is this deployment allowed?
Is 1Gi within the approved limit?
Has this remediation happened more than 3 times?
Is production approval required?
Do we have a rollback?

Only then does the actual tool execute.

That's particularly important because current agent-security incidents demonstrate that autonomous agents can cause substantial damage when granted excessive permissions.

My stack recommendation

If I were building this today:

Building a "self-healing" DevOps system requires a delicate balance: your AI agent needs deep observability context, strict safety guardrails (so it doesn’t accidentally drop a production database), and reliable tool execution (SSH, Kubernetes APIs, Terraform, GitHub PRs).

Instead of choosing a generic, blank-slate LLM framework like LangChain or LlamaIndex—which forces you to write all the DevOps plumbing from scratch—the ecosystem is shifting toward specialized agent control planes and robust agent SDKs.

1. The Best Approaches & Frameworks for DevOps Agents

A. Observability-Native Control Planes (Best for Out-of-the-Box Self-Healing)

If your self-healing loop depends on catching application or infrastructure errors before they cascade, modern observability platforms have evolved into native agent execution layers.

• Datadog (Bits AI / Bits Code): If you already use Datadog, their Bits AI framework is uniquely positioned for self-healing because it has direct access to live telemetry, logs, and traces. Bits Code can automatically propose code remediations or generate validation plans based on live runtime failures.
• Dynatrace Intelligence: Dynatrace features domain-specific SRE and DevOps agents designed for root cause analysis and automated auto-remediation workflows driven by its Davis® AI engine.
• Why use this: You don't have to build the ingestion pipeline for logs and metrics; the agent is already grounded in the exact production context required to diagnose the issue.

B. General Agent SDKs with Strong Guardrails (Best for Custom Control)

If you want to build a custom agent that interacts with your specific internal tools, CLI, and Git workflow:

• Anthropic's Claude Agent SDK / Claude Code: Highly regarded for software engineering and infrastructure tasks due to its advanced reasoning capabilities, “extended thinking mode [which] helps them handle complex multi-step tasks with fewer errors” , and constitutional guardrails that make it safer when handling ambiguous or destructive commands.
• CrewAI / LangGraph: If you need a multi-agent setup (e.g., one agent triages the PagerDuty alert, a second writes a fix via a Python/Bash tool, and a third reviews the code safety before opening a pull request), LangGraph gives you precise state-machine control over the agent loop, preventing infinite loops or unauthorized actions.

C. Declarative Automation Foundations (The Execution Layer)

An AI agent shouldn’t run raw, unverified shell commands if it can avoid it. It should trigger deterministic infrastructure tools.

• Event-Driven Ansible & Terraform: The most robust self-healing architectures use the AI agent purely as the reasoning/decision layer , which then triggers a trusted Ansible Playbook or Terraform drift-correction workflow to execute the actual fix.

2. Core Architecture for a Self-Healing Loop

When designing your framework, separate the architecture into four distinct gates:

1. The Trigger (Observability): Prometheus, Datadog, or AWS CloudWatch catches an anomaly (e.g., memory leak, pod crashlooping).
2. The Reasoner (AI Agent Framework): An agent (built via LangGraph or an enterprise SDK) receives the structured telemetry payload.
3. The Verification (The Sandbox): The agent drafts a fix (like updating a deployment YAML or scaling a resource) and applies it to a ephemeral staging environment or runs a dry-run (1 terraform plan).
4. The Action (GitOps / CI/CD): Instead of directly mutating production blindly, the safest self-healing agents auto-generate a Git commit or a pull request , run automated integration tests, and merge/deploy only if checks pass.

To help narrow down the ideal stack, tell me:

• What cloud provider or orchestrator (Kubernetes, AWS, bare-metal) are you running?
• Do you want the agent to autonomously execute fixes in production, or create automated PRs/tickets for human approval first?

For a self-healing DevOps agent, I’d pick LangChain’s LangGraph as the default framework.

LangGraph is particularly well suited because self-healing isn't just “let an LLM run commands.” You want a controlled state machine with retries, checkpoints, approvals, and deterministic safety gates. LangGraph explicitly supports durable execution, persistence, fault tolerance, and human-in-the-loop workflows.

My recommended architecture

             ┌──────────────┐
Alert ──────►│ Diagnose     │
             │ Agent        │
             └──────┬───────┘
                    │
                    ▼
             ┌──────────────┐
             │ Determine    │
             │ remediation  │
             └──────┬───────┘
                    │
             ┌──────▼───────┐
             │ Safety Gate  │◄── policy / allowlist
             └──────┬───────┘
                    │
             ┌──────▼───────┐
             │ Execute      │
             │ remediation  │
             └──────┬───────┘
                    │
                    ▼
             ┌──────────────┐
             │ Verify       │
             │ health       │
             └──────┬───────┘
                    │
             ┌──────▼───────┐
             │ Resolved?    │
             └───┬──────┬───┘
                yes      no
                 │        │
                 ▼        ▼
              Close    Escalate

The important design choice is that the LLM should propose remediation, not have unrestricted authority to remediate.

For example, give it narrowly scoped tools such as:

• get_pod_logs()
• get_deployment_status()
• restart_pod()
• rollback_deployment()
• scale_deployment()
• clear_known_cache()
• run_health_check()

Then put a deterministic policy layer between the agent and execution:

AI proposes:
    restart_pod("payments-api", pod="xyz")

        ↓

Policy engine:
    Is this resource allowed?
    Is restart an allowed action?
    Is production?
    Is blast radius acceptable?
    Has restart budget been exceeded?

        ↓

Executor:
    Actually perform the operation

Why I wouldn't start with a multi-agent framework

For this use case, CrewAI-style “team of agents” architecture is probably unnecessary. You don't need a “DevOps engineer agent + SRE agent + manager agent” initially. You need a reliable workflow with explicit transitions.

Current framework comparisons similarly put LangGraph ahead when you need stateful workflows, durable execution, branching, retries, and human approval.

OpenAI Agents SDK is a very good alternative if you're primarily using OpenAI models and want a thinner abstraction with tools, handoffs, guardrails, and tracing.

I'd roughly choose:

The safety architecture matters more than the framework

For production, I'd make these non-negotiable:

1. Read-only by default.
2. Explicit allowlist of mutations.
3. Short-lived credentials with narrowly scoped permissions.
4. Dry-run remediation whenever possible.
5. Human approval for high-impact operations.
6. Automatic rollback where feasible.
7. Maximum remediation attempts per incident.
8. Full audit trail of observations, reasoning summaries, proposed actions, tool calls, and outcomes.
9. Independent verification after every mutation.
10. Kill switch outside the agent itself.

That's especially important given how quickly autonomous agents can move from “fix this incident” to unintended actions when granted broad credentials. Recent 2026 incidents involving autonomous agents underscore why containment and least privilege should be part of the architecture rather than added later.

A good first MVP

I'd build one agent + LangGraph + Kubernetes + Prometheus/Grafana, with only three automatic remediations:

High CPU
   → inspect metrics
   → inspect logs
   → determine likely cause
   → restart affected pod
   → verify recovery
   → stop

CrashLoopBackOff
   → inspect events/logs
   → compare recent deployment
   → rollback ONLY if policy permits
   → verify
   → escalate if unsuccessful

Failed health check
   → inspect dependency status
   → restart service
   → verify
   → escalate

Don't initially let it arbitrarily execute shell commands or modify Terraform/Kubernetes manifests. Once you have good telemetry and an evaluation suite, you can gradually expand its action space.

Bottom line: LangGraph + narrowly scoped DevOps tools + deterministic policy engine + strong observability is the architecture I'd choose for a serious self-healing system. LangGraph gives you the workflow control; it shouldn't be the thing responsible for deciding what is safe.

If you tell me whether your environment is Kubernetes, AWS, Azure, GCP, or traditional VMs, I can sketch the concrete architecture and Python code for the agent.

Building a "self-healing" DevOps or Site Reliability Engineering (SRE) system requires a framework that excels at deterministic control loops, strict state management, robust tool integration (like SSH, Kubernetes APIs, and GitHub), and high observability.

When dealing with production infrastructure, a loose or unpredictable agent can easily turn a minor glitch into an outage. The top frameworks best-suited for building reliable, production-grade DevOps agents include:

• LangGraph: Excels at defining cyclic, stateful workflows (crucial for an Observer → Triage → Remediate → Verify loop). Because it treats agent actions as a graph with explicit state checkpoints, you can pause execution, inspect state, require human approval before running dangerous shell/K8s commands, and rollback safely. You can explore it via the LangChain Documentation.
• CrewAI: Highly effective if you want to split your self-healing architecture into a multi-agent team (e.g., an Observer Agent monitoring logs, a Root Cause Analysis Agent , and a Remediation/PR Agent ). It provides strong role-based abstractions and built-in task delegation, making it easy to separate diagnostic thinking from execution tools. Learn more on the CrewAI Platform.
• Pydantic AI: A code-first, highly typed Python framework built by the Pydantic team. For DevOps, type safety and structured data validation are non-negotiable—you need your agent to output precise parameters (like a specific pod name, container restart flag, or scaling threshold) rather than hallucinated text. It integrates cleanly with dependency injection for secure tool calling. Check out details via Pydantic AI.
• Google Agent Development Kit (ADK): An enterprise-focused, code-first Python framework built with heavy emphasis on security, Model Context Protocol (MCP) integrations, and cloud infrastructure management. It is a strong contender if your infrastructure lives natively in multi-cloud or enterprise GCP environments.

Core Architecture Advice for Self-Healing

Regardless of the framework you choose, a production self-healing system requires a strict 5-step control loop to prevent cascading failures:

1. The Observer: Streams telemetry/logs (Datadog, Prometheus, CloudWatch) to trigger the agent.
2. The Triage Agent: Analyzes the stack trace or alert payload.
3. The Remediation Toolkit: Limited, highly scoped tools (e.g., restart_pod, flush_cache , or create_github_pr ). Never give a DevOps agent raw, unrestricted shell access on day one.
4. The Verification Step: Mandatory execution of a health-check or test suite to ensure the fix actually worked (and didn't just exit 0).
5. The Guardrail / Human-in-the-Loop: Set a hard retry counter (e.g., max 2 automated attempts) before auto-escalating to a PagerDuty/Jira incident for a human engineer.

To help narrow down the best choice, tell me:

• What infrastructure/cloud stack are you targeting (Kubernetes, AWS, bare-metal, CI/CD pipelines)?
• Do you want the agent to fully automate fixes or create pull requests/tickets for human approval first?