The agent demo is impressive on purpose. A vendor sets it a long task, walks away, and comes back to a finished spreadsheet, a populated CRM, or a drafted set of emails. The natural reaction is to ask "could it do that for us?" and start picturing where the saving would land.
That is the wrong first question. The useful one is quieter: what should this agent be allowed to do without checking with anyone? Until that is decided, "buying an agent" is just buying a way to make decisions faster, including the wrong ones.
This is the question we keep coming back to internally. We run scheduled agents on our own studio every working day, and the rule that has survived every change of model is the same: anything that leaves the building gets a name on it before it goes. Everything else is fair game. The interesting work is drawing that line in a way the team can live with.
Risk and reversibility set the permission
Most agent buying conversations stall on a single axis: how capable is it. That is a tooling question, and tooling moves quickly. The line worth drawing for your own business sits on two different axes.
The first is risk. What is the worst case if the agent gets it wrong? A miscategorised email is mild. A refunded order is more serious. A deleted database row is very serious. A message sent to a regulator on your behalf is in a different league.
The second is reversibility. If the agent gets it wrong, how cheaply can you undo it? Some actions can be rolled back inside a minute. Some can be rolled back if you notice in the next hour. Some cannot be rolled back at all.
Plot those two together and the picture clarifies. Low risk and easy to reverse: grant autonomy. High risk and irreversible: gate it. The interesting decisions live in the middle.
What is safe to grant without asking
The actions worth granting blanket permission for share four properties. They are repeated, they affect only internal state, they are easy to inspect after the fact, and they can be undone without anyone outside the team noticing.
Reading falls here. An agent that reads your inbox, your tickets, your project tool, your codebase, or your documents to summarise or classify them is not making a consequential change. It is making sense of work that already exists. The risk lives in what it does with the reading, not in the reading itself.
Classifying falls here. Labelling, tagging, grouping, deduplicating, sorting into queues. The output is information that a human then acts on. If the classification is wrong, the correction is a relabel.
Drafting falls here. Writing a first version of a reply, a brief, a code change, a summary, a proposal. As long as the draft sits in a place where a person sees it before it goes anywhere, the agent has saved time without taking the decision.
Queuing and notifying fall here too. Putting an item in front of the right person, raising an internal ticket, posting a message to the team's own channel. Internal nudges are reversible and the worst case is mild noise.
Most of the day-to-day usefulness of an agent lives in this quadrant. Our own scheduled agents spend almost all their time here. They sort inbound work, group repeated errors, draft suggested fixes, prepare project summaries, and surface things that look unusual. Nothing in that list needs a human approval click. It just needs a person to read the result.
High-risk actions always need review
At the other end sit actions that change the world outside the team, cost money, or cannot be cleanly undone.
Sending. An email to a customer, a message to a supplier, a reply on a public channel, a comment under someone's social post. Once it is gone, the agent's mistake becomes the business's mistake. Drafting is fine. Sending is not.
Publishing. Pushing copy live on the site, releasing a product update, posting an announcement. These are public commitments and need a person's name on them.
Spending. Authorising a refund, raising a charge, triggering a payment, buying credits. Money should never move without a human in the loop. This is the line where convenience starts costing trust.
Deleting. Removing records, archiving customer data, dropping a database row, wiping a file. Delete is the most irreversible operation on the list. Even a tidy delete can land badly if the customer asks for the record back.
Committing code to production. Drafting a pull request is fine. Merging it is a different action with different consequences. Our code review assistant happily proposes changes; nothing merges without a human review.
Communicating with anything regulatory. A reply to an ICO request, a tax filing, a legal notice. The accountability there is named in law. Hand it to a human.
If an agent demo glosses over this list, that is the most useful thing you have learned about the product.
Most useful work needs conditional approval
The interesting decisions are not at the extremes. They are in the middle: actions that are medium risk, or partly reversible, or that depend on context.
Booking a call into a shared calendar. Updating a CRM record. Closing a ticket. Granting access to a shared folder. Posting an internal report to a wider audience than usual. Renaming a file that other people link to. Restocking from a default supplier.
Default to ask. Then, as the team watches the agent work for a few weeks and the failure modes become known, move individual actions out of the asking pile and into the granted pile, one at a time. Not in batches. Not as a setting called "trust this agent". One action, with a written reason, reviewed after a month.
That sounds slow. It is. It is also the only way to grant autonomy that does not require taking it back later with apologies.