TRIAGRE

AI agents diagnose production outages like a senior SRE — investigating logs, metrics & dependencies, then proposing a fix with evidence, in minutes instead of hours. Built with GPT-5.6 + Codex.

Comment

Inspiration

On-call engineers lose the first 20–30 minutes of every incident just figuring out what's broken — digging through logs, dashboards, and service maps before they can even start fixing anything. We wanted to build something that compresses that window: an AI that investigates an outage the way a senior SRE would, not just answers a support ticket.

What it does

Incident Commander runs a 4-stage pipeline of specialized AI agents — Triage → Diagnosis → Fix → Postmortem — each one handing its findings to the next. The agents don't just guess: they call real tools (log search, metric queries, service dependency mapping, runbook search, and live host metrics) to gather evidence, the same way a human investigator would. Every conclusion comes with a confidence score and a visible evidence chain, so the engineer can see why the AI reached its diagnosis, not just trust a black box.

How we built it

The backend is FastAPI with a WebSocket layer that streams each agent's progress to the frontend in real time. Each agent runs a genuine OpenAI function-calling loop on GPT-5.6 — deciding which tool to call, reading the result, and reasoning over it before concluding. Structured outputs (strict JSON schemas) keep every stage's result typed and predictable instead of free-form text.

Codex was our development partner throughout: it helped implement the multi-agent pipeline and tool-calling loop, caught and fixed an XSS vulnerability in how the frontend rendered model output, added a live host-metrics tool (real CPU/memory data via psutil) so at least one data source in the demo is genuinely live rather than simulated, and helped tighten our documentation and demo flow for reliability.

Challenges we ran into

Getting context-chaining right between agents was the hardest part — the Diagnosis agent needs the Triage agent's findings to know which services to investigate, and the Fix agent needs both. We had to carefully design each agent's output schema so it was exactly what the next agent needed as input. We also had to make sure the frontend degrades gracefully — it has a built-in offline demo mode so the experience never breaks even if the backend or API is unavailable.

What we learned

Multi-agent systems are only as good as the evidence they're grounded in — a single prompt guessing at a root cause is very different from an agent that actually searched the logs and can show its work. We also learned how much a small amount of real data (like live host metrics) does for credibility compared to an entirely simulated demo.

What's next

Swapping the mock log/metric tools for real integrations (Datadog, Prometheus, PagerDuty), adding a human-approval step before any suggested remediation command can be run, and expanding the tool set so the Diagnosis agent can correlate evidence across services by timestamp automatically.

Built With

  • agentic-ai
  • ai-agents
  • asyncio
  • codex
  • css3
  • devops
  • fastapi
  • function-calling
  • gpt-5.6
  • html5
  • incident-response
  • javascript
  • llm
  • multi-agent-systems
  • openai
  • psutil
  • pydantic
  • python
  • rest-api
  • sqlite
  • sre
  • uvicorn
  • websocket
Share this project:

Updates