Meridian Ops
$0.056 for one closed incident, 15 events end to end, on the ledger. Running unattended since August.
Portfolio AI demos sit dead until a visitor presses run. This one was already working when you arrived: every event is appended to an event-sourced SQLite log with per-call token cost, the monitors have real uptime history on my real sites, and the system has already caught real problems, including a misconfigured canary check that it escalated to P2 on its own after the skeptic cited the client's profile. A daily budget cap pauses the operation honestly instead of degrading it silently. The triage stage also runs re-platformed on Azure Functions with Azure OpenAI, same gates ported, as a sibling repo.
Two requirements that pull against each other. It had to be already working when a stranger arrives, which means running unattended around the clock on real infrastructure. And it had to be safe to point at my actual deployed sites, which means an agent fleet with opinions about incidents on systems I cannot afford to have it break. Everything else follows from holding both at once.
Me, as the operator, and any visitor who wants to fire a lab incident and sit in the commander seat for their own run.
Hiring teams asking whether agent autonomy and governance can coexist in one system.
- Incidents arrive three waysA visitor fires a lab ticket, the scheduler invents one with realistic texture, or a production monitor opens one after three consecutive failed checks on a real site.
- The fleet works itTriage classifies with a confidence score, runbook drafts concrete steps for that client's constraints, comms writes the client update, and the skeptic attacks all three against the client profile before anything advances.
- Gates run in codeSecurity floor, close-season floors, comms bans, confidence floor, and the skeptic's raise-only rule. The model proposes; code decides.
- A human approves, anywhereThe run parks at the commander gate and appears on the web board, as a monday.com item, and as a Discord embed with an approve button. All three call the same function.
- Approval leaves receiptsA real email goes out via Resend, a ledger row lands with the run's exact token cost, and every surface flips to closed on its own.
- Production stays untouchableFor real sites the fleet notifies and drafts only. Execution against production is not wired, by design.
The skeptic can only raise severity. Never lower it. That sounds like a small rule and it is the one that makes the fleet trustworthy: a reviewer that can argue a P1 down to a P3 is a reviewer that will eventually be talked into it by a confident draft, and the failure is silent. Raise-only means the worst case is a human reading a ticket that turned out to be smaller than flagged, which costs a minute. The same logic drove the production book: the fleet can notify and draft against my real sites but cannot execute, so the blast radius of a wrong call is a message, not an outage. Deliberately less capable, in the two places where capability is the risk.
The monitor debounce state started in memory and lost open-incident context on every restart. It moved to SQLite, but I would start event-sourced for operational state too, not just run history. The skeptic would also get its own eval suite from day one: meridian-evals proved that gate logic drifts when three implementations share a regex by copy-paste.