Before You Build an AI Agent, Decide What It Should Be Allowed to Do

When you build an AI agent, you usually have a specific outcome in mind. You work out what it needs access to, give it instructions, and start seeing how well it can do the job. But along the way, you also need to decide how much authority you’re giving it. What should it be allowed to do on its own, and when should it come back to you?

This has come up in both my personal agents and the agents we’ve deployed into production at Opreto. Last month, my car lease expired. I needed a new car and didn’t have time to go through the whole rigmarole myself, so as an avid openclaw user I obviously created an agent. I instructed it to find dealerships within 90 kilometers of my home that carried the brands and models I wanted, reach out through email and website contact forms, and run the conversations from its own email address and phone number. Along the way, it would maintain a database of offers, and an internal criterion I had set to help compare them. I gave it a pretty clear requirement: I didn’t want to talk on the phone. Email or text was fine, because the agent could handle both itself.

It was able to get me full quotes from more than 10 dealerships on more than 20 cars. That’s a lot of searching, outreach, and back-and-forth that I didn’t have to do myself. But some of those conversations got ridiculous. Many of the dealers would push for a live conversation. Others wanted information to open a sales file, such as my full name or driver’s license number. The agent had my instructions, and it kept trying to move the conversation forward within them. The dealer wanted something else. The follow-ups got pushy, and the conversation went in circles.

Quickly, I realized that I needed to change the instructions.

When it hit that kind of situation, it needed to come to me for an answer. It could still search, reach out, answer messages, and collect quotes. What changed was its authority to keep handling a conversation when the next step required a decision from me. This required some of my personal intervention, but it also helped move things forward more quickly overall. In the end, I bought a car that had been negotiated through the agent. Even with those approval gates in place, it saved me dozens of hours and many trips, phone calls, and text messages.

That’s the distinction between capability and authority, and it matters to anyone considering bringing agents into their business. At Opreto, our agents connect to our CRM, project management tools, shared folders, wikis, and much more. There’s a lot of power in giving an agent access to the systems where work actually happens. That access also makes it important to define where its authority ends. An agent might be able to send an email, update a customer record, or change a project deadline. Whether it should be allowed to do those things independently depends on the situation. Simply having a tool available doesn’t settle that question.

The car agent had the tools it needed. It also had a goal. What I hadn’t defined clearly enough was when it should stop pursuing that goal and bring a decision back to me. If you’re deciding where to introduce AI in your business, work through that boundary before choosing tools or committing to a build. It affects the permissions you’ll need, the workflow you’ll design, and how much work a person will still have to do. Those details belong in the decision about whether the project is worth doing. A useful starting point is to put every action on a spectrum of risk.

• Lower risk: retrieving information, summarizing, classifying, and drafting something for review.
• Medium risk: updating internal records, creating tickets, scheduling meetings, or triggering workflows that can be reversed.
• Higher risk: sending external communications, spending money, deleting data, changing permissions, or making decisions that affect customers.

Those are starting points. The details can move an action from one category to another. Adding a note to a CRM record is different from changing a deal value that feeds a forecast. Scheduling an internal check-in is different from moving a customer’s implementation meeting. A summary can become consequential if another system uses it to make a decision without review.

Even sending an email needs context. My car agent was allowed to contact dealerships directly. Requiring me to approve every routine message would have significantly reduced its value. But when a dealer pushed back on my requirements or asked for information that needed my input, human in the loop was perfect. The boundary depended on what was happening in the conversation.

Reversibility matters too. If the agent is wrong, can we undo what it did? A draft email is easy to change. Once it’s sent, someone else has read it, formed an impression of it, or acted on it. You can send a correction, but you can’t undo the original interaction.

The same applies to agents setup to automate business tasks. A record might be editable, but changing it could trigger another workflow before anyone notices the mistake. Being able to restore a field doesn’t necessarily reverse everything that happened afterward. So the question is bigger than whether there’s an undo button, how far can the mistake travel, and how much work would it take to recover?

This is also why human approval belongs in the design. An agent coming back with a question can be exactly the right outcome. In the car search, I needed to decide whether to make an exception to my preference for email and text, provide information, or leave that dealership alone. Asking me at that point still left the agent doing the bulk of the work. The useful design question is where a person’s judgment is worth the interruption. Asking for approval on every step creates a bottleneck. Never asking leaves the agent trying to make decisions that it hasn’t been authorized to make.

That human work also belongs in economics. How long does the task take today? With the agent involved, how much time is spent reviewing its work, responding to escalations, and fixing mistakes? Measure the completed workflow against the starting point. Counting the actions an agent takes won’t tell you whether it has actually saved anyone time.

That authority should be specific. Which systems can the agent access? What data can it see and share? Which actions can it take? Are there dollar limits? Which situations require escalation? Which actions always require approval? For my car agent, changing the instructions helped address the behavior I was seeing. In a business system, consequential boundaries should also be enforced through permissions and approval steps. If an action always requires approval, the system should require that approval before executing the action.

Confidence can inform these decisions, but it doesn’t settle them either. An agent saying it’s 95% confident doesn’t establish that it will be right 95% of the time. And even if you’ve measured its performance and found it reliable, you still have to consider the cost of the remaining mistakes. An occasional incorrect label on an internal note might be manageable if it’s easy to catch and fix. The same error rate on changes to customer billing information would be a very different proposition.

Autonomy needs to account for both the likelihood of an error and its consequences. It also needs to account for whether you’ll notice the error in time to do anything about it. That means defining an escalation path before the agent gets stuck. Missing information, conflicting records, ambiguous requests, policy conflicts, and requests outside its scope should all have somewhere to go. When it escalates, the agent should bring enough context for someone to make the decision: what happened, what it has already tried, what’s blocking progress, and what answer it needs. Otherwise, the person has to reconstruct the whole task before they can help.

You also need to be able to inspect what happened. What did the agent do? What information did it use? What reason did it record for the action? Did the action succeed? Who approved it, if approval was required? What would recovery involve? Logging those details gives you a way to investigate mistakes and adjust the boundaries. Without that visibility, it’s difficult to know whether the agent needs better information, narrower authority, or a different workflow.

Before giving an agent authority over an action, I’d work through these questions:

1. What exactly is the action, and what data and permissions does it require?
2. What happens if it’s wrong?
3. Can we reverse it, including anything it triggers?
4. How reliably and quickly can we detect a bad decision?
5. Can it act independently, or does someone need to approve it?
6. When should it escalate, and who will answer?
7. With review and recovery included, is this still an improvement over how we work today?

The greater the consequences and the less reversible, the less autonomy the agent should have. My car agent helped me buy a car and saved me dozens of hours, even after I added approval gates. It handled the searching, outreach, and back-and-forth, and brought me in when a decision needed my input. That’s a level of autonomy I’d happily use again.

As agents get access to more of our businesses, deciding where they can exercise judgment becomes a bigger part of the work. We need to be deliberate about what we’re delegating and which decisions we’re keeping. The best agent isn’t the one who does the most without asking. It’s the one that knows when to act, when to ask, and when to stop.