How to set limits on what an AI agent can do alone

The wrong thing to measure first

For an owner-operator running invoicing and customer replies through an agent, it is tempting to decide how much freedom to give it based on how well it performs in testing. A piece on enterprise AI governance at kuzmanko.com argues against that instinct directly: granting autonomy according to how competent an agent looks is not a serious standard. The agent does not need to hallucinate to cause damage. It can follow an imprecise instruction exactly as written and still do the wrong thing, at full speed, before anyone reviews it.

There is a distinction worth settling before any of this matters: whether what you are running is fixed-step workflow automation or an agent making its own calls about what to do next. We have written separately about how workflow automation differs from agentic AI. The limits in this piece apply to the second kind, the one deciding on its own, not the first.

Sort every action by how hard it is to undo

The kuzmanko.com piece frames this as recoverability instead of confidence: an agent should get more freedom for actions that are cheap to review and reverse, and less freedom for the ones that are not. In a software team that means the difference between drafting a pull request and running a command that deletes production data. In an operationally heavy small business, the same split applies to different things.

Low-risk work includes drafting a reply to a customer question for someone to send, or flagging an overdue invoice for review. High-risk work includes issuing a refund, or canceling a confirmed booking. The first kind is reversible inside a few minutes. The second touches money or a promise already made to a customer, and undoing it means another conversation, sometimes an uncomfortable one.

Widen the boundary one task at a time

The instinct, once an agent handles a handful of low-risk tasks well, is to open the door wider all at once. That same piece warns against the opposite mistake too: requiring a person to approve every single step quietly kills the reason to automate in the first place. The answer sits between those extremes. Widen the boundary one task at a time, and only after the agent has run that specific task enough times, with a person checking the output, to know where it tends to go wrong.

This is slower than either extreme, and that is the point. A booking confirmation email can earn unsupervised status after weeks of correct drafts. A refund does not earn that status just because the email did. Each action keeps its own record, because being right about one kind of task says nothing about being right on a different one.

Put the checkpoint in the system, not in your memory

Remembering to check on an agent does not hold up past a handful of tasks, so the approval step needs to live inside the workflow itself. Nutrient's approval agent, built for enterprise document review, offers a useful shape for this even outside that setting: it checks a request against a set policy, recommends approve, deny, or escalate, and logs the reasoning behind every decision. Escalation happens automatically when something falls outside the policy, not when someone remembers to look.

Microsoft's Copilot Studio documentation describes a similar pattern for agent flows, combining manual approval stages with AI approval stages inside one process, so routine requests clear on their own while anything unclear stops for a person. The lesson for a small operator is not to copy either product. It is to write the policy down before the agent runs: which dollar amount needs a yes, which change to a listing or a price needs your initials. An agent without a written policy is not being supervised. It is being trusted without a reason.

How we draw these lines in our own operation

We run 197 scheduled jobs across 78 live integrations for our own operation, covering 30 projects in production and content in 7 languages. Not all of it runs unsupervised. Some jobs post content, answer routine questions, or update a report without anyone in the loop, because a wrong output there is a bad paragraph fixed on the next run. Others touch a customer directly, send money, or change something live on a site a client depends on, and those get a checkpoint first.

This is also why we map the manual process before building anything: we want to know, task by task, what a system can own outright and what still needs a person, and we say so plainly rather than guessing. We have written before about what happens when an autonomous agent makes a mistake and about where agents tend to fail once they touch real systems, and the same answer shows up both times: the failure is rarely the model being wrong. It is a missing checkpoint at the one step where being wrong was expensive.

One thing to check this week

List every recurring task your agent, or a person following a script, currently completes without anyone looking at it first. Next to each one, write down what it would cost you, in money or in an awkward phone call, if that specific task were done wrong once. Our answers library breaks this down by business type if you want a starting list for yours. Anything above a cost you would not want to explain to a customer needs a checkpoint before its next run, not after.