Not which AI. How much you let it decide

Most conversations about AI start with the model. Which one is smartest? Which scored highest? Which subscription should we buy? Those questions matter, but they leave out a more practical one: what will this system be allowed to do?

An incorrect draft waiting on your screen and an incorrect invoice already sent to a customer create different problems. The model could be the same. Its permissions changed.

That is the starting point I use when thinking about AI in a business.

Four levels of authority

I find it useful to separate four practical levels. They describe what a system may do, rather than how intelligent it is.

A paid subscription can give you a more capable model at any of these levels. It does not, by itself, give the system more authority. Equally, a team of agents can still require approval before anything is sent or changed.

Take a customer asking about an order. At level one, AI helps you write a reply. At level two, it looks up the order before drafting. At level three, it sends the reply you approve. At level four, it sends routine updates on its own and passes unusual cases to a person.

The levels are not fixed risk ratings. Bad advice from a chatbot can be costly if someone acts on it. A narrow, reversible action may be suitable for automation. What matters is the consequence of the mistake, how often it could happen, and whether you can catch or undo it.

Choose the task before the tool

A chat window can show you how well a model writes. It cannot tell you whether a connected system will find the right customer record, follow your rules or update an account correctly.

Start with one piece of work you want to improve. Define a good result and decide which actions need approval. Then choose the model and connections that can support it.

Capability is moving quickly

It is easy to dismiss AI because of something it failed to do last year. It is just as easy to give it too much freedom after one impressive demonstration.

METR's research shows why regular reassessment matters. Its January 2026 update estimated that the length of technical tasks frontier models could complete at 50 percent success had doubled roughly every seven months across the historical period since 2019. Estimates for more recent periods were faster, but the researchers also showed that the task mix affects the trend.

That is evidence of progress. It is not a promise about your company's work.

Reliability needs its own test

The reliability figure is part of the result. A five-hour horizon at 50 percent success would mean an estimated even chance of completing tasks of that difficulty in the benchmark. It would not mean five dependable hours of autonomous work.

METR measures difficulty using the time a human expert needs. Its tasks are mainly clearly specified software, machine-learning and cybersecurity work. The researchers explicitly caution against reading those scores as a measure of all business tasks.

Another METR study makes the gap concrete. In an August 2025 evaluation using 18 software issues, one agent setup averaged 38 percent success on automated tests. Yet none of the 15 submissions manually reviewed was ready to merge unchanged. The reviewers estimated that even submissions passing the tests needed further work. This was a small study of an older model and a particular setup, not a verdict on every agent today.

The lesson for a business is to test the finished job. Does the reply use the right account? Is the invoice correct? Did the system make an unwanted change? A result can look complete while failing the check that matters.

Longer workflows need checks along the way

A mistake can also become the starting point for the next step. Research published at ICLR 2026 found that models became more error-prone when earlier errors remained in their context. Larger models alone did not remove that effect, although the paper also found benefits from reasoning and scale.

The original 2025 Vending-Bench study found a related problem in a simulated vending business. Every tested model had some runs that went badly off course, including missed orders and misread delivery schedules. Some also ran the business successfully.

For me, the practical response is to build checks into the workflow. Confirm the customer before preparing a reply. Check an amount before issuing an invoice. If the system cannot establish something important, give it a clear way to stop and ask.

What robotaxis show about handing over control

Robotaxis offer a useful example of how a company decides where autonomous operation is appropriate. Waymo describes a process built around testing and the conditions in which its system is designed to operate, including geography and road conditions. It says major expansions and safety-relevant changes require a fresh assessment.

I would apply that principle to business automation: prove a limited use case, monitor it, and assess the next expansion separately. Removing the driver from a vehicle does not mean removing the wider system of oversight. Nor does letting an agent send routine updates mean letting it negotiate prices.

The aim is to establish where independent action is justified. Human approval can remain part of the design wherever the consequences call for it.

Which level fits your work

Choose the least authority that makes the task useful. Different steps in the same process can sit at different levels.

• For a one-off draft or analysis, start at level one. A more capable model may help without any new system access.
• For repeated work that needs your documents or records, test level two. Compare the time saved with the work of checking answers and maintaining the connection.
• For a repeatable action you still want to approve, use level three. The approval should show exactly what will happen, including the recipient, amount or record being changed.
• For routine work with clear rules and manageable consequences, consider level four. Set limits, record the actions, and make it possible to pause the process and recover where practical.

If a mistake would be expensive, keep the relevant approval. For example, an agent might gather order details and prepare a refund automatically, while a person authorises the payment. You can save work without handing over the final decision.

Earn more authority through evidence

Before expanding permissions, run the system on representative cases from your own work. Include awkward cases and missing information. Measure the time spent checking and correcting, as well as the time saved.

Then move one boundary at a time. Let the system read before it can write. Have it prepare actions before it executes them. Keep review on the steps where an error would matter most.

That is how I approach an AI project. The model matters, but the design of its permissions and checks determines how its abilities become useful in your business. The project stages are on my method page.

For the connected-system approach, read software built for agents. If you already have a process in mind, explore the AI agent team service.

A note on the research: the findings below describe particular tasks, models and dates. The four levels are a practical framework for choosing permissions, not an industry standard.