Praxis
A personal AI operating platform — server, web and Wear OS, self-hosted
Praxis is mine. It is not a product, it is not for sale, and it is not running in anyone’s dealership. It is the system I run my own day on, and it is where I work out how an AI agent can be given real authority safely — long before that pattern goes anywhere near a business. Mail, calendar, tasks and knowledge come in, it reasons about what actually matters, and inside authority I granted in advance, it acts. It runs entirely on hardware I own — a purpose-built engineering workstation — reachable only over a private tailnet.
It is also, by a clear margin, the largest thing I have built — roughly two and a half times the codebase of Garage.
The Engineer execution plane
Praxis could already reason about software work. It could not do any of it — every Agent Room specialist runs with no filesystem, no shell and no git, deliberately. The Engineer plane is the governed layer that lets me say, from my phone:
Diagnose the problem, implement the correction, run all the tests, have the reviewer look at it, fix anything material, commit it, and deploy it.
— and have real work happen on the workstation while I am standing on a service drive.
- The boundary is enforced, not requestedPrompt text asking an agent to stay in a directory is not isolation. Every agent process is spawned with settings sources disabled — so a repo-controlled settings file, which is attacker-controlled in the threat model, is never read — plus MCP servers off, slash commands off, an explicit tool allowlist, and a PreToolUse guard hook as the actual capability boundary.
- Verified, not assumedThat isolation behavior was tested empirically against the installed CLI before the design was built on top of it, rather than taken on faith from documentation.
- Every run is isolated and durableA fresh git worktree per run, one job claimed at a time under a heartbeated lease, an immutable mission-authorization snapshot, and stage events streamed back into durable tables — so a run survives a restart and can be replayed.
- No shellProcesses are spawned with an argv array and a sanitized environment. There is no shell string to inject into.
Agent Room
Six named specialists — a chief of staff who breaks down an objective and picks the team, plus calendar, inbox and communications, research and two more — addressable in five modes: Direct, Delegate, Compare, Review and Council. Work moves through visible states, survives a restart, and can be cancelled or safely retried. No specialist touches the outside world directly; every external action routes through the approval engine below.
Program 5C — the safe action engine
This is the authority boundary between a recommendation and a real mutation, and it is the piece of my work I would put in front of the hardest reviewer you have.
| Tier | Rule | Examples |
|---|---|---|
| READ_ONLY | No action request needed. Authenticated query APIs stay read-only. | Context and search queries |
| INTERNAL_LOW_RISK | A deterministic policy approval is stored. No human needed unless the action promotes or suppresses durable knowledge. | Complete or defer a task; handle, dismiss or snooze an intelligence item |
| EXTERNAL_REVERSIBLE | Exact human approval required, bound to the snapshot hash. | Create a Gmail draft or draft reply |
| EXTERNAL_HIGH_IMPACT | Exact human approval required, and an ambiguous outcome is never blindly retried. | Send mail; update, decline or cancel a calendar event |
| PROHIBITED | Rejected before an action request is even created. Not a guardrail — an absence of capability. | Money transfer, bill payment, destructive account action |
- Approval is bound to exact contentAction snapshots are append-only and carry a canonical SHA-256 hash. An approval is bound to one snapshot ID and that hash — so an action a human approved cannot quietly become a different action before it executes.
- The model cannot grant itself authorityAn LLM cannot submit or override the authority tier, whether approval is required, the policy rule, the execution capability, or who approved. The caller supplies an action type; a versioned deterministic policy decides everything else.
- Some things are simply unavailableA prohibited tier — money transfer, bill payment, destructive account actions — is rejected before an action request is even created. Money never moves autonomously, by construction rather than by prompt.
- Exactly once, or visibly not at allDurable idempotency keys carry request hashes; reusing a key with different content is rejected. Execution is claimed under a lease, and an ambiguous outcome on a high-impact action is never blindly retried.
- The audit trail cannot be editedDatabase triggers reject updates and deletes on snapshots, approvals and events. Sensitive content stays inside the authenticated snapshot rather than being copied into audit rows.
Knowing what not to build
The notification engine is specified in full — durable-first creation, no silent drops, at-least-once delivery with deduplication, loud failure, a dead-man's switch for the case where Praxis itself is the only thing still notifying me — and then marked, at the top of the document, requirements only, not authorized for implementation, because the security roadmap outranks it.
Writing a design that good and then not starting it is a harder decision than building it, and it is the one I would point to if you asked whether I can be trusted with a roadmap.
