Design note / Active prototype
Making actions visible
Why saying a thing is done is not the same as it being done.
An assistant can describe an action perfectly well before anything has happened. The sentence and the outcome come from different places, and the interface has to keep them apart.
So you watch the tool itself. Running, finished, failed: three different things on screen. Finished means the work finished, not that the answer used the word.
Watch for the confident one.
The failure worth naming is the reply that reports success when nothing succeeded. It is convincing precisely because it reads so well. There is a check for exactly that: a claim that something is done, with no completed operation anywhere behind it, gets caught rather than shown to you.
Leave room to say no.
File changes come to you as a draft and a diff. Read it, edit it, or refuse it before anything is written, and put it back afterwards if you change your mind. Your approval is part of how it works, not a setting you can lose.
Keep failure visible.
Reconnecting, offline, and error sit alongside listening, thinking, and speaking. A disconnected assistant should not look ready. An unfinished job should not look finished.
These are interface decisions in a prototype that is still moving. They make it easier to see what is going on. They are not a promise that everything works.