AI, usefully · 4 min read · Sep 24, 2026

Before an AI agent gets a button, give it a boundary

Imagine asking an assistant to clean up a customer list. It identifies duplicate records, explains its reasoning and offers a tidy table. You can inspect that table before using it.

Now give the assistant permission to merge those records directly.

The task sounds nearly identical. The risk is not. A mistaken suggestion can be rejected; a mistaken merge may change account history, reporting and the next message sent to a customer.

This is the point where an AI tool becomes an agent: it is no longer just producing something for a person to consider. It can take a step in another system.

The question is not simply, “Is the model accurate enough?” It is, “What happens when it is wrong?”

Start with the action, not the intelligence

Consider an assistant helping a small team manage customer accounts. It might:

1. Read account notes.
2. Identify customers who appear to need follow-up.
3. Draft an email.
4. Add the email to a review queue.
5. Send it.

Those steps do not deserve the same permissions.

Reading notes can expose sensitive information. Identifying customers can be wrong. Drafting an email is relatively easy to revise. Adding it to a queue changes someone else’s workflow. Sending it reaches a person who cannot unreceive it.

A useful design exercise is to write down, for each step:

• What can the agent read?
• What can it change?
• Who could be affected?
• How would we notice a mistake?
• Can we undo it?

If those questions have different answers, the steps should not all sit behind one broad “allow access” switch.

Give it a proposed action before an actual one

For higher-impact work, the first output should be a plan a person can inspect.

Instead of “send follow-up emails,” ask the agent to produce:

• the exact accounts selected;
• the evidence for selecting each one;
• the message proposed for each recipient;
• the records it would update;
• anything it is unsure about.

Then let a human approve the action—or change the selection.

This is a dry run. It makes the agent’s intended effect visible before the effect happens.

A good approval screen should show the difference between the current and proposed state. “Update 38 records” is not enough. Show which records, which fields and the old and new values.

Approval is only one boundary

Human review helps, but it should not carry the entire safety design. A busy person can approve a convincing-looking plan without spotting a hidden mistake.

The action tool itself can enforce limits:

The agent may draft messages, but cannot send them.
It may update a review queue, but cannot delete customer records.
It may act on accounts in the selected workspace, but not every account the user can access.

Those are permissions the system enforces, not promises in a prompt. An instruction saying “please be careful” does not restrict what a connected tool is capable of doing.

The agent should also have a limit on quantity. Sending one approved message is a different operation from sending 10,000. The same applies to database updates, purchases, refunds and public posts.

Make retries safe

Automations fail in untidy ways. A request can time out after the action succeeded but before the agent receives confirmation.

If it retries without checking, one approved action can happen twice.

For example, an agent creates a support ticket, sees a timeout and creates another. Or it issues a refund, receives no response and issues the refund again.

Before allowing an action, ask: If this step runs twice, what happens?

A system can assign each approved action a unique identifier and check whether that identifier has already been completed. It can also read the current state before retrying. The model should not have to guess whether a tool call worked.

Keep a record that explains what happened

A useful activity log answers more than “the agent ran.”

It should show the request, the plan, the evidence available at the time, the approval, the tool action and the result. If the action failed, record where it stopped.

That history helps someone repair a mistake. It also reveals patterns: perhaps the agent repeatedly selects the wrong accounts because a field is stale, not because its wording needs another prompt adjustment.

None of this requires treating every task as dangerous. The point is to match the boundary to the consequence. Drafting a note, scheduling a review and sending money are different kinds of work.

The most useful agent is not necessarily the one with the most access. It is the one that can move work forward while making the consequential decisions visible.