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?

The best approach for a self-healing DevOps system is using LangChain / LangGraph for stateful, cyclic remediation workflows, or Microsoft AutoGen for multi-agent collaboration (such as a monitoring agent talking to a remediation agent).

Building a self-healing loop requires connecting observability inputs (like Prometheus or Datadog) to a reasoning engine that can safely execute infrastructure changes via Terraform or Kubernetes commands.

Top Frameworks for DevOps Agents

• LangGraph : Best for deterministic, cyclic workflows where an agent needs to test a fix (e.g., run helm lint or a dry-run), check for errors, and iterate until validation passes.
• Microsoft AutoGen : Best for multi-agent setups where distinct roles are required—such as a Log Analyzer Agent passing data to a Code Fixer Agent.
• CrewAI : Great for sequential task management and role-based agent assignment in automated pipeline error handling.
• Custom Python + MCP (Model Context Protocol) : Increasingly favored for production DevOps to give LLMs secure, standardized, and read/write access to local CI logs, git repositories, and terminal commands without heavy framework abstraction.

Core Architectural Layers

If you'd like to proceed, tell me:

• What specific DevOps tool or environment are you targeting first (e.g., Kubernetes, GitHub Actions CI, AWS infrastructure)?
• Do you want the agent to fully automate fixes or open a pull request for human review first?

For a self-healing DevOps agent, I’d choose LangGraph as the orchestration framework.

The key reason is that self-healing is less about having multiple agents chatting with each other and more about controlled, stateful execution with retries, verification, approvals, and the ability to stop safely. Current 2026 comparisons consistently put LangGraph in the strongest position for complex production workflows.

Recommended architecture

                    ┌─────────────────┐
                    │ Monitoring /    │
                    │ Alert / Event   │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Triage Agent    │
                    │ classify issue  │
                    └────────┬────────┘
                             │
                 ┌───────────┴───────────┐
                 ▼                       ▼
          Known safe issue         Unknown issue
                 │                       │
                 ▼                       ▼
          Remediation Agent       Human approval
                 │                       │
                 ▼                       │
          Execute fix ◄─────────────────┘
                 │
                 ▼
          Verification Agent
                 │
          ┌──────┴──────┐
          ▼             ▼
       Healthy       Still broken
          │             │
          ▼             ▼
        Done       Rollback / escalate

Why LangGraph fits

It gives you an explicit workflow/state model, so you can make things like:

• Retries — retry a failed remediation a controlled number of times.
• Checkpoints — preserve state if the agent or infrastructure fails.
• Human-in-the-loop — require approval before dangerous actions.
• Conditional branches — different remediation paths for different failures.
• Verification steps — don't trust the agent's claim that the fix worked.
• Rollback paths — undo a remediation when health checks fail.
• Auditable state — know exactly what the agent observed and did.

Those characteristics are particularly important for production self-healing.

I would not start with a multi-agent "crew"

You could use CrewAI, and it's excellent for quickly prototyping role-based agent teams. But for your use case I'd make the workflow deterministic and the individual remediation steps agentic, rather than letting several autonomous agents freely collaborate.

For example:

Alert
  ↓
[LLM] Diagnose
  ↓
[Policy] Is remediation allowed?
  ↓
[Tool] Restart service
  ↓
[Tool] Check health
  ↓
[LLM] Interpret result
  ↓
[Policy] Healthy?
  ├── yes → close incident
  └── no  → rollback/escalate

That's a much safer architecture than:

Agent A ↔ Agent B ↔ Agent C
       ↕
   "figure it out"

CrewAI is still worth considering if your system eventually needs distinct specialists—for example, Kubernetes, networking, database, and security agents.

The really important part: constrain the agent

I would not give the LLM unrestricted shell/Kubernetes/cloud credentials.

Instead expose narrowly scoped tools such as:

get_pod_status()
get_recent_logs()
get_deployment_status()
restart_deployment(deployment)
scale_deployment(deployment, replicas)
rollback_deployment(deployment)
run_health_check(service)
create_incident(summary)

Then put a policy layer between the agent and the actual infrastructure:

