You wired five tools into your agent and it worked beautifully. So you added more. Twenty. Forty. Somewhere in there it got slower, it started reaching for the wrong tool, and the bill crept up — and you couldn’t point at the line that caused it.
That’s not a prompt you can fix. It’s a structural cost, and it’s the reason this project exists.
Two problems hiding in plain sight
Every tool you register does two things you never asked for.
First, its definition — the name, the description, the JSON schema — gets loaded into the model’s context on every single call. Five tools is nothing. Fifty is thousands of tokens spent before the model has a single thought. You pay that on every turn, every retry, for the whole conversation.
Second, none of it comes with guardrails. A flat list of tools trusts the model to behave — the agent that approves its own change, runs the migration before the tests, deploys before CI is green: none of that is constrained. No audit trail. No approval gate. No retry policy. A flat list and a prayer.
Here’s the part that stings: both problems get worse the more useful your agent becomes. The teams hitting them hardest are the ones doing the most ambitious work.
The bet
Praxec makes one bet: the model should never see your tool list.
No matter how many capabilities you wire in — five, fifty, five hundred — the model sees exactly two tools: praxec.query for every read and praxec.command for every write. That’s the entire surface. Which operation runs is determined by the arguments you pass, not by a distinct tool name. Every response hands back the legal next moves as pre-filled { method, args } link objects the model copies verbatim. It follows links instead of scanning a menu.
The second half of the bet: governance should be something you declare, not something you code. Turn a plain capability into an approval gate by giving a transition actor: human and a human executor — the model gets no path around the gate, not because you wrote a defensive check inside the tool, but because you declared a rule the kernel enforces.
Start flat, add governance later
You don’t have to design a state machine on day one. A flat list of tools — “proxy mode” — is just the trivial case: one state, every tool looping back to it. So you start ungoverned. When one tool — the deploy, the refund, the user-delete — needs rules, you wrap that one in a workflow with real states and guards. Nothing else changes, and the model’s surface stays at two tools.
What’s actually built today
This is an early project, so let me be precise. What works now: the two-tool surface; capabilities wired to MCP servers, CLI commands, and REST APIs; guards that gate on permission, role, a small expression language, or recorded evidence; JSON Schema validation before any executor; retries with backoff, fallback executors, and idempotency keys; deterministic chaining; a structured audit event for every meaningful step; and a persistent SQLite store for state that survives a restart.
What I won’t claim: there are no published case studies yet, and permission/role guards assume a deployment with real identity wiring — the bundled binary treats every caller as anonymous, which is the right default for one developer on a laptop but is not a security boundary. The docs say all of this plainly. So will this blog.
Every post here is grounded in the actual tool — real config, real output on the wire, real numbers. If a claim isn’t traceable to something you can run, it doesn’t go in.