How long does changing a rule take?
If it's in the agent's code, a business change goes through a ticket, a release and a deploy, everywhere the agent acts from.
Zarel is the governed runtime for AI agents. Your agent's rules live in a contract, outside its code. Zarel checks every action that goes through it against that contract, outside the model. Your team edits the contract; if the contract says so, someone else approves the change; once it's published, the new version applies within seconds, with no deploy. Every state change that goes through it records the version that allowed it.
Done, it's recorded.
If the destination account changed recently, the back office verifies it first.
It couldn't be recorded: the destination account changed recently.
── refused · recent_destination_change ──AI agents went from answering to acting: they file requests, change records, move money. And they act under a business's rules, which change: a limit, a deadline, an exception, who has to approve. If your agent's are in its code, every change is a project. And when someone asks which rule applied the day it acted, you have to reconstruct it.
If it's in the agent's code, a business change goes through a ticket, a release and a deploy, everywhere the agent acts from.
When the code defines the limits, the same deploy that ships a feature can move them, and whoever answers for them can't read what changed.
Logs record what happened. Rarely which rule was checked, in which version, and who approved it.
Zarel answers all three from the runtime. Every chained event cites the contract version that decided it, and how that version went live: approved, by whom and in which role, or published without approval. zarel verify checks it offline. The record does not yet list, for every event, each rule it was checked against.
It's the fastest way, and enough for a pilot. You can build all of it in-house. The cost comes later: every change ships with a deploy, and only engineering can read what changed.
Quick to change. But a prompt asks the model to behave, and a filter checks what the model says, not what your system executes.
They version rules, approve them, and some already change them with no deploy. The price is thinking about your business in their process model, and adopting one tends to be a project of its own.
Outside the agent's code and outside the model, in a document that gets reviewed before it applies. What goes through Zarel, the model can't skip.
Before publishing, you see what it would have done to what already happened. If the contract says so, someone else approves it, and until then nothing changes. Then it takes effect without touching the agent's code.
When someone asks which rule applied, the answer comes from the record and doesn't have to be reconstructed. And someone outside can check it.
The model is an interface, not an executor. It does not execute a call, mutate state, or decide an outcome; where a contract allows chained actions, the model proposes the sequence and each step clears the same gates.
A typed intent rather than free-form text or a tool call, validated against a schema before anything deterministic runs. Output from the model enters as untrusted data.
A declarative contract holds the data model, roles, permissions, state transitions, bindings and checks in one reviewable artifact. Risk and compliance read and approve the contract, and never need to read the codebase.
State transitions and flow steps are hash-chained and checkpoints are signed. Verification runs offline, against the exported bundle, with no call back to Zarel.
After a fraud, compliance decides: if an account’s withdrawal destination changed recently, no request goes through until the back office has verified it, and how many days depends on the account’s policy. That is new data and new logic, in the contract, with no code to change and no deploy.
A policy with its hold in days, and when each destination changed and was verified. Nothing changes for anyone while the back office fills them in.
In our demo, 2 of 5 past requests would now be refused by that rule and 3 wouldn’t change. What it can’t judge it says, instead of counting it as unchanged. It judges your rules over what happened, not what the model would have done.
Until then nothing changes, and the approver is told how many accounts the rule can’t apply to yet because they hold no value for it.
The same request is now refused, and the record names the rule and the version. Once the back office verifies the change, it goes through. Shortening the hold is an edit to a record, not a new version. Zarel records the request; it moves no money in this demo.
Run on 3 November 2026 on a demo contract in a local stack, by the API and the zarel CLI.
Hash-chained events with Ed25519-signed checkpoints. Altering any event a signed checkpoint covers is detectable at the exact sequence number where the chain breaks. It detects tampering; it does not prevent it.
Where the contract declares a binding, a bound value comes from authoritative state and the model's version is discarded; an asserted one is refused if it breaks a rule over state the model cannot set. The model still reads and proposes.
The surface that changes the rules and the surface that executes under them are distinct, with tenant isolation enforced by row-level security at the database and separate Postgres roles.
Real output of the zarel CLI, run on 19 October 2026 on a demo tenant in a local development deployment. One person proposed the contract version and another approved it. For the second run, event 26 was changed and re-signed with the deployment's bundle key. The verifier runs with no network access.
Zarel is the layer between what your AI proposes and what your systems execute. Most of what you already run stays.
Composes the agent and orchestrates the conversation. Zarel governs what that agent is permitted to execute.
Keeps long-running workflows alive across failures. Zarel enforces the contract that determines which steps are allowed to proceed.
This is the overlap. If your process definitions already encode who may do what, Zarel is an alternative, one built for probabilistic callers.
Customer-controlled. Bring your own key, choose your region, keep your existing contract with the provider.
It shows most where a wrong action is expensive: it touches money, customer data or an obligation to someone else.
An agent that's usually right isn't enough when the rule it has to follow just changed.
A regulator, an auditor or your customer's customer. What can be verified comes as a consequence of every change.
What Zarel does not do yet, and where each guarantee stops.
It covers what goes through Zarel. Anything the agent can do some other way, it doesn't judge.
Someone still edits a contract. Changing a rule takes no deploy, but someone writes it and publishes it; today, in a file and a terminal.
Tamper-evidence, not tamper-prevention. The record makes altering any event a signed checkpoint covers detectable. It does not make alteration impossible, and the events since the last hourly checkpoint are not attested yet.
Approval is what the contract declares. Approval applies when the contract declares approvers. Without them a version goes live when it is published, and the record says who published it and that no one approved it. With one approver, the record says they approved alone.
Offline verification applies everywhere; trustlessness has a scope. Verifying a bundle without contacting us works on any deployment. Verifying without trusting the operator requires a customer-operated deployment where you hold the signing key.
What is deterministic, and what is not. Every check the contract declares (field rules, permissions, state transitions, bindings, confirmations) returns the same verdict for the same input. The sequence of actions is fixed only in the flows the contract declares; elsewhere the model proposes it, and each step is checked. The topic check can consult a classifier.
Production-oriented architecture, not certified. No SOC 2 report, ISO 27001 certification, PCI DSS attestation or HIPAA assessment to date. The architecture is designed toward those controls; it has not been audited against them.
Channels today. Zarel Desk runs on the web. WhatsApp is on the way, not shipped.
The Design Partner Program is opening. We are not claiming deployments or references we don't have.
We're talking with teams that already have an agent acting on its own, to understand what changing a rule costs them. If that's you, write to us.