Your AI Agent Is About to Do Something Irreversible

An agent in a procurement workflow has decided to send a purchase order to a supplier. The model has chosen the tool, filled in the arguments, and is one function call away from an email leaving your tenant.

Between that decision and that email there is a question most AI architectures never really answer: who said yes, and to what, exactly?

We wrote earlier about why approve/reject buttons fail as human oversight. This is the other half of that problem. Not how the human is asked, but what the platform knows about the action at the moment it asks — and what it does when the action goes out and nothing comes back.

Not every action deserves the same question

The first mistake is treating "the AI is about to do something" as one category. Reading a calendar and wiring money are not the same event, and a platform that gates them identically will either block everything or gate nothing.

Every tool in Findable carries an effect tier. There are five:

• read — looks at data, changes nothing
• read_egress — reads, and can carry data out of the tenant
• write_reversible — makes a change someone can undo
• write_irreversible — makes a change nobody can undo
• admin — reach across other people's data

The tiers are specific, not aspirational. Listing mailbox messages is a read. Creating a mail draft is reversible — the person deletes it. Sending that mail is irreversible. Writing to a directory group is admin.

Two rules make the tiers load-bearing rather than decorative.

First: anything unclassified is treated as an irreversible write. A tool nobody has reviewed does not get the benefit of the doubt.

Second: the default for each tier differs, and the defaults are not permissive. A reversible write is confirmed by the person who asked for the work. An irreversible or admin write asks a named approver. An owner can configure something looser per tier — that is a decision they make deliberately, in a policy editor, and it is visible — but a workflow that asks for an approval and names nobody to give it does not quietly run the call. It stops, with a reason that names who can fix it.

The approval is on the bytes, not the intention

Here is where most approval flows have a hole in them. A reviewer approves a described action, and then the system goes and performs an action. Those are not guaranteed to be the same thing.

In Findable, every write-tier call becomes a record in storage before the call is issued. The arguments are frozen at that moment, and the approval card shows byte-for-byte what will be sent — not a summary of it, not a regenerated version of it. The record moves through states anyone can audit: pending, then approved or rejected, then sent, then succeeded or failed.

Approve, and the frozen arguments go out once. Reject, and nothing is sent — the rejection becomes the step's result, handed back to the agent as an observation it has to reason about, and the workflow continues from there. The reviewer's decision attaches to a specific payload, which is the only thing that makes the word "approved" mean anything later.

One consequence worth naming: an MCP tool whose effect tier no administrator has reviewed never runs unattended — not even in a flow whose owner explicitly allowed unattended writes. The card says why the gate held. Annotations from a third-party server are a default to be reviewed, not a permission to be trusted.

The hard part is the answer that never comes

A write that returns 403 is a failure. You know nothing happened. You can retry it, log it, surface it.

A write that times out is not a failure. It is a question.

This is the case nearly every agent framework gets wrong, usually by retrying. The request may have reached the supplier's system and created the purchase order; the response may have died on the way back. Retrying sends a second purchase order. Not retrying may mean nothing was ordered. Both are wrong, and the system cannot tell which without asking.

So Findable classifies the outcome rather than guessing. A 4xx other than 408 or 429 is definite — nothing happened. A 5xx, a timeout, a connection reset, a broken pipe, a cancelled run, a transport failure that was not the server's answer: all ambiguous. The call may have landed.

An ambiguous write is never sent again. The step fails naming the record, and the platform does one of two more useful things:

It reconciles. A tool can declare how to find what its write created — a key field that the idempotency key is written into before the arguments are frozen, and a read-only lookup on the same system. Found at the target: the write succeeded, and the workflow moves on. Not found: it never landed, and the call is reissued under the same record. Can't tell: it stays ambiguous and an operator resolves it by hand, with the exact payload in front of them.

It reconciles before resuming. If the process died mid-call, every issued-but-unanswered record is reconciled before the run re-enters. A crash cannot turn one purchase order into two.

What this is actually for

The payoff isn't the gate. It's the answer you can give afterwards.

When someone asks what the AI did last Tuesday, there is a record of every write-tier call the workflow made: the frozen arguments, who approved them, when, what came back, and which ones are still unresolved. When one agent delegates to another, the chain takes the strictest policy any link set — a permissive child cannot loosen a cautious parent. When a designer tests a workflow before publishing, every write is recorded and none is sent.

None of this makes the agent smarter. It makes the agent deployable — which, for every enterprise we talk to, has never been the same problem as making it clever.

Findable runs inside your Azure tenant with your identity, your storage, and your audit trail. Request a demo or read the docs.