one action · on rails · left working

Your agent drafts it. A human still clicks it.

Somewhere in your company an agent produces a refund, a payout, a credit, an access change, and then waits for a person to execute it. Every one. That person is not reviewing judgement calls; they are clicking through the obvious ones to reach the three that matter.

You are paying for something that can act, and using it to write. The cage is not caution, it is the absence of anything that can refuse, so refusing everything is the only safe policy available.

Count the ones a human did not need to see.

Take the action you already have an agent drafting. How many did it produce last month, and how many of those did a person execute without changing anything? That second number is what you are currently paying a human to do, and it is the number this engagement moves.

today agent drafts 400 a human executes 400
on rails state · authority · limits checked before each one
after the clear ones execute a human sees the exceptions
every one of them leaves a record what was proposed, what state it was checked against, who had authority, and what happened

We do not guess that ratio for you. The first week decides against your real traffic without changing anything, and then you can see it.

A week to see it. Then until it ships.

Week one Your action, running in observe mode on real traffic. We map what your agents can already reach, define the one action's states and authority, and put KIFF on its path, deciding, recording, refusing nothing. At the end you see what it would have allowed, held, and blocked, on your own volume, and what that agent would have drawn in a day.
Then Issue the card, and stay until it is launched and tested. The clear cases execute. Everything else routes to a person, with the reason attached. The card's ceiling comes from week one's number rather than from our guess, and past it the action is refused rather than sent to someone to approve. We are on it until it runs in production and your team has taken it over.
What stays An issued card and the tests that hold it. The runtime is MIT and self-hostable. The attacks we wrote against your own claims stay in your build, failing if the guarantee regresses.

A day rate and a small first step.

Week one is fixed at €7,500, and it ends with something running rather than a document. After that it is a day rate against an agreed scope, and we stop when the action is live and your team owns it, no project fee to approve up front for work nobody has scoped yet.

That first number is deliberate. Engineering leaders we have spoken with put their own signing limit near ten thousand; above it a second approval appears and the decision slows down. A sale about someone who does not want to own a sign-off should not require them to go and get another one.

If week one shows the ratio is not worth it, that almost everything needs a human anyway, we say so and you stop, having paid for one week and learned something true about your operation. That is a real outcome and we would rather reach it in week one than in month three.

We broke our own runtime before selling you one.

Our framework claimed an agent cannot approve its own action, enforced by two independent language rules and covered by tests that had passed for months. We wrote four attacks. Three worked. The first was four lines of reflection with no unsafe.

The part that mattered more: while the executor ran with an empty approval store, our own audit trail recorded the action as validated and executed. Nothing malformed, no warning, the exact record a reviewer would hope to find. Both write-ups are public, the bypass and the audit that found it, every attack now ships as a test that fails our build, and the guarantees that came out of it are listed at /invariants with the attack each one refuses.

Start with thirty minutes. Bring the action you already have an agent drafting, and the number of times a human executed it last month. If rails are not the right answer for what we find, we will say so. gabriel@kiff.dev