Three-agent autonomous incident detection, investigation and resolution system.
For internal brainstorming — AgentsIQ Engineering, Internal Platforms.
Today, when an alert fires, multiple engineers are pulled in to triage, investigate, and fix — often spending hours on incidents that follow known patterns. This pipeline automates that entire chain, reserving human attention for genuinely novel problems.
Reads alerts from OpsGenie / JSM and classifies them before any human sees them.
Receives genuine alerts and investigates to find the root cause.
Receives RCA findings and takes remediation action.
All three agents read from and write to a shared RAG store. This is what makes the system improve over time rather than repeating the same work on every incident.
Over time, the Alert Analyser stops escalating known-noise patterns. The RCA Agent skips investigation for known root causes. The Action Agent builds a larger library of automated fixes. The system matures towards full autonomous incident response.
New Relic, Zabbix, LightStep, or another monitoring tool sends an alert to OpsGenie. OpsGenie records it.
On the next sync cycle, Alert Analyser reads new alerts from OpsGenie. It deduplicates (same alias = same incident), scores each alert, and classifies it. Noise goes nowhere. Suspect gets flagged for human review. Genuine alerts are enriched with inventory data and RAG context.
Alert Analyser passes enriched genuine alerts to RCA Agent. RCA checks the RAG first — if this pattern has been seen before, it applies the known root cause directly. Otherwise it investigates: pulling logs, checking dependent services, correlating with recent deployments. It produces a structured finding with recommended remediation actions.
RCA findings arrive at the Action Agent. It checks whether a Jenkins job exists for the recommended action. If yes, it triggers the job, watches the execution, and verifies the alert clears in OpsGenie. If no job is mapped, it creates a Jira ticket with the full RCA context attached so the on-call engineer has everything they need.
Regardless of whether the fix was automated or manual, the outcome is written to the shared RAG. Next time a similar alert fires, the whole chain is faster — Alert Analyser recognises the pattern, RCA skips investigation, Action Agent knows exactly which job to trigger.
| Area | Question |
|---|---|
| Alert Analyser → RCA | What is the exact data contract? Which fields does RCA need from Alert Analyser? |
| RCA Agent | Which data sources can RCA query autonomously? Logs, metrics, traces, deployment history? |
| Action Agent | How is the Jenkins job catalogue maintained? Who maps alert types to jobs? |
| Action Agent | What approval gates exist before automated actions execute on production? |
| RAG | How is the RAG structured? Per-service, per-alert-type, or a single global store? |
| RAG | How do we prevent bad fixes from being learned and re-applied? |
| Jira fallback | When a Jira is created and resolved manually, how does that fix get added to the Jenkins catalogue? |
| Governance | Which alert severities are allowed to trigger automated remediation without human approval? |
| Observability | How do we track agent decisions end-to-end for audit and debugging? |