In the demonstration, the agent reads the claim, finds the policy, corrects the customer’s address and closes the ticket. A field in your system of record has changed. Nobody in the room asks the question that matters in a regulated organisation: who approved that change?
Reading answers, writing acts
An agent that reads your systems and answers produces statements. A statement commits nothing.[1] If the answer is wrong, the record is unchanged.
Once the agent holds credentials that can write to the system of record, the situation is different. A write is an act. It propagates: the nightly job reads it, the invoice carries it, downstream systems rely on it. It commits the organisation, and closing the window does not undo it.
This is the central question for agents in production, and it usually comes up too late, in the security review after the pilot has been declared a success.
A log records the past
The usual answer is a log: the agent writes, each write is recorded, an auditor can read the record. The record is accurate, but it is not a control. A log describes what happened; a control governs what will happen. By the time anyone reads the entry, the field has changed and the change has spread.
What separates a draft from a mistake is reversibility.[2] Deciding is cheap and can be revised; executing is neither. The sequence is preview, commit, revert. An error caught before the commit is a draft that gets discarded. An error found in a log is an incident that gets explained to a regulator.
Undo is a second write
Vendors know this and offer an undo. But an undo is a second write that restores the previous value, issued after the first write has propagated. In between, things happened: the customer received the letter, the position was reported, the batch was released. The second write corrects the record. It does not recall the letter.
The only error that can truly be reverted is one that never reached the record.
Approving three hundred proposals a day
The other answer is a human in the loop. But a person approving several hundred machine proposals a day is not examining any of them. The arrangement exists for the auditors.[3] Human control is real only if the proposal is presented in terms the person understands, can be refused without professional cost, and can be reversed. Bulk approval fails all three: proposals arrive as a list, refusing one causes a delay someone will have to justify, and the batch is committed as a whole.
A decision without a name is no one’s decision.[2:1] A name obtained by clicking “approve all” is not much better.
Our position
The industry’s usual pattern keeps the decision in the platform and sends the source system an instruction. The ERP or the CRM receives a call, and the rules that govern that call live elsewhere.
Galahad refuses three things. Write access with a log as the only control, because the log comes after the act. Bulk approval, because a hundred proposals approved in one click is one decision taken by nobody. An undo that is a second write, because reversibility ends at the commit, so the review has to happen before it.
Monarch proposes and never executes alone. A mistake stays an uncommitted draft.[4] Every step is auditable and every decision traceable to a person. This is what authority has always meant, not a concession to regulators.[2:2]
Questions to ask a vendor
Ask them in writing, before the agent receives any credential.
- Which of my systems can the agent write to, and under whose account?
- What does the approver see before the write: the exact change to the record, or a summary written by the model?
- How many proposals does one approver receive per day, and can they be approved in bulk?
- What does it cost the approver to refuse one?
- What does “undo” mean: discarding a draft that never reached the record, or a second write after the first has propagated?
- Whose name is on the write, and can it be removed afterwards?
A vendor who answers all six with something you can verify from your own network has built a system a regulated organisation can run.
Monarch puts every action in front of a named person before it happens, inside your infrastructure, on the systems you already run. See it on your data.