Part 9: Read-only tools first: how an agent earns write access

Part 9 · One Agent, Five Platforms

Nobody gives a new hire in accounts payable posting rights on day one. They read invoices, shadow a colleague, make suggestions, and take on more as their suggestions prove right. An agent should earn access the same way.

The contract is already settled. Part 7 split the nine tools into six reads and three writes, and Part 6 put a person's approval in front of every ERP post and every supplier message. Part 8 defined what happens when a call fails. What's left is the order in which the agent is allowed to use those tools in production, and what it has to prove before it moves up.

What "write access" means here

One thing first, so the title isn't misread: earning write access never removes the human gate. post_invoice_adjustment and notify_supplier require an approval_id at every stage, and the process API rejects them without one.

What the agent earns is scope: which tools are switched on, which exception types it may propose fixes for, and how large an amount it may propose. The person still approves every write. The agent earns the right to ask.

Stage 1: shadow

Tools on: the six read tools only. request_approval, post_invoice_adjustment and notify_supplier are not exposed to the agent at all.

The agent runs on real exceptions alongside the AP team. It investigates, classifies the exception and writes the proposal it would have made. Nothing goes to an approver and nothing is written. The team handles the invoice as they do today, then the two answers are compared.

This is where you find the problems cheaply: wrong classifications, weak evidence, prompts that miss a supplier's quirks, tools that return too much or too little. A wrong answer in shadow costs nothing but a log line.

Removing the write tools from the agent's tool list matters. An instruction saying "don't post" is a request; a tool that isn't there can't be called.

To move up:

• Classification matches the expected answer on the golden set and on a sample of live shadow cases.
• Proposals cite the evidence they rely on: the PO line, the receipt, the price agreement.
• No loops. The limits from Part 8 hold on every run.

Stage 2: assisted, low-risk types first

Tools on: reads plus request_approval. The write tools are exposed, and still fail without an approval.

The agent now sends real proposals to real approvers, but only for the exception types that Part 2 placed in "agent proposes, quick approval": missing goods receipts and near-duplicates. A wrong proposal here costs a short delay or a quick rejection, not money.

Everything else stays in shadow. Price and quantity variances are still investigated and logged, but they go to the team as before.

The most useful number at this stage is the override rate: how often approvers reject or change the agent's proposal. A high rate means the proposals aren't good enough yet, however confident they look. Approvers' comments are the best feedback you'll get for improving prompts and tools.

To move up:

• A low and stable override rate over an agreed period, set by finance, not by the team building the agent.
• No approval bypass attempts. Every APPROVAL_MISSING in the logs is reviewed.
• Approvers say the evidence is enough to decide without opening three other systems.

Stage 3: wider scope

Tools on: the same. What changes is scope.

Price and quantity variances over tolerance come in, starting below an amount threshold and rising as results hold. These go to approvers with financial authority, exactly as the tiers in Part 2 describe.

Two things never move, at any stage:

• Tax mismatches: the agent gathers evidence only. It doesn't propose a tax fix.
• Closed purchase orders: the agent summarises. Procurement decides.

Those aren't limits the agent grows out of. They're decisions that belong to people.

Moving down is part of the design

A rollout that only goes up isn't a rollout. Each stage needs a clear way back:

• If the override rate rises, or a golden-set run fails after a change to the model, prompt or platform, that exception type drops back to shadow.
• Scope is configuration, not code. Moving down should take minutes and need no release.
• A wider kill switch, covering the whole agent, comes in Part 39.

Every change of model or prompt restarts the evidence for the affected types. An agent that earned scope on one model hasn't earned it on another.

Why the platforms will be compared on this

Every build from Part 11 onwards will run through the same three stages, on the same golden set. For each platform I'll check that it can:

• Expose a different set of tools per stage, without rebuilding the agent.
• Limit scope by exception type and amount through configuration.
• Report the override rate and the approval outcomes per exception type.
• Drop a type back to shadow quickly.

These map to the human-in-the-loop and governance criteria in the scorecard. The golden set itself is Part 10: thirty invoices, and what "correct" means for each.

What is the first write you would trust an agent with?

---

This series describes a reference build on a fictional company. Product capabilities are based on vendor documentation as of October 2026; check current docs before you build.