Changes
It proposes. You approve. The server applies.
The conversational loop cannot change anything: the assistant can only read or propose. A change is a separate, human-confirmed step, and when it runs the server executes the arguments it stored at proposal time rather than anything the browser sends it.
How it works
Three steps, and what is checked at each one
This is the part of an AI assistant that either earns your trust or quietly loses it, so it is worth being specific.
Propose
Maddox calls a tool whose name begins with propose or draft. It validates the change and shows you exactly what would happen without doing it. For a campaign edit that means running the real change inside a transaction that is then rolled back, so the diff you see is the diff that would apply.
Approve
You see a card describing the change in plain English and click approve. The request names a stored proposal by its identifier. It cannot describe a different change, because the endpoint does not accept a tool name or arguments at all.
Apply
The server re-reads the proposal, re-checks your permissions and scope, and re-verifies the change against the live record. If anything moved since you were shown the diff, it refuses and tells you, rather than applying something you did not approve.
In the product
An approval card, and an audit trail behind it.
The mechanism
What happens when somebody clicks approve on twenty cards
That is the second question people ask, straight after “can it write”, and it has a specific answer rather than a reassuring one.
A batch is judged one action at a time
Approving several cards together is not a single decision applied to a list. Each action is asked separately whether a batch may carry it, and one that may not is refused on its own, by name, with the reason — while the rest still run. A selection containing one thing that must be looked at individually should not cost you the four ordinary changes you also selected, and silently dropping it would be worse than either outcome.
The policy is read off the tool, not off its name
The rule used to be a list of tool-name prefixes mapped to sensitive domains, and it admitted its own failure mode in writing: a tool matching no prefix fell through to a general bucket, which was bulk-approvable. That list was one unremembered naming convention away from sweeping up something serious.
It now asks the same question the capability manifest already asks to decide whether to offer a tool at all — does this tool declare a permission inside a blast-radius domain — using the thing a tool cannot avoid declaring. A tool is refused a place in a batch for exactly the reason it would be refused exposure, and a new tool inherits the policy by declaring its domain rather than by somebody remembering to add it. An action naming a tool the registry cannot resolve is refused outright, because a name nobody can resolve is the worst possible case for guessing from the name.
The approval list is built from the same manifest that offered the tool
The set of tools an approval can name is assembled from your own manifest — the one the four gates produced for you at the start of the turn. So an approval cannot name a tool you would not have been offered in the first place. There is no second registry with its own idea of what you may run, which is the usual place a gap like that opens up.
A rejection is written back into the conversation
Rejecting a card asks you for a reason, and that reason is persisted against the conversation and replayed on the next turn. A refusal nobody records is a refusal the assistant never learns about, so it proposes the same thing again and the reason you were asked for goes nowhere. Failing to write that note does not fail the rejection itself — your decision is the part that matters.
Who it is for
For whoever has to sign this off
Most objections to an AI assistant in a CRM are really objections to unsupervised writes. This page is the answer to those.
- Sales operations, who own the data quality this could damage
- Security and compliance reviewers asking what it can actually do
- Administrators deciding who should have the assistant at all
Related
Questions
The things people actually ask.
What exactly can Maddox change?
Six things: create a follow-up task for yourself, book a meeting at a time it has checked, edit a campaign, pause one, resume one, and create a campaign as a draft. It cannot update a deal, move a stage, edit a contact or company, change a quote, touch a ticket, or assign a task to another person.
Could the model call the applying tool directly?
No. Any tool that changes data is refused unless the request carries a human-confirmed approval, and the chat loop never builds one. The model is also told plainly never to call those tools, because doing so achieves nothing except a refusal.
What stops an approval being replayed or tampered with?
The proposal is stored server-side and the approval names it by identifier. Approval is checked against the workspace and against the same person who was asked, a double-click cannot apply it twice, and the stored arguments are hashed so a reviewer can later assert exactly what was approved.
What happens to an approval nobody answers?
It expires, an hour by default. An open approval card is a standing offer to change something, and one left open for a week is an offer whose details nobody has re-read.
Can I reject one?
Yes, with a reason, and the rejection is written back into the conversation so the assistant does not immediately propose the same thing again.
Read the approval card before you trust the assistant.
It is the shortest honest summary of what any AI in your CRM is actually allowed to do.