A refusal is a good outcome
Software that stops when it is unsure is more useful than software that continues and is usually right. We would rather be told no and ask again than discover later that nobody could explain what happened.
Company
We think the current answer is the wrong shape.
Not incrementally wrong — wrong in kind. You cannot inspect your way to a guarantee, and most of the industry is trying to.
01Why we are building this
The gap nobody is closing.
The capability of autonomous systems has moved faster than anyone's ability to make promises about them. Teams are being asked to put agents in front of refunds, records, infrastructure and customer data, and the honest answer to what will it do is still some version of we watch it closely.
That answer works until the first time it does not. Then somebody has to reconstruct, from logs written by a system that was improvising, what an agent decided and why. Usually under time pressure, often in front of a customer, occasionally in front of a regulator.
We do not think the fix is more inspection. Watching a process more carefully does not turn it into a proof. The fix is to move the risky, creative work to a moment where it can be examined — before it runs, when there is still time to say no — and to leave run time to software that behaves the same way every time.
That idea is not new. It is roughly what a type checker did for programs, and what a signed build pipeline did for deployments: take the part that used to be trusted on faith and make it something you can check. We are applying it to what agents are allowed to do.
02What we believe
Four positions we will not trade away.
Evidence beats explanation
The value of a record is what it lets you prove to someone who does not trust you. That is a higher bar than a log file clears, and it is the bar we build against.
Boring at run time is the goal
The interesting part should happen once, up front, where it can be reviewed. What runs against production should be predictable to the point of being dull.
Say what is true about your own product
Including the parts that are not finished. A security page that overstates where a company actually is tells you everything about how it will behave when something goes wrong.
03Where we are
Private beta, deliberately small.
We are working with a limited number of design partners running real workloads rather than opening a self-serve signup. The work is more useful to us — and considerably more useful to them — when we can go deep on a small number of production problems.
The core is being developed as Apache-2.0 open core. Verification you cannot inspect is a strange thing to ask anyone to trust, so the parts that make the guarantee ought to be readable.
- Stage
- Private beta
- Licence
- Apache-2.0 open core
- Working with
- Design partners
If this sounds like a problem you have.
We want to hear about the workflow you are nervous about,whether or not it turns into anything.