It's 3am. Your phone lights up with a page you've seen four times this quarter. You know the fix. You've documented the fix. And yet here you are, half-awake, SSH-ing into a box to run the same three commands you ran last month, because the runbook doesn't run itself and nobody trusts it to.
That gap — between an incident being understood and being resolved — is where PRAXIS lives.
The problem: solved incidents that still wake you up
Most on-call pain isn't novel failure. It's recurring, already-diagnosed failure. The knowledge exists; it just lives in a wiki page, a Slack thread, or one senior engineer's head. So the org pays for it twice: once to figure it out, and forever after in interrupted sleep.
The obvious answer is "automate the remediation." The obvious reason nobody does is fear. Silent auto-remediation is a great idea right up until it confidently runs the wrong DROP, reports success it never verified, and turns a five-minute blip into a postmortem. The cost of a wrong automated action is asymmetric — one bad write can outweigh a hundred correct ones.
So the real design question isn't "can a model fix this?" It's "how do we let a model do the tedious bulk of the work while keeping a human firmly in front of anything that changes state?"
The core idea: an autopilot with a hard approval gate
PRAXIS is an alert-to-remediation autopilot with a mandatory human-in-the-loop approval gate. The word "autopilot" is deliberate: it flies the plane, but a human still has the controls for anything irreversible.
Here's the full flow:
- A signed operational alert arrives.
- Qwen models classify it and reason about root cause.
- PRAXIS gathers read-only evidence — logs, state, context — never touching anything that mutates.
- It drafts a risk-labelled remediation plan.
- It stops. Nothing state-changing happens until a human approves the exact plan.
- On approval, it executes the approved actions against an isolated target.
- Every step lands in an auditable decision trail.
- Resolved incidents become reusable incident memory for next time.
The interesting engineering isn't the "AI reasons about an alert" part — plenty of things do that. It's steps 5 through 7: making the stop unskippable, and making execution honest about what it did and didn't do.
The design: fail-closed, or don't move at all
AWAITING_APPROVAL is the only door into EXECUTING
PRAXIS is built as a fail-closed state machine. The property I care about most is structural, not procedural: there is exactly one transition into the EXECUTING state, and it originates from AWAITING_APPROVAL. There's no side door. No "high-confidence" bypass. No config flag that quietly flips it to autonomous. If a plan hasn't been explicitly approved by a human, no state-changing tool runs. Full stop.
This matters because "we prompt the model to always ask first" is not a safety property — it's a suggestion the model can wander away from. Making approval the only topological path into execution means the guarantee holds even if the reasoning layer misbehaves. The safety lives in the state graph, not in the vibes of a system prompt.
Reconciliation under uncertainty
Distributed systems don't have the courtesy of clean failures. Sometimes you fire an action and never learn whether it landed — the connection drops, the response is ambiguous, the target goes dark mid-call. Naive automation handles this in one of two catastrophic ways: it assumes success (and lies to you), or it blindly retries (and double-applies).
PRAXIS does neither. Before dispatching any real action, it records a durable pre-dispatch intent — a written-down "I am about to do X." If the outcome of that action can't be verified afterward, the incident doesn't get marked resolved and it doesn't get retried. It moves to a terminal RECONCILIATION_REQUIRED state and waits for a human.
The design stance is blunt: it would rather stop and admit uncertainty than report a false success. An incident parked in RECONCILIATION_REQUIRED is a human getting an honest "I'm not sure what happened here, come look" — which is exactly the message you want at 3am, and exactly the one silent automation refuses to send.
The approved plan is the plan that runs
The approval gate is only meaningful if the thing being approved is the thing that runs. A human approves the exact plan — a concrete, bounded set of actions — not a vague intention the executor is free to reinterpret. The blast radius is deliberately tiny: the one real write adapter only restarts an isolated, disposable Function Compute demo target. Every caution- or dangerous-tier tool is a visibly labelled dry-run. You can watch it reason about a scary action without it ever being able to take one.
The stack
The runtime is Qwen-only, served from Qwen Cloud (Alibaba's Model Studio):
-
Reasoning:
qwen3.7-max, with a same-Qwen OpenRouter fallback for availability. -
Classification:
qwen-flash— cheap and fast for the high-volume triage step. -
Memory embeddings:
text-embedding-v4(1024-dim).
It runs on Alibaba Cloud Function Compute 3.0, and semantic incident memory lives in Alibaba Cloud Tablestore vector search. Resolved incidents get embedded and stored so a future recurrence can pull up how the last one went — recall grounded in your own history, not a generic model prior.
A note on how it was built
PRAXIS was built with AI coding agents — primarily OpenAI Codex running GPT-5.6 as the development agent. That's worth stating precisely, because it's easy to garble: Codex and GPT-5.6 are build-time tooling only. They wrote and refactored code; they do not run inside the product. The PRAXIS runtime is Qwen-only. Nothing in the live incident path touches an OpenAI model. Keeping that boundary crisp matters as much for honesty as for architecture — the thing that reasons about your incidents and the thing that helped write the reasoner are two different systems.
Honest limitations
I'd rather undersell this than have you discover the gaps yourself.
- Memory isn't proven end-to-end live yet. The write-and-recall path is implemented and tested — but a fresh approved resolution writing a memory row and a genuinely distinct later recurrence recalling it, proven live in one continuous run, is not yet demonstrated. "Implemented and tested," not "proven in production."
- It's a single-operator demo. Incidents are process-local, not cross-instance durable. This is not multi-tenant, and it's not making production-grade durability claims. It's an honest demonstration of a safety architecture, not a fleet-ready SaaS.
Neither of these undercuts the point PRAXIS is trying to make. The point is the shape of safe automation — the gate, the reconciliation, the audit trail — and that shape is real and running.
Try it / read the code
There's a live, public, read-only demo — no login required. Open it and watch incidents flow through the state machine in real time. You can see everything; only the maintainer's operator token can approve anything, so the approval gate stays intact even for you.
- Live demo: https://praxis.kopachelli.dev
- Source (Apache-2.0): https://github.com/Kopachelli/praxis
The repo ships with a README and 859 passing automated tests. If you've ever wanted auto-remediation but couldn't stomach handing a model the keys to production, the interesting bit here is exactly the part that refuses to let it drive alone.
Top comments (0)