I Built IRAS: An AI Incident Response Agent With Human Approval Built In

An open-source LangGraph + FastAPI system for alert triage, root-cause analysis, remediation planning, and post-mortems — designed for production safety, not AI hype.

Every on-call engineer knows the pattern.

The alert fires at 3 AM. You open your laptop half-awake. You check the dashboard. You dig through logs. You compare recent deployments. You form a hypothesis. You write a Slack update. You prepare a remediation plan. Then, after everything is over, you still have to write the post-mortem.

Most of this work is not creative engineering.

It is structured investigation.

That is why I built IRAS — an open-source autonomous incident response agent that handles the repetitive parts of incident response while keeping a human in control before anything touches production.

IRAS does not try to replace SREs or DevOps engineers.

It tries to remove the exhausting middle layer of incident response: triage, context gathering, root-cause analysis, remediation planning, and documentation.

The important part is this:

IRAS can reason through an incident, but it cannot blindly execute a fix without human approval.

That design choice matters.

The Problem: Most Incident Response Is Still Manual Glue Work

Modern engineering teams already have monitoring tools.

They have Prometheus, Grafana, Datadog, PagerDuty, Slack, logs, dashboards, deployment history, traces, and runbooks.

The problem is not lack of information.

The problem is that the information is scattered.

When an incident happens, an engineer still has to manually connect the dots:

Alert → dashboard → logs → metrics → deployment history → hypothesis → fix → approval → post-mortem

That workflow is repetitive, slow, and mentally expensive.

In a high-pressure incident, the cost is even higher because the engineer is trying to reason clearly while users are affected and stakeholders are waiting for updates.

IRAS turns that messy workflow into a structured agent graph.

What IRAS Does

IRAS is an autonomous AI incident response agent built with:

• LangGraph for deterministic multi-step workflow orchestration
• FastAPI for alert ingestion and approval APIs
• Pydantic AI for typed agent outputs
• Claude for triage, RCA, and remediation reasoning
• PostgreSQL for durable workflow checkpointing
• Pytest for reliability testing

The workflow looks like this:

Alert
  ↓
Triage
  ↓
Context Gathering
  ↓
Root Cause Analysis
  ↓
Remediation Plan
  ↓
Human Approval
  ↓
Execution or Escalation
  ↓
Post-mortem

The original DEV article describes the core flow as:

Alert → Triage → RCA → Remediation → Post-mortem → Human Approval → Execution

The GitHub version extends this into a more detailed 9-node LangGraph state machine with context gathering, approval handling, escalation, and post-mortem persistence. (GitHub)

The Most Important Design Decision: Do Not Trust the Model

A lot of AI agent demos fail at the same point.

They assume the model is correct.

IRAS does not.

The model can suggest a remediation plan, but the system enforces safety rules in code.

For example:

if any(step.risk_level == "high" for step in plan.steps):
    plan.requires_human_approval = True
if any(not step.rollback_command.strip() for step in plan.steps):
    plan.reversible = False
    plan.requires_human_approval = True

That means approval is not just a prompt instruction.

It is a system invariant.

If the model says a risky fix is safe, the code can still override it.

If the model forgets a rollback command, the plan is blocked.

If RCA confidence is too low, the graph can retry context gathering or escalate instead of pretending to know the answer.

This is the difference between a cool AI demo and something closer to a production-grade workflow.

How the Human Approval Step Works

The most interesting part of IRAS is the approval checkpoint.

Instead of faking human-in-the-loop behavior with polling, the system uses LangGraph’s interrupt pattern.

The graph pauses before remediation.

The incident state is checkpointed to PostgreSQL.

Then the engineer can approve or reject through an API or Slack-style workflow.

Conceptually:

human_decision = interrupt({"message": "Approve remediation plan?"})
if human_decision["approved"]:
    return apply_remediation(state)
else:
    return escalate(state)

This makes the workflow durable.

If the server restarts, the incident does not disappear.

If the process crashes, the approval state can be restored.

For incident response, that matters because the system cannot lose track of a half-handled incident.

What Happens When an Alert Comes In

IRAS accepts alert payloads through a FastAPI webhook.

Example:

curl -X POST http://localhost:8000/webhook/alert \
  -H "Content-Type: application/json" \
  -d '{
    "title": "High error rate on payment-service",
    "timestamp": "2026-05-03T10:30:00Z",
    "service": "payment-service",
    "error_rate": 0.45
  }'

The system returns an incident ID and starts processing.

