FleetMind

Inspiration

I've been on enough 2 AM incident bridges to know the real problem isn't fixing the system, it's the coordination tax on top of it. Someone has to assess severity, page the right people, write the internal Slack update, draft the exec summary, keep the customer status page honest, and eventually write a post-mortem that doesn't just say "human error." All of that happens while the actual outage is still burning. I wanted to build the tool that takes that overhead off the engineer and lets them focus entirely on restoration.

What I built

FleetMind is a multi-tenant incident command platform with five specialized AI agents running in a coordinated pipeline:

1. Triage agent — classifies severity (SEV1–4), blast radius, and affected services from the raw signal
2. Coordinator agent — assigns commander, resolver, and comms lead from your team roster based on expertise and on-call status
3. Runbook agent — matches the incident to an existing runbook or generates a scoped one if confidence is below threshold
4. Comms agent — drafts three stakeholder tiers in one shot: internal engineering, executive summary, and customer-facing status
5. Post-mortem agent — fires on resolve, producing a structured draft with root cause, contributing factors, timeline, and action items

The war room is live-streamed via SSE — every AI action, timeline update, and team assignment appears in real time without a page refresh. A one-click simulation engine lets you fire realistic outage scenarios (payment degradation, DB pool exhaustion, CDN outage) to demo or stress-test the pipeline.

How I built it

• Next.js 15 App Router on Vercel, scaffolded with v0, the dark mission-control UI came together fast using v0's component generation
• Aurora DSQL as the primary relational store for incidents, timeline events, assignments, runbooks, and post-mortems, chosen specifically because it's a serverless distributed SQL database that stays available even when the system it's monitoring is on fire. Every query is org-scoped for strict multi-tenant isolation
• DynamoDB for the high-velocity layer: incoming alert signals, deduplication (conditional writes with a 1h TTL window to collapse noisy alert storms), and session presence tracking for war room viewers
• Claude Sonnet via the Anthropic API for all five agents, with Zod-validated structured output and template fallbacks so a bad AI response never crashes the pipeline
• Clerk for authentication and multi-org management, each workspace gets its own isolated data context
• SSE on Vercel Edge for the live war room stream, polling DSQL every 500ms and pushing diffs to connected clients

Challenges

The hardest part was the dual-database data model. Deciding what lives in DSQL versus DynamoDB required a clear contract: DSQL owns anything relational or auditable (incidents, timelines, post-mortems), DynamoDB owns anything high-frequency or ephemeral (raw signals, dedup locks, session presence). Getting the dedup logic right, using DynamoDB conditional writes to collapse 50 rapid-fire alerts into one incident, took more iteration than I expected.

The second challenge was the AI pipeline reliability. Claude's structured output is good but not perfect, and an incident tool cannot crash because an LLM returned malformed JSON. Every agent call has a Zod parse step with a hardcoded fallback template, so the worst case is a slightly generic response rather than a 500 error while your production is down.

SSE stability on Vercel Edge was the third, streaming connections behave differently at the edge than in a local Node server, and I had to tune the reconnect backoff and heartbeat to keep the war room reliable under the 60s edge timeout.

Built With

• anthropic-claude-sonnet
• aws-aurora-dsql
• aws-dynamodb
• clerk
• next.js
• prisma
• server-sent-events-(sse)
• tailwind-css
• typescript
• v0.app
• vercel
• zod