Open source, MCP and A2A
Independent, deterministic verification for AI agent actions.
The agent proposes the action. Joltrin checks it against the recorded trace and fixed preconditions before it commits. It does not use the agent's claims, its context, or its confidence.
A claim that something happened is not evidence that it happened.
The order is enforced by the barrier, whatever the agent says it already did.
The engine compiled to WebAssembly. Run ACID transactions, vector search, a benchmark, and an agent checkpoint resume, all in your browser.
A cluster simulation. Add workers, crash storage nodes, and spike load to see the concepts behind the engine. It illustrates the design, it is not a live cluster.
The same verify barrier that gates the MCP and A2A servers. Try to drop a database before the backup is validated and watch it refuse.
The agent and the verifier are separate.
An agent that proposes an action and also judges it safe can be wrong in both places for the same reason. Joltrin keeps the two apart. The agent emits intent. The check runs outside the agent's context window, against the steps the server has actually recorded and the runbook's rules.
A step is blocked until the states it needs have been established in the run's trace. What the agent claims does not count. A backup must be validated before a drop.
A rule can forbid reaching a state unless another state already holds, for example no database drop without a validated backup.
When a runbook is registered, it is checked that rollback can still be reached from every state. A runbook that can dead-end is refused.
verify runbook gating MCP and A2A agents. Try dropping a database before taking a backup.
Any agent that supports MCP can use the barrier. This downloads a binary of about 6 MB, checks its checksum, and registers it with Claude Code, Codex, and the Gemini CLI, whichever are installed. No Go needed.
curl -fsSL https://raw.githubusercontent.com/SharedCode/joltrin/master/scripts/install.sh | sh
Then ask it: "Use the joltrin tools to run drop_prod_db on workflow db-maintenance with trace id t1." The server refuses until take_backup and validate_backup have run in that trace, whatever the agent claims. Recorded runs with real agents.
A block tells the agent what to do next.
A blocked call is a normal result, not an exception or an opaque error. It says what is missing and which recorded step would establish it, so the agent can replan instead of retrying the same call.
{
"blocked_by": "precondition",
"missing_state": "backup_validated",
"established_by_steps": ["validate_backup"],
"attempts": 1,
"next": "run_established_by_steps"
}
blocked_by names the rule that stopped the step. missing_state is what has not been established in this run. established_by_steps lists the steps that would establish it.
Read it as a replan signal. attempts counts how often the same step was blocked for the same reason in this run, and next says whether to run those steps or stop and ask. Retrying the same call with different parameters will not change the answer.
With memory turned on, the server also counts, per rule, how many runs it blocked and how many of those went on to commit the step. That shows whether a rule is catching bad plans or is set too strict. It is a count, not an analytics product.
Agents hand off work. The barrier checks every call.
Jira, Grafana, AWS, and PagerDuty agents hand off work. Every call passes three checks first: the tool is on that agent's allowlist, any claim matches evidence a tool returned, and the steps it depends on have committed.
Replays the output of go run ./examples/agent_team. The tools are stubs and the checks are real. A result: line is what an agent gets back when a step is blocked on order: the rule, the missing state, and the steps that would establish it.
A block is feedback, not a dead end
When the barrier blocks a step, the agent gets back which rule tripped, the state that is missing, and the steps that would establish it. It can correct course from the block itself instead of guessing or retrying.
In our runs, Claude agents that were allowed to fix the problem used those fields to take the missing steps and finish, with no identical blocked call repeated. It is a small sample, so the prompts, models, and transcripts are written up in full.
Read the agent test results
What is real, what is simulated, what it does not do.
Real
The checks. The same verify package serves the MCP and A2A servers and compiles to WebAssembly for the live demo, and the repository has tests for it. A recorded run with real agents covers one runbook over MCP.
Simulated
The tools. In the team demo, Jira, Grafana, AWS and PagerDuty are stubs, and the Arena is an illustration, not a cluster. The demos show the checks, not live systems.
Not covered
The barrier only answers, so whatever performs the real action must wait for it. It cannot see what the trace does not contain: a backup in another cloud account has to be represented by a step you trust, such as one that checks that account and then records the result. It does not judge whether an agent's own claim is true.
No production deployments, customers or third-party benchmarks are claimed. A dry-run mode, where blocked calls are logged and allowed so teams can tune rules first, is a possible direction and is not implemented. Test results and their limits
Durable state underneath.
When an agent's process restarts, a network connection drops, or a container gets evicted, whatever it was holding in memory is gone. Joltrin gives it durable state, transactional checkpoints, and a deterministic way to recover.
Survives Failures & Reboots
State is persisted directly to local copy-on-write B-Trees or clustered storage with zero dependency on ephemeral cache processes.
Atomic Multi-Step Commits
Record intermediate reasoning steps atomically. If an agent fails on step 8 of 10, resume from step 7 without restarting the full workflow.
Deterministic Crash Recovery
Strict two-phase commit (2PC) ACID guarantees allow rolling back partially executed state mutations cleanly when unexpected exceptions occur.
Integrated Cosine Embeddings
Recall relevant past agent episodes and facts via high-dimensional vector cosine distance indexed directly in the storage engine.
Zero Server Roundtrips
Runs natively inside your application binary or in-browser via OPFS (Origin Private File System), so reads do not cross a network.
Booting Embedded Go WASM Kernel
Compiling B-Tree transaction log, vector index, and ACID isolation manager into browser memory sandbox...
Under the Hood: High-Performance Embedded Engine
Joltrin isn't just a thin wrapper around an LLM. Underneath the agent layer is a real storage engine: copy-on-write B-trees, write-ahead logging, strict two-phase-commit ACID transactions, and Reed-Solomon erasure coding, compiled to native Go and to WebAssembly so it can run in the browser too.
In-Memory B-Tree Financial Ledger
Real-time balances stored in local B-Tree nodes.
Execute ACID Scenario
Browser WAL & Execution Log
Open core, paid governance
The engine, vector search, agent memory, and the verification barrier are MIT licensed and stay free. Paid plans add team governance on top.
Open source
- Embedded ACID B-Tree engine
- Durable agent memory and vector search
- Verification barrier, MCP and A2A servers
- Community support on GitHub
Pro
- Everything in open source
- Policy-as-code for the barrier
- Tamper-evident audit lineage
- Team workspaces and quotas
We confirm by email. Self-serve checkout opens when billing is switched on for this site.
Enterprise
- Everything in Pro
- Okta and Microsoft Entra ID sign-in
- Custom CEL policy rules
- Compliance audit exports
Hosted Joltrin Cloud is planned and not available yet. .
Tell Us What You're Building
A few details about your agents and what you need, and we'll follow up personally.