The problem
An agent that can write to your systems is a liability the moment it is wrong, and in a finance team it is wrong in front of an auditor. Most teams answer by letting the agent do nothing, which is the same as not having one.
What goes wrong
- The agent acts first and reports later. A wire is released, a client is emailed, a record is changed, and the first a person hears of it is the complaint.
- Approval is a checkbox nobody reads. The request lands in a channel with no context, the approver taps yes to clear the queue, and the gate is theater.
- Nothing is logged in a form a reviewer can use. When someone asks why a record changed, the answer is a chat scrollback and a guess.
The approach
- Write the gate list before the build: every action that moves money, contacts a client, or changes a system of record, and the role that owns each one.
- Make the agent draft the action and stop. The proposal shows what it read, what it will do, and what it is unsure about, on the channel the approver already uses.
- Log the proposal, the decision, the approver, and the time in a log you can export, then let the write happen only after the decision is recorded.
- Review the log every month: what was proposed, approved, and sent back, and where the agent was wrong. Every miss becomes a rule.
When it works
When the team can name the actions that matter and the person who owns each one, and that person is willing to read a short proposal instead of a long report. It does not work when the approver is everyone, which means nobody.
Why the gate comes first
An agent that reads is a research tool. An agent that writes is a colleague with system access. The difference is whether anyone stands between the agent and the action.
In a lending desk or a fund back office, a wrong action is not a bad draft. It is a wire released to the wrong account, a client told something the policy does not allow, or a record changed with no trail. At an insurer, it is a claim paid twice or an endorsement posted with no record of who approved it. The fix is not a smarter agent. It is a gate with a name on it.
What gets gated
Three kinds of action always go through a person.
Anything that moves money
Payments, releases, refunds, limit changes. The agent assembles the packet and names the amount, the account, and the source documents. The approver confirms or sends it back.
Anything that contacts a client
Emails, messages, letters, portal updates. The agent drafts in your voice from your approved material. A draft is a draft until someone says send.
Anything that changes a system of record
CRM fields, loan status, ledger entries, compliance flags. The agent shows the current value, the proposed value, and the evidence. The write happens after the decision is logged, not before.
Reads are not gated. The access list controls what the agent can see. The security playbook covers that list.
What a good proposal looks like
The gate only works if the approver can decide in under a minute. So the proposal is short and complete: what the agent read, what it will do, what it is unsure about, and two buttons. Approve. Send back with a note.
Example. A new client onboarding packet arrives. The agent checks the identity documents against the application, finds the proof of address is 97 days old against a 90-day policy limit, and proposes a hold with a message to the relationship manager. The compliance lead sees the packet, the rule, the date, and the proposed message. She approves the hold and edits one line of the message. The edit becomes the version that sends.
An approver who has to go find the document will stop reading and start tapping yes.
The log
Every proposal, decision, approver, and timestamp is written to a log you can export, in a form a reviewer can read without us in the room. When an auditor asks who approved a change and when, the answer is a row, not a recollection.
How we build it
First we write the gate list with you: the actions, the role that owns each, the evidence each proposal carries, and the channel it lands on. That document is the spec.
Next the agent runs in shadow. It reads real items and proposes what it would do. Nothing writes. The approval buttons go live on your channel, your approvers correct it in the review queue, and every correction becomes a rule.
Then approved items write to your systems, beside your current process, until the results match. Then comes switch-over. Your team works from it, and monthly operation includes the log review: what was proposed, approved, sent back, and where the agent was wrong.
Nothing on the gate list writes without a person. You set the list, and anything that moves money, contacts a client, or changes a system of record stays on it.
When it does not work
It does not work if nobody reads the queue: then the gate is a delay with no control behind it. Review the send-backs every month. The agent gets better because a person reads what it got wrong, and each correction becomes a rule.
Where to start
If you have one workflow with approvals in it, the Workflow Agent is the build. If you are not sure which actions belong on the gate list, ask Roo, Webaroo's AI: Which AI actions in our business should wait for a person?
Book 15 minutes with Connor