Agent
  ↓
Tool request
  ↓
Policy engine
  ↓
Allowed?
  ├── no → reject
  └── yes
       ↓
    Executor
       ↓
   Kubernetes/AWS/etc.

For example, you might allow:

Restart api-prod if crash-looping for >5 minutes. But require human approval for:

Delete production database. That distinction should exist outside the prompt.

My 2026 stack recommendation

LangGraph's broader ecosystem also includes observability/evaluation tooling, which is useful once you're trying to understand why an autonomous remediation succeeded or failed.

One important 2026 note

I wouldn't start a new system on AutoGen today. Microsoft has moved it into maintenance mode and points new development toward the Microsoft Agent Framework.

If you're already heavily invested in Azure/.NET, I'd seriously evaluate Microsoft Agent Framework instead.

Bottom line: for a self-healing DevOps platform, I'd build LangGraph + narrowly scoped infrastructure tools + deterministic policy/approval gates + mandatory verification/rollback. The LLM should be the diagnostician and decision-maker, not the unrestricted administrator.

If you tell me whether your infrastructure is Kubernetes, AWS, Azure, GCP, or a mix, I can sketch the actual architecture and a minimal first version.

Building a self-healing DevOps system requires an agent framework that excels at tool calling, deterministic state management , and strict safety guardrails (because an autonomous agent with the power to kubectl apply or modify production infrastructure can cause massive damage if it hallucinates).

Rather than picking a generic chat-bot framework, the best approach depends on whether you want to build custom control loops or orchestrate multi-step remediation workflows.

Top Frameworks for Building DevOps Agents

1. LangGraph (by LangChain) — Best for Complex, Stateful Remediation Loops

• Why it fits DevOps: Self-healing isn't a single prompt—it's a loop: Detect error → Pull logs → Formulate hypothesis → Test fix → Verify metric . LangGraph lets you model agents as explicit state machines with cyclic graphs.
• Key advantage: You can build human-in-the-loop checkpoints (e.g., “Agent wants to restart pod X, pause execution and wait for Slack/PagerDuty approval” ) before committing changes. It supports deterministic routing so the agent doesn’t wander off into an infinite debugging loop.

2. LlamaIndex (Workflow APIs / Agentic RAG) — Best for Context-Heavy Diagnosis

• Why it fits DevOps: To fix an issue, an agent needs context: your runbooks, past incident reports, architecture diagrams, and current codebase/Terraform manifests. LlamaIndex is unmatched at ingesting and retrieving this tribal knowledge via advanced RAG.
• Key advantage: Its event-driven workflow system allows you to build asynchronous handlers for alerts (e.g., a Datadog or Prometheus webhook triggers an ingestion flow, retrieves the exact troubleshooting runbook, and passes structured context to the LLM).

3. Temporal + Custom Python/Go LLM SDKs — Best for Production-Grade Reliability

• Why it fits DevOps: If you are building mission-critical self-healing, traditional AI frameworks can feel fragile. Pairing an orchestration engine like Temporal with direct LLM API calls gives you bulletproof retries, state persistence, and timeouts.
• Key advantage: If your remediation script fails halfway through executing a shell command or API call, Temporal handles the compensation logic, state tracking, and failure recovery natively.

4. AutoGen (by Microsoft) — Best for Multi-Agent Collaboration

• Why it fits DevOps: You can simulate an entire SRE team. For instance, assign distinct roles: an Observability Agent that reads logs/metrics, a Security/Compliance Agent that vets the proposed fix, and an Execution Agent that applies the patch.
• Key advantage: Multi-agent conversation patterns allow agents to "peer-review" each other's patches before executing them against a staging or production environment.

Essential Architecture for Self-Healing

No matter which framework you choose, a production-ready self-healing loop requires a strict multi-layered setup:

