What is Coco
A check that runs outside the agent and before the tool call, returns allow, block or escalate, and writes one row every time.
What is Coco
Coco is a check that runs outside the agent and before the tool call. The gate reads the behavioural contract you own, how far the case has got right now, and what this run already did, and it returns one of three answers.
| Verdict | What it means |
|---|---|
| ALLOW | No contract objected. The gate declines to interfere and the call proceeds |
| BLOCK | The call does not run, and the receipt names the check that stopped it |
| ESCALATE | A person answers this one, and the answer goes on the record |
No model runs at decision time. The same call against the same state and the same contracts returns the same verdict every time, which is the property that makes a receipt worth showing to a regulator.
What it is not
Coco holds no funds and no keys. It does not sign and it does not settle. It does not read the conversation, so nothing in the model's context can argue with a verdict. It is not a prompt, not a system message and not a markdown file the agent is asked to respect.
An instruction is a request the model can reason its way past when the context gets long or the case looks unusual. A hook is a return code.
The problem it solves
Banks and the vendors selling into them are putting agents into fraud, KYC and AML. Those rules are deterministic and agents are not. Nothing in that stack validates an action against the rules before it executes, or leaves evidence a regulator accepts afterwards.
The usual workaround is walling the agent off and running scripts, which removes the reason to have an agent at all.
Coco sits at the tool-call boundary instead. The agent keeps every tool it had, and each action is checked against a rule a compliance officer can read.
Why the sequence matters
A check with no memory judges every call alone, so a run of individually allowed calls is allowed. Reading a customer file is the work. Sending a summary out is the work. Doing the second after the first is exfiltration.
This is the structuring pattern that AML has known for fifty years. The individual transactions are each under the threshold and the pattern is the offence. Coco keeps session state in the ledger and evaluates the pair, and each half stays permitted on its own, which is what keeps the rule usable.
The honest limit is that session state is per session. Two agents co-ordinating across separate sessions are outside what Coco sees today.
Maker and checker, made binding
Maker-checker means the party that does the work is not the party that approves it. An agent that carries its own guardrail in its prompt is both.
Coco is the checker as a separate process. The agent cannot skip the gate, talk its way past a verdict or sign its own approval, and an ESCALATE waits for a person rather than timing out into a pass.
Enforcement is only as good as the contract behind it. A rule that is too loose passes things it should not, and no amount of enforcement fixes a rule nobody checked. That is why the gate starts in observe mode and why the catch report, not the install, is what decides whether to enforce.
Where it goes next
The gate is what exists today. A governance control plane sits above it, and intelligence on top of that. There is no lasting technical advantage in AI, so the strategy is speed, and every governed decision teaches us how compliance teams want agents to behave.
In this section
- How a call is decided. The ordered path from tool call to verdict.
- Architecture. One core, two roads in, and the hosted plane as deployed.
- Behavioural contracts. What a contract is, and who owns it.
- The ledger. Receipts, the hash chain, and what an auditor gets.
- What it does not stop. The threat model, said first.