On the contact page, put the phone number below the form and make the
button dark blue. Show me what you change first.
When you build an assistant that really works on a server, you quickly arrive at the question that decides everything: what may it do on its own?
Asking for everything is the safe choice. You get a card at every step and you click approve. That works for exactly one day. After that you click yes on everything without reading, and your approval has become a clicking exercise. Asking for nothing is the other side: fast, and afterwards you cannot see what happened.
We now sit in between, and that did not happen in one go. This is what is left after half a year of building and picking the wrong side a few times. The practical guide is in approving changes, auto mode and undo; this is about the choices behind it.
Three modes, not two
The first version had two modes: ask or do not ask. That turned out to be the wrong split. In practice you often do want file changes to go through, but not a command that does something else.
So it became three: ask on every change, file changes automatically but everything else with a question, and auto mode where the assistant judges for itself whether a step is safe. That middle mode is the one people end up using most. Not because it is a compromise, but because it matches how you think about your own site: text and layout may be touched, the rest not without a word.
Reading never asks permission
A rule that looks small and matters a lot. Reading files, searching and seeing what is there always happens without a question.
That is not only convenience. An assistant that has to ask for every read action looks less and assumes more. You want it to inspect your files and then propose, not to guess because looking costs effort. The approval belongs at the moment of changing, not at the moment of understanding.
The problem with auto mode: you stop seeing anything
Here we ran into something that is not in the documentation. In auto mode a classifier judges whether a step is safe, and steps that get approved no longer pass the point where we build our approval card. The result: the change does happen, but there is no card, so nothing visible happens in the interface.
That is exactly the opposite of what you want. You gave the assistant more freedom and you got less insight.
The fix now sits in two hooks. One that keeps the old content of the file before every change, and one that reports after every executed change what happened. Together they still produce the difference in red and green, only afterwards instead of beforehand. The speed of auto mode with the visibility of ask mode.
The technique behind it is in our lessons on the Agent SDK.
One thing always asks permission
In every mode, auto mode included, there is one action that keeps asking: restoring a backup.
The reason is simple. Everything the assistant does to files you can undo with one button, because a snapshot is taken before every instruction. But restoring a backup turns back the clock in a way that same button does not reverse. An action that cuts off the way back should never happen automatically, however safe a classifier finds it.
That is the rule we find most useful out of this whole exercise: do not distinguish between dangerous and safe, but between reversible and not reversible. The first is a judgement. The second is a fact.
The lesson we had not thought of: half finished work
In one of our own build runs an instruction went wrong in a way no approval protects against. The assistant decided to push the heavy part of the task to the background and answered saying it would let us know as soon as it was done. For our system that answer was the end of the instruction. The work never arrived, and the next two instructions started on half a site.
Nobody had approved anything wrong. The question was never asked.
What we changed: background work is no longer possible, and the instruction now says explicitly that it has to finish before it answers. On top of that, large bulk changes are summarised instead of shown file by file, because hundreds of separate notifications stall the display. Both are in what's new.
The broader lesson: approvals protect you against the wrong change. They do not protect you against an instruction that was never carried out. For that you need a different check, namely verifying that the result is actually there.
Why a settings switch sometimes waits
Another small one, from the same corner. If you switch the knowledge packages of your website while a conversation is running, that can get in the way of the connection. That is now blocked: such a switch waits until your session is finished.
It is an example of something you only see once people really use your product. In the documentation a session is a thing that starts and ends. In practice someone is halfway through and flips a setting in another tab.
What we would recommend if you build this yourself
Three things, in this order.
Let reading always happen without a question and only ask when something changes. Not the other way round.
Make sure automatically approved steps still become visible. Giving freedom is fine, giving up insight is not.
And draw a hard line at actions that are not reversible. That list is shorter than you think, which is exactly why it is manageable.
Common mistakes
Picking a mode and never switching again. The mode belongs to the instruction, not to the person. Having a new page built asks for something different than changing a price in a live shop.
Using approve everything for this task as your default button. It exists for an instruction whose plan you have seen. Not for the first card you come across.
Thinking undo reverses everything. Files yes, content in your database no. For the second there is a backup, and that always asks permission.
Seeing an approval as a check on the result. You approve a step, not an outcome. After a big instruction, check that the result is really there.