1. The Trigger Layer: Observability platforms (Datadog or Dynatrace ) or Kubernetes native controllers catch anomalies and fire webhooks.
2. The Sandboxed Execution Layer: Never let the agent run arbitrary code directly on a live host. Give it constrained tools—like executing pre-approved shell scripts, hitting specific REST APIs, or interacting with a Model Context Protocol (MCP) server tied to your cluster.
3. The Guardrail & Verification Layer: After the agent applies a fix, the system must independently verify that the error rate drops or health checks pass for a cool-down period (e.g., 5 minutes). If metrics degrade further, it must automatically trigger a rollback.

To help narrow down the best path, tell me:

• What infrastructure platforms are you targeting (e.g., Kubernetes, AWS/Terraform, bare-metal CI/CD)?
• Are you looking for fully autonomous fixes or an agent that proposes pull requests/approvals for human review?

For a self-healing DevOps agent, I’d choose LangGraph as the orchestration layer.

The key reason is that self-healing is less about “having several agents talk to each other” and more about controlled, stateful execution with explicit safety gates. LangGraph is designed around state graphs, checkpointing, branching, retries, and human-in-the-loop workflows—features that map unusually well to incident remediation.

My recommended architecture

                    ┌─────────────────┐
 Alert / Incident → │ Triage Agent    │
                    └────────┬────────┘
                             │
                       classify issue
                             ↓
                    ┌─────────────────┐
                    │ Investigation   │
                    │ Agent           │
                    └────────┬────────┘
                             │
                   logs / metrics / k8s
                             ↓
                    ┌─────────────────┐
                    │ Remediation     │
                    │ Planner         │
                    └────────┬────────┘
                             │
                      safety policy
                         /       \
                     safe         risky
                      ↓             ↓
              ┌────────────┐   Human approval
              │ Execute    │
              └─────┬──────┘
                    ↓
              verify health
                    │
             ┌──────┴──────┐
             │             │
           fixed        still broken
             │             ↓
             │       rollback/escalate
             ↓
          resolve

I'd make the graph deterministic around the dangerous parts, while letting the LLM handle interpretation and planning.

Framework comparison

Current framework comparisons similarly put LangGraph toward the production/stateful end of the spectrum, while CrewAI is optimized more for rapid role-based multi-agent prototypes.

The important part: don't let the LLM directly "fix production"

I'd separate reasoning from authority.

For example, give the agent tools like:

get_pod_status()
get_logs()
get_recent_deployments()
query_metrics()
describe_kubernetes_resource()

restart_pod()
rollback_deployment()
scale_deployment()
clear_cache()

But put a policy engine between the agent and destructive operations:

LLM proposes:
    restart payment-api pod

        ↓

Policy engine:
    Is this service allowed to auto-remediate?
    Is restart within blast-radius limits?
    Has it already tried this?
    Is there an active deployment?
    Is production currently under change freeze?

        ↓

    ALLOW / REQUIRE_APPROVAL / DENY

That gives you something much safer than an autonomous shell agent.

I'd start with only 3 remediation classes

For an MVP, make the agent capable of things such as:

1. Restart an unhealthy Kubernetes pod
2. Rollback the most recent deployment when a strong failure signal exists
3. Scale a service within predefined limits

Everything else should initially be observe → diagnose → recommend → human approval.

The agent should also have a mandatory verification loop:

detect
  ↓
diagnose
  ↓
propose fix
  ↓
policy check
  ↓
execute
  ↓
observe
  ↓
did it recover?
  ├── yes → document + resolve
  └── no  → rollback / escalate

That last step is particularly important: a self-healing agent isn't really self-healing unless it can determine whether its own intervention worked.

Stack I'd use

For a serious implementation:

• LangGraph — agent orchestration/state machine
• Python — agent runtime
• Kubernetes API — infrastructure actions
• Prometheus/Grafana — metrics and health signals
• Loki/Elasticsearch — logs
• PagerDuty/Opsgenie — incident input/escalation
• Postgres/Redis — persistent agent state
• OpenTelemetry — tracing the agent itself
• Policy layer — hard limits on what the agent can do
• Git/Argo CD/Flux — deployment/rollback operations where applicable

The biggest design mistake I'd avoid is building a “DevOps chatbot with kubectl access.” Build a bounded remediation state machine that happens to use an LLM for diagnosis and planning. That's much easier to test, audit, and eventually trust.

