Read vs Write Tools, and Why Confirmations Matter

This is the single most important safety concept in agentic support, and it's easy to get wrong. The instinct is to grade tools by how smart they are. The right axis is far simpler: does this tool read, or does it write? Read tools look at the world. Write tools rearrange it. Everything about how you trust an agent — when it runs alone, when a human signs off, what you log — follows from that line.

Macha is an AI agent layer that sits on top of the helpdesk you already run (Zendesk, Freshdesk, Gorgias, Front) and connects out to commerce and knowledge tools. Because Macha agents take real actions — post public replies, update tickets, issue refunds through Stripe or Shopify — it draws the read/write line explicitly and puts a confirmation gate on the write side. This post explains the concept, why it matters, and exactly how Macha implements it.

The two kinds of tools every agent has

Every tool an agent can call falls into one of two buckets:

• Read tools answer a question. They have no side effects: run one a thousand times and nothing in your world changes. Get ticket. Search tickets. Look up the customer. Fetch the order. Search the help center.
• Write tools take an action. They create, modify, send, delete, or transact — and the effect is visible to someone outside your dashboard. Add a public reply. Update the ticket status. Change the subject. Issue a refund. Create a Confluence page.

You can see both kinds living side by side the moment you assign tools to an agent. Macha's tool picker mixes pure look-ups (Get Ticket, Search Tickets, Search Help Center Articles) with genuine actions (Add Public Reply, Update Ticket Status) in one list:

The reason this matters is reversibility and blast radius. A read tool that misfires costs you a few tokens. A write tool that misfires sends a wrong answer to a real customer, closes a ticket that should have stayed open, or moves money. The blast radius of a read is zero; the blast radius of a write is your customer's inbox. That asymmetry is the whole game.

This isn't a Macha idiosyncrasy — it's the consensus pattern across every serious agent framework. AWS's guidance on human-in-the-loop confirmation for Bedrock Agents frames it as letting developers "decide which tools can be executed automatically and which ones should first be confirmed." WorkOS's AI agent access-control guide puts the human side plainly: "build in checkpoints where a human must confirm, and in some cases re-authenticate, before the operation proceeds" for destructive or high-risk actions. Cerbos's MCP-permissions guidance tiers it explicitly: a read-only user "should only see tools that perform read operations — write or admin-level tools should simply not be available," some roles "can approve but not delete," and the safe stance is default deny — if a policy doesn't explicitly allow an action, the agent shouldn't take it. The principle is consistent across all of them: let agents do cheap, reversible work on their own and ask before crossing a line that's public, financial, or hard to undo.

How Macha draws the line

Macha applies the read/write distinction in three places: when a tool is built, when an agent runs interactively, and when an agent runs autonomously. Each has its own default, and the defaults all lean toward safety.

1. Write tools are marked at build time

When you connect a REST API as a custom tool, Macha asks you the one question that matters: is this a read or a write? The Create Custom Tool modal has an explicit Type toggle — Read or Write (requires confirmation) — right next to the HTTP method:

You don't have to remember to flip it, either. As of the March 30 release, Macha's AI Tool Builder auto-detects the type from the HTTP verb: GET requests are treated as reads, while POST, PUT, PATCH, and DELETE are automatically marked as write operations that require confirmation. The web's own conventions about what mutates state become your safety default. You can always override it — but the system fails closed, toward asking, not toward acting.

The built-in connectors carry the same metadata. When Shopify shipped, create_refund arrived explicitly "with confirmation." When the Confluence connector landed, its page-create, page-update, and comment tools were all flagged as write operations requiring confirmation, while search and read-content tools run freely. Macha's own native tools follow suit — the Update Ticket Subject tool, for instance, validates the new subject (1–150 characters) and requires confirmation in chat mode before it touches the ticket.

2. In interactive chat, writes pause for you

When you're chatting with an agent in the dashboard's Chat tab, read tools stream their results inline — the agent fetches a ticket, looks up an order, searches your knowledge base, and just keeps going. But the moment it wants to write, it stops and asks. You confirm the write operation before it executes, with the proposed action and its arguments in front of you.

The proposed call is shown with its arguments before anything happens, so you approve the specific action — this reply, this refund amount — not a blanket permission.

This is the same tool-level human-in-the-loop pattern that Cloudflare's agent docs and Microsoft's Agent Framework describe: pause execution right before a risky function runs, let a human approve, reject, or adjust, then continue. The agent does all the thinking and assembling; you keep your hand on the trigger for anything that leaves the building.

3. In autonomous mode, the rules are stricter — by design

Interactive chat has a human watching. Autonomous runs — an agent firing on a new-ticket webhook or a scheduled trigger — do not. So Macha sets the defaults accordingly.

By default, sub-agents are read-only during interactive chat for safety, and write permissions are something you grant deliberately for autonomous execution. The capabilities themselves live in two places on the agent's configuration page: the Triggers that decide when an agent fires, and the Tools that decide what it can do. A broad trigger like Every Customer Message sits right next to narrower ones in the triggers picker:

