An assistant that can read an entire workspace is genuinely useful. Ask a question and it looks across conversations, records, calendar and pipeline, and answers something that would have taken four screens and ten minutes.
The moment it can also change things, the calculation shifts. Now a misunderstanding is not a wrong answer, it is a modified record, a moved deal, or a message a customer has already read.
Reading and writing are not one permission
The useful framing is that these are two products sharing an interface.
Reading is low risk and high value. The worst outcome is an answer that is wrong, which a person notices and ignores. Give it broad access, keep it inside the workspace's own boundaries, and it repays itself immediately.
Writing is the opposite. The value is roughly the same, the risk is unbounded, and the failures are not obvious. A record changed incorrectly looks exactly like a record changed correctly.
So they should not carry the same permission, and the interface should not treat them as one gesture.
Propose, then confirm
The pattern that works is dull and effective: the assistant does the thinking and stops one step short of the action.
It drafts the reply. It fills in the booking. It selects the deal and the new stage. Then it shows what it is about to do and waits.
The cost is one click. The benefit is that the person keeps the thing they were always going to be accountable for: what got said and what got changed. Nobody wants to explain to a customer that the software decided something on its own.
Two details decide whether the pattern actually works:
- Show the change, not a description of it. "Move the opportunity to Won" is a sentence. The record with the field highlighted is the fact. People approve sentences without reading them, because sentences are cheap; they read a diff.
- Make the default the smaller action. If the assistant is unsure between updating one record and updating twelve, it proposes one. Being under-eager is recoverable in a way that being over-eager is not.
Behaviour comes from the payload, not the prompt
A lesson that is easy to learn the hard way. When an assistant behaves wrongly, the reflex is to rewrite the instructions: add a rule, add emphasis, add an example.
That mostly does not work, and when it does it is fragile. The instructions are advisory; the model weighs them against everything else it was given. What reliably changes behaviour is changing what it receives: fewer, better-shaped facts, with the irrelevant ones absent rather than present-and-discouraged.
An assistant that keeps mentioning internal identifiers stops when the identifiers are not in the payload. One that keeps proposing the wrong record stops when the candidates are filtered before they reach it. Both of those are engineering changes to the data, not to the wording, and they hold.
The practical version of the rule: if the only lever anyone reaches for is the prompt, the system is being persuaded rather than configured, and persuasion regresses.
Summary
- Read access and write access are different decisions.
- The assistant proposes and a person confirms. One click, and accountability stays where it belongs.
- Confirmations show the change itself, and default to the smaller action.
- Undo does not cover anything that has already reached a customer.
- Fix behaviour in the payload. A prompt-only fix is a fix that comes back.