If you tell me whether your infrastructure is Kubernetes, AWS, Azure, GCP, or bare-metal, I can sketch a concrete architecture and LangGraph implementation for it.

Current framework comparisons similarly put LangGraph toward the production/stateful end of the spectrum, while CrewAI is optimized more for rapid role-based multi-agent prototypes.

The important part: don't let the LLM directly "fix production"

I'd separate reasoning from authority.

For example, give the agent tools like:

get_pod_status()
get_logs()
get_recent_deployments()
query_metrics()
describe_kubernetes_resource()

restart_pod()
rollback_deployment()
scale_deployment()
clear_cache()

But put a policy engine between the agent and destructive operations:

LLM proposes:
    restart payment-api pod

        ↓

Policy engine:
    Is this service allowed to auto-remediate?
    Is restart within blast-radius limits?
    Has it already tried this?
    Is there an active deployment?
    Is production currently under change freeze?

        ↓

    ALLOW / REQUIRE_APPROVAL / DENY

That gives you something much safer than an autonomous shell agent.

I'd start with only 3 remediation classes

For an MVP, make the agent capable of things such as:

1. Restart an unhealthy Kubernetes pod
2. Rollback the most recent deployment when a strong failure signal exists
3. Scale a service within predefined limits

Everything else should initially be observe → diagnose → recommend → human approval.

The agent should also have a mandatory verification loop:

detect
  ↓
diagnose
  ↓
propose fix
  ↓
policy check
  ↓
execute
  ↓
observe
  ↓
did it recover?
  ├── yes → document + resolve
  └── no  → rollback / escalate

That last step is particularly important: a self-healing agent isn't really self-healing unless it can determine whether its own intervention worked.

Stack I'd use

For a serious implementation:

• LangGraph — agent orchestration/state machine
• Python — agent runtime
• Kubernetes API — infrastructure actions
• Prometheus/Grafana — metrics and health signals
• Loki/Elasticsearch — logs
• PagerDuty/Opsgenie — incident input/escalation
• Postgres/Redis — persistent agent state
• OpenTelemetry — tracing the agent itself
• Policy layer — hard limits on what the agent can do
• Git/Argo CD/Flux — deployment/rollback operations where applicable

The biggest design mistake I'd avoid is building a “DevOps chatbot with kubectl access.” Build a bounded remediation state machine that happens to use an LLM for diagnosis and planning. That's much easier to test, audit, and eventually trust.

If you tell me whether your infrastructure is Kubernetes, AWS, Azure, GCP, or bare-metal, I can sketch a concrete architecture and LangGraph implementation for it.

For a self-healing DevOps agent, I’d pick LangGraph as the orchestration layer, with OpenHands as the execution/coding layer if the agent needs to modify code or infrastructure.

My recommended stack

1. LangGraph — control plane

• Models your agent as an explicit state machine/workflow.
• Supports durable execution, persistence, retries, and human-in-the-loop approvals.
• This is particularly valuable for DevOps because you don't want an LLM casually deciding what happens next.

2. OpenHands SDK — remediation worker

• Purpose-built for software-engineering agents.
• Provides tools for Bash, file editing, web access, MCP, etc.
• Can execute inside Docker/Kubernetes ephemeral workspaces, which is a very good fit for safely testing fixes.

3. Your existing observability stack — trigger Something like:

Prometheus/Datadog/Grafana → alert → agent

The agent shouldn't continuously "wander around" looking for problems. Let deterministic monitoring identify an anomaly, then give the agent a bounded incident.

4. Kubernetes/Docker — sandbox Give the agent a disposable environment where it can:

• inspect logs
• reproduce the problem
• make a change
• run tests
• verify the fix
• produce a patch/PR

Only after verification should anything touch production.

---

