AKAR (Anomaly Knowledge & Automated Root-cause)

Inspiration

Modern engineering teams have access to extensive observability data, yet incident response remains highly manual. Engineers often switch between metrics, logs, traces, Kubernetes workloads, and runbooks to identify the root cause of an issue. We asked ourselves:

What if AI could connect the evidence, investigate incidents, recommend solutions, and verify that the system actually recovered?

This idea became AKAR (Anomaly Knowledge & Automated Root-cause), an AI-powered incident intelligence and service continuity platform.

Our goal is not to build another observability dashboard, but to bridge the gap between monitoring, decision-making, and safe recovery.

AKAR follows a closed-loop workflow: $$ \text{Observe} \rightarrow \text{Hypothesize} \rightarrow \text{Validate} \rightarrow \text{Act} \rightarrow \text{Verify} $$

What it does

AKAR acts as an intelligent incident-response layer for cloud and Kubernetes infrastructure. It unifies telemetry and investigation findings into one timeline, helping engineers understand incidents without manually correlating multiple tools.

Its core capabilities include: Detecting and triaging anomalies Collecting and correlating metrics, logs, and traces Analyzing service topology and ranking probable root causes Using AI investigation and operational RAG Recommending risk-aware remediation Executing bounded, low-risk actions Requiring human approval for higher-risk actions Verifying recovery and maintaining an audit trail

The workflow connects every stage: $$ \text{Incident} \rightarrow \text{Evidence} \rightarrow \text{RCA} \rightarrow \text{Remediation} \rightarrow \text{Verification} $$

For example, if a Kubernetes service experiences high latency, AKAR can investigate CPU pressure and replica availability, then recommend scaling the workload. It verifies pod readiness and telemetry recovery before resolving the incident.

Successful action does not necessarily mean successful recovery. AKAR escalates incidents when safe recovery cannot be established.

Risk-based automation

Risk Label	Akar Behaviour
Low	Bounded automatic execution
Medium	Engineer approval
High	Manual execution with AI recommendation
Critical	Blocked or escalated

How we built it

AKAR is designed around the RISE principles.

R (Reliable) Incidents follow a controlled lifecycle, with recovery verification, bounded retries, cooldown periods, escalation, and audit trails.

I (Intelligent) AI investigation combines evidence retrieval, root-cause ranking, service topology, and operational knowledge to reduce the time between an alert and an informed decision.

S (Safe) AKAR separates AI recommendations from infrastructure execution. It uses risk evaluation, Kubernetes RBAC, blast-radius checks, approval requirements, and bounded actions.

$$ \text{AI Recommendation} \rightarrow \text{Risk Evaluation} \rightarrow \text{Policy Check} \rightarrow \text{Bounded Execution} $$

If an action cannot be established as safe, AKAR does not execute it.

E (Easy)

AKAR brings relevant investigation context into one experience, reducing the need to switch between monitoring dashboards, Kubernetes tools, and runbooks.

AI agent workflow $$ \text{Detect} \rightarrow \text{Triage} \rightarrow \text{Investigate} \rightarrow \text{Diagnose} \rightarrow \text{Propose Remediation} \rightarrow \text{Check Risk} \rightarrow \text{Execute Safely} \rightarrow \text{Verify Recovery} \rightarrow \text{Resolve or Escalate} $$

AI handles investigation and recommendations, while deterministic controls govern production actions.

Challenges we ran into

Our biggest challenge was balancing automation with safety.

An AI agent may identify the wrong root cause, recommend a risky action, or repeat a remediation without fixing the problem. We therefore designed AKAR to fail closed: when an action cannot be verified as safe, it is blocked or escalated for human review.

We also recognized that successful API responses do not guarantee application health. Recovery must be verified through workload state and live telemetry.

Finally, we focused on making AI recommendations explainable by connecting them to supporting evidence and operational context.

Accomplishments that we're proud of

We are proud of building the foundation for a closed-loop incident intelligence platform rather than a simple AI chatbot.

Our key accomplishments include: Evidence-backed RCA: Connects incident findings to infrastructure evidence and an investigation timeline. Safety-first automation: Separates AI reasoning from deterministic execution policies. Recovery verification: Checks actual workload health instead of relying on command success. Open-core approach: Makes the core investigation experience accessible while providing a path toward enterprise-grade automation.

The Community Edition is designed for self-hosted experimentation, while the Enterprise Edition targets production needs such as automated remediation, multi-cluster support, advanced access controls, and comprehensive auditing.

Our initial target market is startups and small-to-mid-sized digital companies with cloud-native infrastructure and lean DevOps/SRE teams. We plan to start with focused pilots and measure improvements in mean time to recovery (MTTR) before expanding adoption.

What we learned

Our biggest lesson is that AI-powered infrastructure automation is as much a safety and systems-engineering challenge as an AI challenge.

AI can accelerate evidence gathering and root-cause investigation, but production execution needs clear, deterministic boundaries.

This led to our core principle: AI proposes. Policy decides. Infrastructure verifies.

We also learned that recovery is a measurable system state, not merely a successful command result.

What's next for AKAR (Anomaly Knowledge & Automated Root-cause)

Our next step is to develop AKAR into a production-ready service continuity platform.

We plan to improve root-cause analysis using historical incidents, deployment changes, service topology, and operational knowledge. We also aim to expand the remediation registry, monitor services after recovery, and detect recurring incidents.

For enterprise adoption, we plan to explore multi-cluster operations, advanced RBAC and SSO, audit trails, compliance support, and on-premise or air-gapped deployments.

Our go-to-market strategy is to begin with targeted pilots, demonstrate measurable MTTR improvements, and build trust through explainable AI, human-approved remediation, and integration with existing infrastructure.

Ultimately, AKAR aims to bridge observability and action.

Traditional observability tells engineers that something is wrong. AKAR aims to help them understand what happened, why it happened, what can be done safely, and whether the system has truly recovered.