Approval Is Not a System-of-Record Boundary

Approval is a decision point, not the whole control plane#

Adding a human approval step is a meaningful improvement over unrestricted automation. It gives an operator a chance to inspect and reject a proposal.

But approval alone does not answer the questions that matter after the button is clicked:

• Which tenant and records were in scope?
• Which sources shaped the proposal?
• Which tool was actually invoked?
• Was the request a retry or a conflicting replay?
• What durable record changed?
• What outbound effect occurred?

Without those answers, the approval is a moment in a chat interface—not a reliable boundary around business truth.

The six controls around an approval#

Tenant scope#

The agent must operate inside a server-derived tenant and workspace context. A prompt should not be able to choose which organization’s records are visible.

This is the first boundary because every later decision depends on the data being in scope.

Source evidence#

The operator should be able to see what source material informed the proposal. If the agent is answering from business knowledge, the workflow should distinguish grounded evidence from uncertainty or a missing source.

Tool permissions#

The agent should receive a filtered set of tools for that workflow. A tool catalog is not the same as permission to invoke every operation.

The distinction is especially important when read, draft, reversible, and customer-visible actions share one interface.

Policy re-check#

The system should apply policy at the point of execution, not only when the agent begins planning. Context, permissions, or business rules may have changed while a proposal was waiting for approval.

Idempotency and conflict handling#

Approval does not make retries safe. A workflow needs a way to recognize a repeated request and reject conflicting reuse of the same idempotency key rather than silently applying duplicate business effects.

Audit and backend-owned writes#

The final outcome should be written through the governed business path and recorded as evidence. The model output should not become a second, competing system of record.

A concrete distinction#

Compare these two outcomes:

Weak outcome: “Approved. The agent sent the message.”

Stronger outcome: “Approved by the named operator for the scoped conversation. The permitted tool committed the backend action with receipt .... The request was idempotent, policy passed at execution time, and the outbound effect count was recorded.”

The second outcome is more verbose because it is more useful. It gives the business a path to inspect, retry, reconcile, or explain what happened.

Mirai’s public About page describes this posture as “AI proposes. Systems commit.” The FAQ and safety and recovery guide define the current maturity and boundary rather than implying unrestricted autonomy.

What to ask in a vendor evaluation#

Ask the vendor to demonstrate:

1. how tenant identity is established;
2. how source evidence is attached to a proposal;
3. how the permitted tool set changes by scope;
4. where policy is re-checked;
5. how retries and conflicting idempotency keys behave;
6. where the durable receipt and audit record live;
7. what happens when the operator rejects the proposal.

If the answer is only “there is an approval button,” keep evaluating.