The architecture I'd build

             ┌──────────────────┐
             │ Prometheus / APM │
             │ Logs / Alerts    │
             └────────┬─────────┘
                      │ incident
                      ▼
             ┌──────────────────┐
             │    LangGraph     │
             │  Agent workflow  │
             └────────┬─────────┘
                      │
             ┌────────▼─────────┐
             │ Diagnose         │
             │ Gather context   │
             │ Classify severity │
             └────────┬─────────┘
                      │
             ┌────────▼─────────┐
             │ OpenHands worker │
             │ sandbox          │
             └────────┬─────────┘
                      │
             ┌────────▼─────────┐
             │ Fix + test       │
             │ rollback if bad  │
             └────────┬─────────┘
                      │
                 ┌────▼────┐
                 │ Policy  │
                 │ / Gate  │
                 └────┬────┘
                      │
             ┌────────▼─────────┐
             │ PR / deployment │
             │ / rollback      │
             └──────────────────┘

The important part: don't make it fully autonomous initially

I'd give it a graduated permission model:

The biggest mistake would be building an agent whose core loop is simply:

"Something looks wrong → LLM gets shell access → LLM fixes it."

Instead, make the workflow deterministic and the diagnosis/remediation agentic.

For example:

ALERT
  ↓
Is this an eligible incident?
  ↓
Collect evidence
  ↓
LLM diagnosis
  ↓
Known-safe remediation?
  ├── yes → execute → verify
  └── no  → create proposed fix
  ↓
Did health metrics recover?
  ├── yes → close incident
  └── no  → rollback / escalate

That's exactly where LangGraph's durable execution and human-interruption capabilities become useful.

Why not just use OpenHands?

You absolutely could. If your primary problem is:

"Give an agent a terminal and let it diagnose/fix software."

I'd start directly with OpenHands. Its SDK is explicitly designed for agents performing software maintenance and can run agents in isolated Docker/Kubernetes workspaces.

But if your problem is:

"Build a reliable autonomous incident-response system with policies, retries, approvals, state, and multiple specialized workers."

I'd use LangGraph + OpenHands.

LangGraph is the orchestrator; OpenHands is the engineer.

One other interesting option is Microsoft Agent Framework, but for this particular use case I'd put LangGraph/OpenHands ahead of it because the combination maps unusually well to the "diagnose → sandbox → modify → test → verify → rollback" lifecycle.

If you're building this from scratch, I can also sketch a production-grade architecture (Python + LangGraph + OpenHands + Kubernetes + Prometheus), including the agent state machine and safety/rollback design.

Building a self-healing DevOps system requires an orchestration framework that excels at state management, deterministic loops, robust tool usage, and human-in-the-loop gating . Because self-healing agents need to inspect logs, query metrics, modify configuration files or Kubernetes manifests, and execute fixes, a simple linear LLM wrapper will fail.

The top production-viable frameworks for building custom DevOps and remediation agents fall into a few clear categories:

1. The Heavyweight Production Standard:

• Best for: Complex, multi-step incident response workflows requiring strict conditional branching, loops (e.g., try fix → test → if fail, retry ), and state persistence.
• Why it fits DevOps: Self-healing is rarely a straight line. LangGraph lets you model your agent as an explicit state machine graph. You can save state at any checkpoint, pause execution for human approval before running a destructive command (Human-in-the-Loop), and trace complex debugging steps seamlessly using LangSmith.

2. The Type-Safe & Robust Choice: Pydantic AI

• Best for: Data-heavy triage, log analysis, and structured extraction where invalid tool outputs or malformed JSON will crash your automation.
• Why it fits DevOps: Built by the Pydantic team, this framework is engineered around strict type validation. When your agent reads a messy 500MB build log or parses a Kubernetes crash loop state, Pydantic AI forces the LLM's inputs and outputs into rigid, validated data schemas, drastically reducing downstream execution errors.

3. The Minimalist / Native Route: OpenAI Agents SDK

• Best for: Lightweight, single-agent setups or quick internal tooling where you want to spin up a triage bot with minimal boilerplate.
• Why it fits DevOps: If your self-healing task is narrow—such as reading a failure.log , classifying the error, and creating a targeted GitHub pull request—heavy graph frameworks might be overkill. The minimalist SDK gives you native handoffs, guardrails, and tool calling without fighting a massive abstraction layer.

Key Architectural Consideration: The Tool Layer (Model Context Protocol)

