What your agents learn,
governed like code.
Cruxible is a governed state engine for AI agents. It produces a Crux: an executable artifact of your domain knowledge: typed, reviewed, versioned, and tested against outcomes.
Running a team? Join the Cruxible Cloud waitlist or talk to us.
Knowledge that verifies like code.
What agents learn usually lands in prose, and prose doesn’t execute. In a Crux it lands as typed claims that are reviewed, versioned, and checkable in seconds.
Decisions held to their outcomes.
A real decision meets its result long after the transcript that made it is gone. An outcome contract puts a check date on the record and writes back what reality said.
One state every agent works from.
Many agents reading the same documents produce many private versions of the truth. Accepted claims, rules, and procedures are one record, shared by every agent, session, and human.
Propose. Accept. Observe. Resolve.
Accepted state is a loop, not an archive. Judgment enters through review, reality reports back, outcomes come due on a clock, and the record moves by supersession.
Judgment enters as a proposal with evidence attached. Direct writes to governed claims are refused; review is the only door in.
Held at this step
- Direct writes to governed claims refuse
- Evidence refs must dereference to pinned source chunks
- The proposal records the workflow and receipt that staged it
# judgment enters as a proposal, evidence attached$ cruxible propose \--workflow propose_incident_impacts_supplier1 candidate staged for review
The full loop.
That claim's life sits in a longer arc, and there is no LLM inside the engine. Judgment enters only where you saw it (proposals, review, attestation); everything the engine itself does is deterministic, works with any agent or harness, and lands in a SQLite file you own.
01
Model the domain
Start from a ready-made domain kit, or hand your agent the authoring skills and review the YAML ontology it drafts.
02
Pin the sources
The exports, tables, and documents your truth comes from register as content-hashed artifacts that claims cite into.
03
Ingest the hard facts
Deterministic workflows match source rows into typed entities and edges, previewed before they commit.
04
Propose the judgment calls
Governed claim types refuse direct writes and enter as proposals, each carrying the evidence that matched it.
05
Review and mint
A human, or an agent under trust rules you declared, approves or rejects; everything ungoverned is live on write.
06
Ask, and act on the answer
Agents work through MCP or the CLI, under scoped credentials; queries return receipts, guards refuse rule-breaking writes, gates hold outside actions until state agrees.
07
Hold decisions to outcomes
A decision can open an outcome contract with a check date. When it comes due, what reality said is recorded against the claim that made the call.
08
Keep the actions that work
When an agent learns a way of acting that works, it can propose that too: a Procedure passes the same review cycle as a claim and runs only within its declared inputs, preconditions, and budgets.
The rules run.
Cruxible never asks a model to follow the rules, because the rules run as code. A rule declared in config runs at the write chokepoint on every mutation, and there is no code path around it. Guards face inward at the write boundary; gates face outward, holding external actions until state agrees.
“The agent knows an exposure can’t be closed while unremediated”
The write chokepoint refuses the transition until the remediation claim, with its evidence, is linked
“The model says these sources support the claim”
The write is refused unless every reference dereferences to a content-hash-verified source chunk
“The agent was told not to accept claims it proposed itself”
The guard compares the acting actor against the creation receipt’s recorded actor and refuses, including create-as-accepted
“The agent learned a reusable action sequence”
A Procedure may call only exported providers, within declared preconditions and budgets; independent acceptance pins it to the reviewed config, and every run leaves a receipt
Any domain you can type.
Kits are installable domains: the ontology, the governance, and the queries ship together. One command in, your agents work a governed model instead of a blank graph.
Incident blast radius over a governed BOM
Map suppliers, components, and recursive BOMs once. When an incident lands, blast radius is a traversal, not a research project. Feeds can only propose impacts, never write them.
Explore the kit →One truth, many writers.
Cruxible is built for many writers out of the box. Each writer holds its own minted credential at one of four cumulative permission tiers; give each agent the least tier that does its job. And everything they write is watchable in the open-source inspection console: the state graph, review queues, workflow traces, receipts.
Minted identity
Every writer, human or agent, acts under its own credential; every write is attributed to the actor that made it.
Roles separable by receipt
A guard can require that the creator of a record is never its approver, anchored on the creation receipt rather than anything a writer can forge.
One accepted state
Humans and agents sit in the same loops under the same rules, and every reader, whatever the agent, model, or session, computes the same answer.
Model the domain.
Don't engineer the context.
Retrieval is how agents discover. Cruxible is where what they establish gets compiled: a shared, executable artifact, accepted at a point in time, changed only through explicit lifecycle, read back with a receipt.
The cut test: which artifact properties does your use case need? If none beyond retrieval, use markdown.
Start local. Scale when ready.
Cruxible runs on your machine: the full engine, nothing held back. When your team outgrows a single daemon, Cruxible Cloud adds managed, isolated deployments you don't have to run.
Give your agents something
worth trusting.
pip install cruxible and model your first domain today, or join the Cruxible Cloud waitlist for managed, isolated deployments.