How It Works
Coding agents accelerated feature work and moved the bottleneck to everything after the commit: the work that keeps software reliable, secure, cost-efficient and supportable. A common workaround is to add a few skills to a coding agent and run it from a laptop when needed. This works until the engineer is unavailable or doesn't know what to ask, or until the skills go stale as systems change. A coding agent's output depends on who prompts it and on the model behind it. That suits novel feature work. It fails repetitive operational work that has to produce the same quality of result every time.
Autoheal is a self-improving software factory for that post-coding work. It turns ad-hoc agent workflows into a shared, cloud-based system that runs in the background, 24x7, in a governed environment. One engineer's practices then become available to every engineer and agent. The factory has two planes and one loop:
- The context plane: what every agent reads before it acts, and what Autoheal improves.
- The control plane: how every agent runs and is governed.
- The self-improvement loop: the Evaluator and Healer, which keep agents accurate and cost-efficient as your systems change.
Agents for post-coding work
Autoheal groups agents by the post-coding work they take on.
| Area | Agents |
|---|---|
| Production operations | Incident Response · Alert Triage |
| Security | Vulnerability Remediation |
| Developer experience | AI Coding Cost Efficiency: an agent owned by your DevEx team that lowers your coding agents' cost per task. It does not change which coding agents developers use |
Autoheal doesn't manage or replace the coding agents your developers already use, such as Claude Code, Codex or Cursor. It changes the context they read, through the CLI, so an improvement made for one agent reaches every agent, coding agents included.
Any other step you can describe in plain English can become a custom agent with its own trigger, instructions, and integration allow-list. See Build Your Own Agents.
Context plane
The context plane is what every agent reads before it acts, and it is the part of the factory the self-improvement loop changes. It has two parts:
- A context graph that links your repositories, services, teams and people, with tickets and releases read live from the connected integrations. This is the Engineering Context Graph and its catalog.
- A skill and memory registry that holds the skills, AGENTS.md files and memories agents read for each task.
The graph connects four layers of your environment:
Services, dependencies, topology, deployment targets, and resource configurations. The ECG knows how your systems relate to each other.
Repositories, recent deployments, pull requests, CI/CD pipelines, and change history. The ECG knows what changed and when.
Observability platforms, incident management systems, documentation wikis, and custom internal tools, all connected via MCP integrations.
Skills, past incident RCAs, service ownership, debugging procedures, and team expertise.
Control plane
The control plane is how every agent runs. Agent definitions, budgets, model selection, identity, roles and approval policy live in one governance layer, so a team governs every agent the same way.
| Capability | What it means |
|---|---|
| Agent definitions as code | Agent definitions are versioned, diffed, and promoted through the review workflow your team already uses for services (GitOps coming soon) |
| Budgets and model selection | Spend is tracked per agent and per team. Frontier models handle complex reasoning such as hypothesis formation and root cause analysis. Lower-cost or open-weight models take the steps where evaluations show they perform well |
| Identity and roles | Agents and people act under roles and SSO identity, and every action is attributed |
| Approval policy | Tenant-wide governance policies pause any matching tool call, such as every write, until a person approves it. A run that needs a decision pauses as waiting for input instead of acting |
| Escalation | When a step calls for it, an agent escalates to your DevEx, DevOps or SRE team for input or approval |
| Observability and audit | Every run records its trigger, the integrations it queried, the context it loaded, each step it took, and its conclusion. The audit trail holds this record, with the evidence behind it |
| Sovereign deployment | Fully-managed SaaS by default, or BYOC in your own cloud, connected or airgapped |
Tool gateway
A tool gateway registers, scopes and audits every integration once, for every agent. Agents reach your systems over the Model Context Protocol (MCP) through integrations spanning code and CI/CD, infrastructure, observability, docs, collaboration, and task management.
- Least privilege by default. Many integrations ship only read tools. Where write tools exist, agents use them only when granted, and governance policies can require approval for each write. Each agent has an explicit allow-list enforced by the platform rather than by prompt instructions, and read and write access are granted separately.
- Audited. Every tool call is recorded in the audit trail.
- Real-time data. There are no data syncing or ETL pipelines. Agents query your tools live during a run.
- Extensible. Connect any tool by building a custom MCP server.
See Sovereignty and Security.
Self-improvement
Agents drift as your codebase, production architecture and tools change. For this reason, Autoheal runs two agents whose only job is to keep the others accurate and cost-efficient.
- Evaluator. Scores every run's trajectory and outcome against rubrics generated from downstream signals: review comments, CI re-runs, fired alerts, and the incident's confirmed root cause. It runs continuously on your data, in your isolated tenant (SaaS) or your own environment (BYOC). Your run data is never used to train models.
- Healer. Turns weak scores into specific context changes. Examples include an updated skill, an AGENTS.md correction, a new memory, a narrower tool scope or a different model. Each change is back-tested against your run history and opened as a pull request only if it clears a blast-radius threshold.
- Engineer approval. Every change is version-controlled in git and needs an engineer's approval to go live, reviewed like any other pull request.
Because the context is shared, an approved change improves every agent that reads it, including coding agents in the same repositories. The loop only catches what leaves a downstream signal. A failure mode with no review comment, re-run, alert or confirmed root cause stays invisible until someone notices it in a run. See Self-Improvement, the Evaluator and the Healer.
What one run looks like
The planes above are platform-wide. This section narrows to a single Incident Response run, an investigation, to show how they come together.
The Investigation Agent
The Investigation Agent is the orchestrator. It uses a team of subagents to:
- Assess the situation. Read the alert, ticket, or user query to understand the problem.
- Plan the investigation. Determine which tools to query and in what order.
- Gather evidence. Query integrations (Datadog, Grafana, GitHub, and others) through MCP.
- Consult the ECG. Check past incidents, skills, and service ownership for context.
- Form hypotheses. Generate ranked probable causes with supporting evidence.
- Propose fixes. Suggest remediations based on skills, past resolutions, or code-level changes.
- Capture learnings. After resolution, record memories that feed back into the ECG.
The agent maintains full conversation context, so investigations are interactive rather than fire-and-forget. You can ask follow-up questions, redirect it mid-run ("I think this is related to the 3 PM migration"), or expand scope without losing prior context.
Fast vs Deep investigation
You choose how much reasoning the agent applies:
- Fast. A single hypothesis, for a faster time-to-root-cause. Best for well-understood alerts and routine checks.
- Deep. Multiple hypotheses, cross-validated against the evidence before a conclusion is presented. Best for ambiguous or high-stakes incidents.
Both modes produce the same evidence and run through the same adversarial review. The difference is how many hypotheses the agent explores. The Alert Triage and Incident Response agents map onto these modes by default. Alert Triage uses Fast, which suits high alert volume. Incident Response uses Deep to drive a declared incident to a validated root cause.
Evidence
Every decision an agent makes is documented as evidence, a transparent record of its reasoning:
| Element | Description |
|---|---|
| Data sources queried | Which tools were consulted and what data was retrieved |
| Hypotheses considered | All probable causes evaluated, not just the final answer |
| Support for/against | What data supported or contradicted each hypothesis |
| Path decisions | Why the agent pursued certain diagnostic paths over others |
| Confidence levels | How confident the agent is in each finding, and why |
Evidence makes a run auditable. It lets engineers verify reasoning rather than just results. When an agent is wrong, it shows you where the reasoning went off-track. In regulated environments it's also the documentation trail.
Adversarial review
Before findings reach your team, a separate validation step challenges them. The step:
- Verifies that every finding is backed by concrete, retrievable evidence.
- Flags gaps the investigation should have covered.
- Checks that the causal chain from symptoms to root cause holds up.
- Filters correlations that don't imply causation.
Conclusions that survive reach you with their evidence intact. Conclusions that don't survive are sent back for more investigation. The step is there to reduce false positives, so a stated root cause comes with evidence your team can check before acting.
Alert normalization
One incident typically fires alerts across many tools at once: a PagerDuty page, a Datadog monitor, a Grafana alert, and a Sentry spike. Rather than opening an investigation per alert, Autoheal:
- Normalizes the alerts into a consistent format.
- Deduplicates alerts that describe the same issue.
- Categorizes each alert by service and failure domain.
- Correlates simultaneous alerts to tell cascading failures from independent ones.
Your on-call engineer sees one consolidated investigation instead of a wall of noise.
Root cause and fixes
Investigations produce a structured 5-Why RCA built from actual evidence rather than recollection. The RCA contains:
- Incident summary
- Timeline
- The 5-Why chain from symptom to systemic cause
- Impact assessment
- Mitigations applied
- Preventive measures with owners
Because it's generated from the run, every incident gets a post-mortem instead of only the ones someone remembers to write.
When the root cause is a code defect, the agent pinpoints the file, function, and logic responsible, then proposes the specific change. Your team reviews it with full context on why it was proposed and how it connects to the incident.
Investigation flow
A run starts from a PagerDuty alert, Datadog monitor, Sentry exception, Slack message, support ticket, or manual input in the Autoheal UI.
The agent loads relevant context from the ECG: service ownership, related skills, past incidents for this service, recent deployments, and known dependencies.
The agent queries your connected integrations, pulling metrics, logs, traces, deployment history, and error data. It builds a timeline of events.
Based on evidence and ECG context, the agent generates ranked hypotheses, each recording its reasoning and supporting data.
Findings are validated to ensure they're evidence-backed and logically sound.
The agent proposes mitigations such as rollbacks, restarts, config changes, and scaling actions. For code-level issues, it surfaces preventive fixes for review.
After resolution, memories are captured and fed back into the ECG. The next run on this service then starts from more context than this one did.
That last step is the platform closing its own loop. The run that just completed becomes a memory the next one reads. The Evaluator scores it once its downstream outcome is known.