Regardless of which framework you choose, the real superpower for 2026 DevOps agents is standardizing how they talk to your infrastructure. Exposing your logs, Git repositories, and cluster tools via MCP (Model Context Protocol) means you can swap out or upgrade your agent framework later without rewriting your entire tool integration suite.

Always implement a policy-driven guardrail framework (like treating write access as something "earned" via staged autonomy—from L0 read-only recommendations to L2 policy-bounded auto-remediation) so your self-healing loop doesn't accidentally amplify an outage.

To help narrow down the ideal choice, tell me:

• What is the primary target for self-healing (e.g., Kubernetes manifests, CI/CD pipeline test failures, or cloud infrastructure drift)?
• Do you require fully autonomous execution , or a human-approval gate before applying fixes?

If you're building a self-healing DevOps agent, my default choice in 2026 would be LangGraph as the orchestration layer, with a sandboxed execution environment and tightly scoped DevOps tools around it.

Why: self-healing isn't just "give an LLM shell access." You want a workflow that can observe → diagnose → propose → validate → act → verify → rollback/escalate, with durable state and human approval where appropriate. LangGraph is specifically designed around durable execution, stateful workflows, human-in-the-loop control, and customizable branching/loops.

My recommended architecture

                    ┌──────────────────┐
 Alert / SLO ──────►│  Incident Agent  │
                    └────────┬─────────┘
                             │
                       investigate
                             ▼
                    ┌──────────────────┐
                    │   Diagnosis      │
                    │ logs/metrics/traces
                    └────────┬─────────┘
                             │
                       generate plan
                             ▼
                    ┌──────────────────┐
                    │   Safety Gate    │
                    │ policy + dry run │
                    └────────┬─────────┘
                         approve?
                       /           \
                     yes            no
                      │              │
                      ▼              ▼
              ┌──────────────┐   Human approval
              │ Actuator     │
              │ K8s/Terraform│
              │ cloud/CI/CD  │
              └──────┬───────┘
                     │
                   verify
                     ▼
              recovered? ──no──► rollback / escalate
                     │
                    yes
                     ▼
                  resolve

Why LangGraph over a generic "agent framework"

The important feature isn't the ability to call an LLM. It's control over what the LLM is allowed to do.

LangGraph gives you:

• Durable execution — an agent can survive restarts and resume a workflow.
• Explicit state — useful for keeping incident context, hypotheses, actions and observations.
• Human-in-the-loop interrupts — e.g. "restart pod" can be automatic, while "modify production database" requires approval.
• Deterministic workflow nodes alongside agentic nodes.
• Loops and branching — essential for diagnose → fix → verify → retry.
• Observability/integration with LangSmith for debugging agent behavior.

I'd actually use LangChain's create_agent/tools for the agent interface, with LangGraph underneath rather than building everything directly from raw model calls. LangChain's current agent runtime is built on LangGraph's durable runtime.

Where OpenHands fits

If the system's job is primarily fixing code, rather than operating infrastructure, I'd seriously consider OpenHands.

OpenHands is purpose-built for autonomous software engineering and provides an SDK, sandboxed execution, integrations and workflows around GitHub/GitLab issues and code changes.

So I'd think of the choice as:

The most important part: don't give it unrestricted production access

For a self-healing system, the safety architecture matters more than the agent framework.

Google's current SRE work on AI operators recommends exactly the pattern I'd use: least-privilege agent identities, risk evaluation, dry runs, circuit breakers, deterministic actuation controls, progressive autonomy, and the ability to immediately stop/revoke agents.

For example:

L0 — observe

"API latency is elevated."

L1 — investigate

Query Prometheus, Loki, traces, recent deployments.

L2 — suggest

"Deployment api-v42 introduced the regression. Roll back?"

L3 — bounded autonomy

Automatically roll back a deployment if error rate > X for Y minutes and the rollback passes predefined safety checks.

L4 — dangerous actions

Database changes, IAM changes, networking changes, deleting resources → human approval.

That progression is much safer than an agent with kubectl, AWS credentials and a shell.

What I'd build

For a first production-quality version:

LangGraph → agent orchestration/state machine

MCP/tool layer → Prometheus/Grafana, Kubernetes, AWS/GCP/Azure, GitHub, PagerDuty, Terraform, CI/CD

Sandbox → isolated environment for commands and scripts

Policy engine → explicitly defines which operations the agent may perform

Dry-run actuator → agent proposes actions before mutation

Approval service → Slack/PagerDuty/web UI for higher-risk operations

Observability/evaluation → record every observation, reasoning summary, proposed action, tool call, result and recovery outcome

Circuit breaker → kill switch + action/rate limits

The key design principle is: the LLM should decide what it wants to accomplish, but deterministic infrastructure should decide whether it is permitted to do it.

If you're starting from scratch, LangGraph is the framework I'd pick. For a particularly ambitious system, I'd pair it with OpenHands for code remediation and make Kubernetes/cloud APIs available through a constrained tool layer rather than handing the model a general-purpose shell.

Building a "self-healing" DevOps system requires an agentic framework that excels at state management, deterministic control flow, and secure tool execution (the "brain" and the "body"). Unlike creative writing or chat assistants, a DevOps agent cannot afford chaotic looping or unmonitored side-effects when interacting with infrastructure.

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

• LangGraph
  • Best for: Complex, stateful, and cyclic workflows.
  • Why it fits DevOps: It models agent logic as explicit state machines (directed graphs with nodes and edges). For self-healing, you need absolute control over the loop: Observe failure → Analyze log → Propose fix → Human approval gate → Execute patch . LangGraph's native checkpointing, "time-travel" debugging, and durable execution make it the industry standard for production reliability.
• Microsoft Agent Framework (AutoGen / Semantic Kernel)
  • Best for: Enterprise .NET/Python hybrid stacks and Azure-native environments.
  • Why it fits DevOps: The unified architecture blends AutoGen's multi-agent conversational patterns (where a Planner, Log Analyzer, and Executor agent debate/verify a fix) with Semantic Kernel's robust enterprise plugins. It handles heavy async event-driven message passing well, making it ideal for large corporate infrastructure.
• CrewAI
  • Best for: Rapid prototyping of role-based multi-agent teams.
  • Why it fits DevOps: If you want to spin up a specialized "crew" (e.g., a SRE agent, a QA testing agent, and a Git PR writer agent) with minimal boilerplate, CrewAI provides the fastest path from zero to a working demo. However, it can require more careful scaffolding if you need rigorous, deterministic state control.
• n8n (with AI Node capabilities)
  • Best for: Visual, low-code/event-driven operational control planes.
  • Why it fits DevOps: Many teams implement self-healing infrastructure not purely via code frameworks, but by pairing webhooks (like a GitHub Actions or Kubernetes crash alert) with visual node-based orchestrators. It handles the "body" (integrating with Slack, Docker restarts, and Jira tickets) seamlessly alongside LLM reasoning nodes.

The Missing Piece: The Integration Layer ("The Body")

Regardless of which framework you pick for the brain, the hardest part of a self-healing DevOps system is securely executing commands (interacting with GitHub APIs, reading cluster logs, running terraform validation).

Most production teams pair their chosen framework with an action layer like the Model Context Protocol (MCP) or integration platforms like Composio to handle secure tool execution, authentication tokens, and API sandboxing without writing custom wrappers for every DevOps tool.

To help narrow down the ideal stack, tell me:

• What is your primary environment or cloud (Kubernetes, AWS, Azure, GitHub Actions)?
• Do you prefer a Python or TypeScript/C# ecosystem?
• Will this agent automatically apply fixes directly , or require a human-in-the-loop approval first?

For a self-healing DevOps agent, I’d pick OpenHands SDK + a workflow/orchestration layer such as LangGraph rather than a generic multi-agent framework.

My recommendation

1. OpenHands SDK — for the actual “engineer”

• Built specifically for software-engineering agents.
• Gives the agent tools for shell commands, files, code editing, web access, MCP, etc.
• Supports sandboxed execution and remote execution with Docker/Kubernetes.
• Model-agnostic, so you aren't locked to one LLM.

