Use cases
Three places an agent takes real actions
Each of these was built as a working model: a realistic system, a real AI agent driving it, and the failures allowed to happen before any control was written. Each page answers the same questions — what the work is, how it goes wrong, where the checkpoint goes, what you get, and what it will not do. The last one is there because it is the part a product page usually leaves out.
Paying suppliers
An agent pays invoices that match an open order. The fraud that beats it changes the supplier's bank details first, so every payment afterwards is correct in every checkable way. The control is on the change, not the payment.
Read it →Cloud and platform operations
An agent fixes incidents using the credentials an on-call engineer would have. A checkpoint in front of your deployment tool is blind to it calling the cloud provider directly — and the honest fix is to take the credentials away.
Read it →Clearing a work queue
Results, tickets, alerts. Here the harm is what the agent closes without doing, and an empty queue looks like success either way. One rule covers both the careless and the over-cautious agent.
Read it →The pattern that shows up in all three
These domains have nothing in common — a finance department, a platform team, a clinic — yet the control that carried the value was the same shape every time: an approval on a small, rare change that unlocks a large, frequent effect. A supplier's bank details. A resource's delete-protection flag. A patient record merge.
None of them is a rule about the dramatic action. Guarding the payments, the deletions and the closures would mean reviewing hundreds of items a month and still missing the one that mattered. Guarding the change that unlocks them means reviewing a handful of requests a year.
We think that is the most useful thing we have learned so far. It also makes the claim more honest: what this really offers is change control on those few enabling actions — a narrower and more specific promise than "a gateway for AI agents", and one that can be tested.
How to read these pages
They describe test systems, not customers. Each one was written to behave like the real thing, including the parts that are inconvenient — an API generation nobody retired, a field the newer client overwrites, a bulk action with no way to escalate — and then a real language model was pointed at it and allowed to fail. The controls were written afterwards, against what actually happened.
What we do not publish here are the loss figures from those runs. They are measurements against a model of a business, not against yours, and a number like that in a marketing page is a claim we would rather not make on your behalf. The mechanisms, the limits and the failures are all here, and the code is open.
The mechanism, in the developer's guide → · where this project stands →