When you do turn on a high-impact capability, Macha makes you look at it. As of the April 17 release, toggling on a high-impact tool (Add Public Reply, Update Ticket Status) or a broad trigger (Every Customer Message, New Ticket) raises an activation confirmation modal — a severity-themed warning with its own confirm and cancel labels, so you can't enable "reply to every customer automatically" by reflexively clicking a switch.

And once it's on, Macha keeps reminding you. Enabled tools and triggers display a persistent advisory card on the agent's configuration page: a short, always-visible note on how to use that capability safely. You can see the shape of it on the Tools list, where the high-impact write tools (Add Public Reply, Update Ticket Status) sit among the reads, each in its own row on the config page where the advisory note lives:

The warning doesn't vanish after setup — it lives next to the thing it's warning about.

A worked example: the refund that asks first

Picture a Shopify-connected agent handling "where's my refund?" tickets on Zendesk. A customer writes in. Here's the shape of a run:

1. Read: get_order — pull the order by number. No confirmation; it's a look-up.
2. Read: get_customer_orders — check the customer's history for context. Still just reading.
3. Read: the agent searches your help center for your refund policy. Reading.
4. Write: create_refund — the agent has decided a refund is warranted. Stop. This is money leaving your account. In chat it surfaces a confirmation with the amount and order in view; as an autonomous capability it's something you enabled deliberately, behind an activation warning.
5. Write: Add Public Reply — tell the customer it's done. Confirm, because this reply is going to a real person.

Notice the rhythm: the agent reads as much as it likes, freely and fast, and the only moments anyone has to slow down are the two that actually change the world. That's the point of the read/write split — it concentrates human attention exactly where the risk is, and nowhere else. You're not babysitting a search; you're signing off on a refund.

Watch-outs: where confirmations help, and where they get in the way

Confirmation gates are a safety tool, not a free lunch. A few honest caveats:

• Confirmations don't fix a wrong decision — they expose it. If your agent's instructions are bad, the gate just means a human now has to catch a bad refund every time instead of cleaning it up afterward. Use confirmations to learn what your agent wants to do, tighten the instructions, then loosen the gate. Don't treat the gate as a substitute for good configuration.
• A gate on everything is a gate on nothing. If every step needs a click, reviewers go numb and rubber-stamp. Reserve confirmations for genuine writes — public replies, status changes, money, deletes. Let reads run. This is exactly why Macha auto-classifies by HTTP verb rather than gating indiscriminately.
• Autonomous write access is a deliberate decision, not a default. Letting an agent reply to every customer message without a human in the loop is powerful and occasionally the right call — but it's the setting Macha guards hardest, with an activation warning and a standing advisory. Earn your way there: run interactively first, watch what the agent confirms, then promote it.
• Read tools aren't risk-free, they're side-effect-free. A read can still surface data the agent shouldn't act on, or pull a PII-heavy record into a transcript. The read/write line is about changes to the world, not about data sensitivity — scope your connectors and knowledge sources separately.

For most teams the right starting posture is: connect read-only, run in chat, build trust, and turn on autonomous writes one capability at a time. The Macha on Zendesk setup is designed to be walked exactly this way.

FAQ

What's the difference between a read tool and a write tool? A read tool retrieves information without changing anything (get a ticket, search orders, look up a customer). A write tool creates, modifies, sends, deletes, or transacts — it has a visible side effect outside the dashboard (post a reply, update a status, issue a refund). Macha gates the write side behind confirmations.

Does Macha confirm every action? No — only writes. Read tools run inline so the agent stays fast. Write tools pause for confirmation in interactive chat, and high-impact writes show an activation warning before you enable them for autonomous runs.

How does Macha know a custom tool is a write? You set a Read / Write type when you build it, and the AI Tool Builder auto-detects: GET is treated as a read, while POST, PUT, PATCH, and DELETE are marked as write operations requiring confirmation. You can override the default.

Can an agent post replies automatically with no human in the loop? Yes, if you choose to. Sub-agents are read-only in interactive chat by default and can be granted write permissions for autonomous (trigger-based) runs. Enabling a high-impact tool or a broad trigger raises a severity-themed confirmation modal first, and a standing advisory card stays on the config page.

Do confirmations cost credits? Confirming or rejecting an action costs nothing on its own — credits are spent per AI action when a tool actually runs. See the pricing page for how credits work.

Start with reads, earn the writes

The read/write line is the cleanest safety primitive in agentic support: it tells you, for any tool, exactly how much trust the agent needs before it runs. Macha builds that line into every layer — auto-detecting write tools, pausing them in chat, and guarding autonomous write access behind explicit warnings — so you can move fast on the reads and stay deliberate on the writes.

Want to see it in practice? Start a 7-day free trial, no credit card required, connect your helpdesk read-only, and watch where your agent stops to ask. Or read the docs for the full tool and confirmation model, and browse the blog for more on building agents you can actually trust.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.