When an agent decides about someone's money, you can show what it did, step by step, as it happened.
If an agent can't show its work, every decision it makes is one you'll have to explain from memory.
Autonomous agents already decide who gets an account, who gets credit, and which payment goes out the door. Six months later a regulator, an auditor or a customer with a complaint will ask what the agent saw, what it decided and which person handled the exception, and whether your account of events can be trusted.
Press play on a sample bank workflow, simulated in your browser. Each agent action becomes a record as it happens. Each record is linked to the one before it by a hash, which is a digital fingerprint. At the end the chain is signed, so anyone can check it.
Simulated agents on fictional case data. The checks on screen (SHA-256 linking, Merkle root, offline verification) are the ones Coriqo runs in production.
Three sample cases where an agent decides about a customer's money.
Capture, chain, verify: three steps, in that order.
When one case is questioned, your team can show each step the agent took and the person it escalated to, instead of rebuilding the story from logs. That works because nothing is summarised after the fact. The record is written at the moment the agent acts, which is the only moment the evidence is still complete. Keep that record for every agent in production and you have a control tower over agent decisions, built on the evidence itself rather than a summary dashboard.
Written at the moment of decision
Each agent step is recorded as it happens, with its inputs and who or what acted. That includes the tool it called, the score it got, the threshold it crossed and the person it escalated to. Reconstructing this from logs a quarter later leaves an organization with an explanation instead of evidence.
Each record hashed onto the last
Every block carries the SHA-256 of the block before it. Edit any earlier step, such as softening a risk score or deleting an override, and every hash after it changes. No reviewer has to spot the tampering. The hashes simply stop matching.
Checkable without trusting us
At the end, the chain produces a Merkle root (one fingerprint for the whole chain) and an Ed25519 signature. Your examiner recomputes both offline, using a public key and an export they hold. Coriqo is not in the trust path, and that is the point.
What the examiner runs, on their own machine.
An examiner shouldn't have to take our word, or yours, that the record is intact. The seal at the end of the run is a Merkle root over the chain plus a separate signature, exported as JSON. Anyone holding that export and the public key can check it without an account, without network access, and without asking us anything.
Note: record counts and the anchor index above are from the demo case. Chain, Merkle and signature verification are implemented in the Coriqo codebase today; public anchoring degrades to “pending, retry” without outbound network access.
No approved mandate, and your CI job fails the build.
Add one job to your release pipeline, ahead of the deploy step. It runs coriqo-agents mandate check, which asks Coriqo whether the agent may go live. If the agent is suspended, has no written mandate, or runs under a mandate no named person approved, the job fails and your pipeline stops the release. Give it the mandate file from your repository and that file must match the approved one Coriqo holds, so nobody can change it without a new approval.
The release goes ahead
The agent is active, its mandate is written and approved by a named person, and the file in your repository matches it.
The job fails and says why
Each failed check is named in the log, with a link to the agent's page in Coriqo where someone can fix it.
The job fails here too
Missing settings, a bad key or no network. An outage is never read as a pass, so an unchecked agent can't ship while Coriqo is out of reach.
GitHub and GitLab: ready-made jobs for GitHub Actions and GitLab CI come with the SDK. Copy one in front of your deploy job, keep the API key in a CI secret, and make the deploy depend on it. Coriqo answers the question; your pipeline is what stops the release.
Note: output shortened; the real lines also say how to fix each failure. The check covers agents and their mandates. It does not yet check model approvals or validation dates. The same answer shows on the agent's page before you release.
If you are putting agents anywhere near onboarding, credit, or payments, the useful conversation is about your actual chain: which steps you would capture, who signs off on an exception, and what an examiner would be handed twelve months from now.
We are working with a small number of design partners on exactly that. Bring a workflow and we will map it.