That maps very naturally to:

alert → investigate → inspect logs → reproduce → make minimal change → test → deploy/rollback

OpenHands' SDK is explicitly designed around agents that can execute commands and interact with real software environments.

2. LangGraph — for the control plane Use it to make the self-healing process deterministic, rather than letting an LLM freely decide what happens next.

For example:

                    ┌─────────────┐
                    │   Alert     │
                    └──────┬──────┘
                           ↓
                    ┌─────────────┐
                    │  Diagnose   │
                    └──────┬──────┘
                           ↓
                 ┌─────────┴─────────┐
                 │                   │
             Known fix           Unknown issue
                 │                   │
                 ↓                   ↓
           Apply fix            Human review
                 │
                 ↓
              Test
                 │
          ┌──────┴──────┐
          ↓             ↓
       Passed         Failed
          │             │
          ↓             ↓
       Deploy        Rollback

The key is that the LLM should propose actions, while your workflow controls which actions are actually permitted.

What I'd build

OpenHands' architecture already separates the agent reasoning loop, state management, tools, workspace, and extensibility, which makes it a good fit for this architecture.

One important design principle

Don't start with:

“AI, fix whatever is broken.”

Start with:

“AI can perform these 12 explicitly permitted remediation operations.”

For example:

restart_service
scale_deployment
clear_temp_files
rotate_failed_pod
rollback_last_deployment
re-run_migration
invalidate_cache
change_config X

Then give the agent read-heavy permissions and very narrow write permissions.

For a first version, I'd allow autonomous remediation only when:

1. The symptom matches a known incident pattern.
2. The proposed change is in an allowlist.
3. The agent can reproduce/verify the problem.
4. A post-change health check passes.
5. Automatic rollback is available.
6. The action is completely audited.

That makes it much closer to a junior SRE with guardrails than an unrestricted shell agent.

What I would not choose

AutoGen wouldn't be my choice for a new project now. Microsoft says AutoGen is in maintenance mode and recommends its successor, Microsoft Agent Framework, for new projects.

CrewAI is attractive if your problem is primarily “multiple specialized agents working together,” but self-healing infrastructure is more naturally modeled as a stateful, failure-sensitive workflow than a crew of autonomous personas.

Bottom line:
OpenHands SDK for the agent + LangGraph for orchestration + sandboxed execution + explicit remediation tools + mandatory rollback/verification.

If your target is something like Kubernetes self-healing, this stack is particularly compelling—I can sketch the architecture for an agent that receives Prometheus alerts and safely remediates Kubernetes incidents.

For a self-healing system where an AI agent diagnoses and fixes minor operational issues, the best framework choice depends on how deterministic and structured your control loops need to be . The top orchestration choices are LangGraph for stateful, cyclic remediation workflows, Microsoft AutoGen for multi-agent diagnostic swarms, and Temporal combined with custom Python for enterprise-grade execution safety.

Framework Comparison for DevOps Agents

Architectural Best Practices for Self-Healing Systems

1. Model the Healing Loop as a Graph: Use LangGraph to build a clear, stateful cycle: ingest telemetry (logs/metrics) → plan remediation → validate via dry-run (helm install --dry-run or terraform plan) → execute or escalate.
2. Enforce External Validation (Never Trust "Done"): Do not let the AI blindly apply patches. Force it to use deterministic tools like linters, test suites, or staging validators as reality checks before pushing a fix to production.
3. Keep Humans in the Loop for Mutating Actions: Allow the agent to autonomously open pull requests, restart safe non-production pods, or isolate flaky tests, but require explicit human approval via webhooks or Slack integration for destructive or high-impact state changes.
4. Implement Persistent Memory: Give your agents a local workspace or vector store tracking lessons.md or past incident logs so they don't repeat historical remediation mistakes.

To help narrow down the ideal stack, tell me:

• What observability tools (e.g., Datadog, Prometheus, ELK) and infrastructure layer (Kubernetes, AWS, GitHub Actions) are you targeting?
• Do you want the agent to fully auto-execute fixes or stop at creating a Pull Request for human review?