When the Agent Gets It Wrong: The Situation, the Problem, and What We Do About It

A hypothetical but entirely ordinary case — and our answer to it

The situation

Picture a clinic network that put our agent on booking and confirming appointments. The agent works in WhatsApp and by phone, sees the schedule, moves slots, cancels appointments and issues refunds.

One Friday evening, the administrator who normally approves refunds leaves and switches off her phone. On Saturday a patient asks to cancel and get the money back. The agent sees that cancellation is allowed and that the refund is "within authority", and does both. On Monday it turns out the administrator had revoked refund rights on Friday — but the revocation lived in a different system, and the agent never learned about it.

The money went back to the wrong patient, in the wrong amount. The clinic asks us three questions: who authorised this, why did the agent not stop, and what can you show us.

The problem

The problem is not that the model made a mistake. The problem is that the system had no answer to three things at once.

First. Authority lived apart from the action: the refund right was revoked in one place and exercised in another, with nothing in between connecting them.

Second. Nobody had described what happens when the approver is unreachable. By default the system behaved as "allowed" rather than "denied".

Third. The clinic was left with a log. Detailed, tidy and useless: it could not show on what basis the action was permitted, or whether that basis was valid at that second.

This is not exotic. It is what almost every agent incident review looks like: authority, decision and execution live in different places, and the evidence is assembled after the fact and does not answer the main question.

How we solve it

We do not promise the agent will never be wrong. We build so that a mistake is bounded, stoppable and checkable.

Authority with limits and an expiry. The agent acts inside a granted mandate: which actions, up to what amount, in which channels, until when. Refunds, signatures, publication — either outside the mandate or through human confirmation.

A rule for when nobody is available. We describe in advance what is allowed without the owner and what is not. Denied by default. A revocation stops the next action, not the next conversation.

A record that answers "on what basis". Every significant action leaves a trace: which authority, which decision, what was sent, what actually happened on the receiving side — and separately what we did not measure. That last part matters: a record pretending to be complete is worse than one that marks its gaps.

A review, not an excuse. We go through the incident against predefined scenarios — refusal at the decision point, stale evidence, unreachable authority, revocation after dispatch — and show which of them held and which did not.

The contract. What counts as an incident, how many hours until we report it, who is responsible for rollback and within what limits. Without this, the previous four points are promises.

What the client gets

In the same clinic example: the refund does not go through, because the right was revoked and the revocation is checked at the moment of the action; if the administrator is away, a pre-agreed boundary applies rather than a guess; and by Monday the clinic has not a "log" but a review — why the system did what it did, what was proven, and what stayed outside measurement.

What we do not do

We do not sell a certificate of compliance. We do not claim to have proven that an agent is safe in general. We do not pretend to prove on our own that the receiving side executed exactly that action — part of the guarantee lives with the executor and the target, and we say so plainly.

If you like, we can walk through your scenario: where the boundary of authority sits today, what happens if the responsible person disappears, and what the record will look like after an incident.