What you approve is what runs
There is a moment that decides whether you really dare to deploy an AI agent for work that matters. Not the moment it writes a nice proposal. The moment after: you have read it, you click approve, and it disappears from view. What happens in the seconds that follow, you simply have to take on faith.
With Stilops you don't have to take it on faith. That's not because our intentions are better than anyone else's, but because we made that one moment the core of the system rather than a setting around it. This piece is about what that means in practice — including the part that was wrong on our side, and what we did about it.
The question behind the question
“A human must approve” is by now on practically every product page for AI agents. That is good news: the idea that software may not act on your behalf unasked has won. But it also makes it easier to skip the important question. That question is not whether permission is asked. It is whether what you gave permission for is what gets executed afterwards.
That is less self-evident than it sounds. In the common setup, the preview and the execution are two separate paths. The preview runs restricted and read-only, and produces a plan — that is what you read. If you approve, the original task is started again, now with full permissions. So the agent starts over, and the plan you reviewed goes nowhere. Nothing fails, nothing stands out, and usually it arrives at the same result. But the guarantee that what runs is what you saw is not there.
We know this so precisely because it worked that way with us too. A user put his finger on the sore spot: a test run only deserves trust if it touches the same rules, permissions and data as the execution, and two separate paths inevitably drift apart. When we checked, it turned out to be sharper than he had cautiously phrased it. The two paths didn't just have the potential to diverge — they did something different. You approved a plan, and a task ran.
An approval that is tied to what you saw
The solution is less spectacular than the problem, and that is exactly right. The moment a proposal appears on your screen, a fingerprint is calculated over precisely that: the task and the plan that came out of it. Both, because covering only the task lets a changed plan slip through unnoticed, and the other way around just the same. That fingerprint travels along with your click and is recalculated on the server from what is actually there at that moment. If they differ, something changed between showing and clicking — and the approval does not go through.
If the fingerprint is missing, it doesn't go through either. That is a deliberate choice: here it is about whether someone really approved what they thought they were approving. A check like that should fail closed when it cannot work, not open.
And the second half, which matters at least as much: the approved plan now travels along to the execution. Not as background information, but as the task itself, with an explicit rule added. If the situation turns out so different that the plan no longer fits, the agent may not solve it anyway in its own way. It explains what deviates and what it now proposes, so that you review again. Your approval applies to this plan, not to the task in general.
Also when you approve ten proposals at once — especially then. A batch gets its own fingerprint over all the proposals in it, independent of order. If one proposal changes, or one is added or dropped between showing and clicking, the whole batch does not go through. One click that approves most things at once is exactly the place where a check must not be missing.
What that gets you
- You don't have to rely on good intentions. What you read is what runs, or it doesn't go through — that is a mechanical check, not a promise.
- Doubting costs you nothing. A proposal you reject is something that never happened: rejected and still-pending test runs don't count towards your monthly quota, up to three times your included number of tasks per month. Calmly saying no once in a while is free.
- After your approval, the agent first checks whether the work hasn't already been done another way — by a colleague, by you, outside Stilops. If so, it stops there instead of doing it twice.
- Afterwards it can be retold. Every proposal, every test run and every decision is in a log with no edit or delete button, because that function simply doesn't exist anywhere in the system.
Taken together, that changes the conversation you have internally about AI. No longer “may we switch this on and what could go wrong”, but simply: who looks at it and when. That is the difference between a tool you cautiously keep at the edge of your work and a colleague you dare to put right in the middle of it.
Why you can't switch approval off
Every task you give a Stilops agent starts as a proposal. Not because that is the default setting, but because the server creates it that way and no other route exists. There was once a checkbox with which a customer could skip the test run. That checkbox is gone, and it is not coming back — not as an advanced option, not as an exception for large customers who “really don't need it”.
That is also how we look at the AI Act. For us, human oversight is not a chapter in a policy document that lives alongside the product, but a line of code at the point where tasks are created. The same goes for the rest: documents and draft messages that an agent prepares are marked as AI-generated by the system itself, not because we politely asked the agent to. Compliance that depends on an instruction is compliance that is missing on a bad day.
This costs us something too, and that is worth stating honestly. We can't claim that our agents do your work fully autonomously while you sleep. That is the trade-off: you swap the fantasy of full autonomy for the certainty that nothing happens that you haven't seen. We think the winning form of work AI is not the most autonomous one, but the most trustworthy one.
What isn't finished yet
The fingerprint closes the gap between what you see and what runs. What remains open is the reporter's original point in its full form: the preview and the execution are still two routes with different permissions. Merging them into one route with a switch that turns off the side effects is the next step. Then the test run is no longer a good approximation of the execution, but literally the same execution with the plug pulled.
We mention it here because a vendor who only lists his strengths doesn't help you assess him. An open point that you can ask about is worth more than a claim you have to take on trust.
The calm alternative
The fear around AI in the workplace is seldom about whether it is smart enough. It is about the email that went out without anyone seeing it, the amount that shifted, the customer who received a message nobody would have wanted to send. That silence is exactly where it goes wrong — and exactly there we set our own silence against it: an agent that says nothing until there is something worth your eyes, and then asks for your attention once, clearly.
Handing off work without handing off control is not a compromise between the two. It is what remains when you take the approval moment seriously enough not to be able to switch it off. Hire an agent, give it a task, and see what appears on your screen. Nothing happens before you approve it — and what you approve is what runs.