Read vs Write Tools: Designing an AI Agent's Permissions Around Money

Sort the tools before you build anything else

Every action an AI support agent can take falls into one of two buckets, and the split drives most of the safety design. The AI agent read vs write tools distinction is the first thing to get right — read tools are low-stakes, write tools change state and, for refunds, move money.

The two buckets

• Read: get_order, get_tracking, get_return_policy, get_refund_status. Worst case is a stale or wrong answer — a follow-up question, not a broken transaction.
• Write: create_return, issue_refund, update_shipping_address, cancel_order. These change state. A wrong one is a support ticket about you, and for refunds, real money out.

What the split drives

Once you've sorted the tools, the write bucket gets treatment the read bucket doesn't need:

• A tighter confidence threshold — the agent has to be more sure before it acts than before it answers.
• Guardrails — refund caps, and an approval requirement above a value threshold.
• Idempotency — a retried issue_refund after a timeout must not pay twice.
• A fuller audit record — which customer, which tool, what arguments, what result, the agent's stated reason — with tighter retention.

Business rules live in the tool

"Returns accepted within 30 days" is enforced by create_return, in code — not written into the prompt where the model might paraphrase or forget it. The model decides whether to call the tool; the tool decides whether this order actually qualifies. On our support agent project the eligibility rules sit in the tool that executes the return, checked against the live order record in the same transaction.

No write tool, no write action

The agent can only do what its tools allow. No issue_refund tool means no refunds — by design, not by good behaviour. This is the simplest safety control you have: don't give the agent a capability you're not ready for it to use.

A sensible first-release scope

Ship the read tools plus one write tool — usually create_return, since it starts a process without moving money — behind a confidence threshold, idempotent, audited. Hold issue_refund, cancel_order, and update_shipping_address for a second release, once you know the escalation and error rates on the first set. Each write tool is a new failure mode to watch; add them one at a time.

An approval queue for large writes

Above a value threshold, a write tool shouldn't execute on the agent's judgement alone. Instead of running issue_refund directly, it queues the proposed action — the customer, the amount, the order, and the agent's stated reason — for a human to approve or reject with one click. This keeps the agent useful on large refunds without giving it unbounded authority: it does all the work of assembling the case, a person makes the final call, and the customer waits minutes rather than for a full manual investigation.

Auditing a write after the fact

Every write action leaves a record that has to answer "why did the agent do this" months later: the customer, the tool, the exact arguments, the result, the agent's one-line reason, its confidence at the point of the call, and the model and prompt version. Append-only. On our support-agent project that record is written for every action the agent takes, and it's the thing a disputes or compliance review pulls first.

Where this stops being right

• A read-only agent is dramatically cheaper and lower-risk. Many teams start there and add writes later, and some never need to.
• If you can't staff an escalation queue or review refunds, keep write actions out of the automation entirely.
• A tiny, low-volume queue may not justify the write-path safety work at all.

FAQ

What's the safest first write tool? create_return — it starts a process but doesn't move money. issue_refund and cancel_order carry more and can wait for a second release.

Should refund limits be in the prompt? No. Enforce them in the tool. The prompt is guidance; the tool is the control.

Can an agent be write-capable and still safe? Yes — confidence thresholds, idempotency, caps, approval above a threshold, and an audit record on every write.

ISTRALLEN builds support agents with the read/write split and its safety controls designed in from the first release; see AI for E-commerce.