The AI sent it. Nobody said it could.
An update adds Send. An unfinished customer response leaves with the internal notes still inside.
Before it was sentWithout the check
The customer gets the email.
An unfinished response lands in the customer’s inbox with the team’s internal notes still inside. The assistant could send it. Its permission still said draft only.
Your update is ready.
So is the new Send tool.
With ZAK checking the action
The draft stays put.
ZAK checks the requested action. Sending is outside the permission, so the attempt is stopped.
Being able to do it is not permission to do it.
Your update is ready.
So is the new Send tool.
Here is where
the ending changes.
01
Yesterday, it could write.
Your assistant prepared customer updates. A person sent them.
02
Today, it can send.
A tool update adds a new ability. That does not change what the assistant is allowed to do.
03
Go back to the moment before Send.
With ZAK checking the action, the drafting permission is still the limit. The message remains a draft.
The permission stays the same.
Try a different request.
Permission: draft only.
Draft allowed. The message stays in drafts.
Where could this happen
in your work?
Start with one action you would like to delegate. Work out the permission, the connection and the evidence it needs.
What would this require in practice?
This example explains the permission check. A real email connection must enforce that check before the provider sends anything. The interactive model on this page does not connect to an email provider.
The scenes show the decision being explained. They are not screenshots of a connected product or records of a customer incident.
Read the scope and limits