Everything that has an effect on the outside world waits for a person's signature in the default setting. You choose two exceptions yourself: the autopilot for low or medium risk actions, and the support assistant that answers visitors on its own. Actions with high risk are always done by a person. This page describes exactly what happens, so you can build on it.
- ProposalThe agent proposes what has an effect on the outside world.
- SigningA person decides in the portal or in Discord.
- ExecutingThe runner claims it exclusively and does it.
The life of a proposal
- agent proposes
- open
- person signs
- runner claims
- uitgevoerd
- open
- verlopenafgewezen
- runner claims
- misluktonzekerniet-uitvoerbaar
The words in code type (open, uitgevoerd, onzeker and the rest) are the literal status values in the system, so they stay as they are. The table below explains each one.
| Status | What it means |
|---|---|
open | Waiting for a signature. Expires on its own. |
bezig | A runner has claimed it exclusively. |
uitgevoerd | Done, with the outcome attached. |
mislukt | Tried, the other side returned an error. |
onzeker | Started, outcome unknown. A person has to look. |
afgewezen | Someone said no, or the question expired. |
niet-uitvoerbaar | Signed, but we cannot do it. The reason is attached. |
Why onzeker exists
A claim in our database says nothing about what happened outside our database. If a runner goes down between the call and writing the result, we do not know whether the other side carried it out.
Where you can sign
- In the portal, on the screen with what is waiting.
- In Discord, on a card with two buttons in the channel linked to that workspace. Only someone with signing rights in that workspace can click, and the buttons carry a signature so that a forged button never even reaches the permission check.
- Not via MCP. No tool can issue a signature.
Confirming again with a code
- digits from your authenticator
- 6
- minutes before a second signature asks for a code again
- 5
A signature that costs money, cannot be undone or makes something public asks, after Sign, for the six digits from your authenticator. This is fixed per action and is on straight away: publishing or rolling back a site, and anything whose cost cannot be foreseen. An action you can reverse and that costs nothing looks the same as before.
- Five minutes. If you just gave a code, when signing in or on an earlier signature, a second signature within five minutes does not ask again.
- Only a code from the app. A recovery code is for getting in and does not count here.
- No second step? Then you see a message with the way to My account. Set it up first and sign afterwards.
- Stricter per workspace. A workspace can choose that every signature at the highest level asks for the code. Looser is not possible.
- Discord, the command line and MCP cannot ask for a code. They refuse such a signature and point to the portal.
- WhatsApp asks for the PIN for these actions. That counts as proof.
- Proposals outside the action list too. Every proposal from an agent that is not in the list of actions (an outside connection, a workflow, image, logo, voice-over or support) asks for the code. Only the proposals of Website Studio itself, a draft you still have to accept, do not.
- Discord, the command line and the old portal therefore no longer sign such proposals. You see a message and sign in the portal under To sign. This is a change from before.
- A chat never signs by itself. If a proposal asks for a code, the crew puts it ready under To sign, also in the chat and in the editor assistant.
The trail shows stapup.bevestigd or stapup.geweigerd, with who and about what, and never the code itself.
Where it lands in the trail
Every decision writes a line: who signed, from where, about what and when. For Discord, the server and the channel are included, because with a wrong link the question is not who signed but in whose house.
The trail cannot be changed or deleted, not even by throwing a workspace away. That is a database rule, not a working agreement.