Core Incident API
Incident lifecycle, event ingestion, and correlation across monitoring sources.
Detect. Investigate. Resolve. Learn.
AIRP continuously monitors operational systems, investigates root causes, recommends corrective actions, executes approved runbooks, verifies recovery, and learns from every event — keeping humans in control of impactful actions.
Phase 2 in active development
AI Investigation Agent
4
Phases
16
Workflow Steps
9
Core Engines
The Problem
Modern IT operations teams rely on disconnected tools — ServiceNow, Grafana, Prometheus, PagerDuty, Datadog, cloud providers, and internal dashboards. Engineers spend valuable time correlating alerts, searching historical incidents, gathering evidence, and executing repetitive runbooks.
High MTTR
Mean time to resolution suffers from manual correlation
Alert Fatigue
Unrelated events flood engineers without deduplication
Lost Knowledge
Institutional expertise walks out the door with every incident
AIRP becomes the orchestration layer across these systems — reducing MTTR, improving operational consistency, and preserving organizational knowledge.
Development Roadmap
Four deliberate phases from core incident infrastructure to continuous learning — each mapped to platform components and workflow steps.
Incident lifecycle, event ingestion, and correlation across monitoring sources.
Domain-specialized agents that gather evidence and perform root cause analysis.
Policy evaluation, human-in-the-loop approvals, and safe runbook execution.
Verification, outcome tracking, embeddings, and operational knowledge reuse.
End-to-End Workflow
From first alert to organizational learning — every step is auditable, evidence-driven, and human-gated where it matters.
Receive alerts from monitoring and ticketing systems.
Phase 1
Transform heterogeneous alerts into a unified schema.
Phase 1
Group related events into a single incident.
Phase 1
Open or link incidents with full lifecycle tracking.
Phase 1
Attach assets, ownership, dependencies, and runbooks.
Phase 2
Assess severity, impact, and confidence scores.
Phase 2
Search historical incidents and runbooks via Qdrant.
Phase 2
Route to specialized domain agents.
Phase 2
Collect logs, metrics, and configuration data.
Phase 2
Reason over evidence to identify the root cause.
Phase 2
Generate corrective actions with rollback strategy.
Phase 3
Present evidence and await engineer approval.
Phase 3
Run approved MCP tools and remediation scripts.
Phase 3
Confirm resolution via logs, metrics, and synthetics.
Phase 4
Close tickets and notify stakeholders.
Phase 4
Store outcomes and embeddings for future incidents.
Phase 4
Platform Architecture
Nine vendor-neutral services orchestrate monitoring, investigation, policy, execution, verification, and learning.
Ingests alerts from ServiceNow, PagerDuty, Grafana, and more.
Phase 1
Groups related events into unified incidents.
Phase 1
Owns incident lifecycle and persistence.
Phase 1
Retrieves historical incidents via PostgreSQL and Qdrant.
Phase 2
Coordinates specialized domain agents.
Phase 2
Evaluates risk, maintenance windows, and safety policies.
Phase 3
Runs approved MCP tools and runbooks.
Phase 3
Confirms remediation using logs, metrics, and synthetics.
Phase 4
Stores outcomes, embeddings, and operational knowledge.
Phase 4
Domain Agent Architecture
AIRP organizes investigation by technical domain — not traditional support tiers. Each agent operates under a defined permission profile.
Permission Profiles
Guiding Principles
Every architectural decision answers one question: does this make AIRP a better AI Operations Engineer?
Evidence before action
Human approval before impactful remediation
Every action is auditable
Vendor-neutral integrations
Security by default
Every incident improves future investigations