{
  "incident_id": "550e8400-...",
  "status": "processing"
}

Then the graph begins:

1. Validate the incoming alert.
2. Determine severity.
3. Gather context from logs, metrics, and deployments.
4. Generate a root-cause hypothesis.
5. Create a remediation plan.
6. Pause for human approval.
7. Execute or escalate.
8. Generate a post-mortem.

The repo documents API endpoints for alert ingestion, approval, rejection, and health checks. (GitHub)

Why I Used LangGraph

For simple AI apps, a prompt chain might be enough.

For incident response, it is not.

Incident response needs:

• state
• retries
• branching
• confidence checks
• escalation paths
• approval checkpoints
• persistence
• observability

LangGraph is a better fit because the workflow is not just “ask the model and return the answer.”

It is a graph of decisions.

For example:

RCA confidence < threshold → gather more context
RCA attempts exhausted → escalate
Plan approved → apply remediation
Plan rejected → escalate
Remediation done → write post-mortem

This makes the workflow understandable, testable, and easier to debug.

Why I Used Pydantic AI

Free-form model output is dangerous in automation.

If an agent returns a paragraph when the system expects structured remediation steps, the workflow becomes fragile.

IRAS uses typed models so each stage produces predictable outputs.

Instead of trusting raw text, the system expects structured objects like:

TriageResult
ContextBundle
RootCauseHypothesis
RemediationPlan
RemediationStep
PostMortem

This makes downstream automation safer because each node receives validated data instead of arbitrary prose.

Testing: The Part Most AI Agent Demos Skip

IRAS includes 292 passing tests and reports 99% coverage in the current project materials. The test suite covers unit tests, integration tests, end-to-end graph behavior, mock clients, edge cases, and adversarial scenarios. (DEV Community)

Some scenarios tested include:

• model misclassifies risk level
• remediation plan has no rollback command
• context tools fail
• concurrent incidents run at the same time
• long or malformed payloads arrive
• confidence never reaches the required threshold
• escalation path triggers correctly

This is important because incident response automation cannot rely on happy-path demos.

The question is not:

Can the agent work once?

The real question is:

What happens when the agent is wrong, uncertain, overloaded, or missing context?

That is where production design starts.

Local Setup

You can run IRAS locally with Python and Docker.

Basic setup:

git clone https://github.com/krishnashakula/IRAS.git
cd IRAS

python -m venv .venv
source .venv/bin/activate

pip install -e ".[dev]"
cp .env.example .env

Required configuration:

ANTHROPIC_API_KEY=your_key_here
POSTGRES_URL=postgresql://user:pass@host:5432/db

Then run:

python run.py

The repo also includes Docker and docker-compose support, plus fallback mock clients for integrations such as Slack, PagerDuty, Prometheus, Elasticsearch, and Loki when real tokens are not configured. (GitHub)

What IRAS Is Not

IRAS is not magic.

It is not a guarantee that every incident will be fixed automatically.

It is not a reason to remove human judgment from production operations.

Current limitations include:

• RCA quality depends on available logs and metrics.
• Alerts need enough structure to be useful.
• Remediation proposals still require review.
• Real production use needs authentication, signed approval flows, TLS, observability, and careful permissions.

That is intentional.

The goal is not reckless automation.

The goal is safer, faster incident response.

Where This Can Go Next

IRAS is still evolving.

The most useful next improvements are:

• real Slack approval buttons
• signed webhook verification
• deeper Prometheus and Loki integrations
• Datadog support
• custom remediation playbooks
• model fallback support
• long-term incident memory
• post-mortem search
• deployment-aware RCA
• stronger production auth around approve/reject endpoints

The repo already documents a production checklist including auth for approval endpoints, production environment settings, real Slack and PagerDuty tokens, tracing, TLS, and PostgreSQL connection pooling. (GitHub)

Why I Open-Sourced It

AI agents are easy to demo.

They are hard to trust.

IRAS is my attempt to build an agentic system that respects production constraints:

• deterministic workflow
• typed outputs
• human approval
• durable state
• fallback paths
• test coverage
• clear escalation
• post-incident documentation

The repo is open source so other engineers can inspect the architecture, run it locally, break it, improve it, and adapt it to their own incident response workflows.

If you are working on DevOps, SRE, AI agents, LangGraph, or production automation, I would love your feedback.

GitHub repo: [https://github.com/krishnashakula/IRAS](https://github.com/krishnashakula/IRAS)

If the project is useful, consider giving it a star or opening an issue with ideas for the next integration.