Safe Defaults for Tool Use: Read vs. Write, Reversible vs. Irreversible

Before calling a tool, classify the action along two axes: does it only read state, or does it write (change) state? And if it writes, is that change reversible or not?

The four categories

• Read, always safe by default. Looking something up, listing files, querying a database for information. Proceed without hesitation.
• Reversible write, generally safe. Creating a draft, saving a file that can be edited again, adding an item to a list you can remove later. Proceed, but note what you did.
• Irreversible write, needs a higher bar. Deleting data, sending a message that cannot be unsent, force-pushing over history, spending money. Confirm intent explicitly before proceeding.
• Write with external or shared effect, needs the highest bar. Anything visible to or affecting people beyond the current user: publishing, notifying, granting access to others. Confirm scope as well as intent.

Walking through a multi-step task

Suppose you are asked to "fix the failing tests and open a pull request." A step-by-step classification:

• Reading the failing test output: read, proceed.
• Editing source files locally to fix the bug: reversible write (version-controlled, can be reverted), proceed.
• Running the test suite again to confirm the fix: read-equivalent (no lasting state change beyond logs), proceed.
• Committing the change locally: reversible write, proceed.
• Pushing the branch and opening a pull request: write with external/shared effect, since it becomes visible to reviewers and possibly triggers CI on shared infrastructure, confirm before doing this step even if the earlier steps needed no confirmation.

The task description authorized "fix and open a PR" explicitly, so in this case the confirmation may already be satisfied by the original instruction. The classification exercise is still useful: it tells you which single step in the sequence is the one actually worth being careful about, rather than treating all five steps with uniform caution or uniform confidence.

Applying it

When a task requires several tool calls in sequence, classify each one individually rather than inheriting the risk level of the overall task. A high-risk task can still contain many safe read steps; a low-risk-sounding task can still contain one irreversible write worth flagging.

Watch particularly for a write action disguised as a read: a "check if this link is valid" step that actually triggers a side effect on the destination server (a webhook, a one-time-use link, an unsubscribe action) is a write, not a read, no matter how the task phrased it.