Autonomous AI agents: how much freedom to give one

Autonomous AI agents can handle work without waiting for instructions at every step. They can read documents, organise information, compare records, prepare reports and draft responses. The harder decision is how far they should be allowed to go before a person steps in. An agent that can prepare a supplier payment is useful. One that can send the money without permission is a different proposition.

We think autonomy should be treated as a dial, not a switch. The right setting depends on the job, the consequences of a mistake and the evidence an agent has built through previous work. A research task might need very little supervision. A task involving customer records or an external payment needs tighter limits. The aim is to give an agent enough freedom to finish useful work while keeping consequential decisions in human hands.

Start with the consequences of an action

A common mistake is to decide how much autonomy an agent needs based on how complicated its instructions look. A long research assignment can be relatively safe to delegate. A short instruction to change a bank account detail can carry serious consequences. The number of steps tells you little about the amount of freedom an agent should have.

Instead, look at what happens if the agent gets something wrong. Reading an invoice incorrectly is a problem that a person can catch during review. Sending the wrong payment creates a problem outside the workspace. Drafting an email with an inaccurate statement is recoverable. Sending that email to a client is harder to undo.

This distinction gives you a practical starting point. Let the agent do work that produces material for inspection. Keep a person involved when an action changes something another person, company or system will experience.

The important detail is that the same agent can have different permissions within one assignment. It might be allowed to read every invoice in an approved folder, match them against purchase records and prepare a payment list. That does not mean it should be allowed to submit the payments.

Give each job its own autonomy setting

An organisation does not need one universal permission level for every agent. A research analyst and a bookkeeper have different jobs, access different information and create different risks. Even two delegations to the same agent can justify different limits.

Consider an inbox triage assignment. The agent can read incoming messages, identify their subjects, group them by urgency and prepare draft replies. It may also suggest which messages need attention first. If the assignment is limited to preparation, there is little reason to interrupt the agent every time it classifies a message.

Now consider an outreach assignment. The agent can research a potential contact, prepare a personalised introduction and check the draft against the brief. The first message to someone outside the workspace should still wait for approval. The research and writing can happen independently. The first contact cannot.

For each job, write down three things before starting:

• What the agent may do without asking, including the files, tools and records it can access.
• What it may prepare but cannot execute, such as payment instructions, external messages or proposed record changes.
• What it must never attempt without a fresh human decision, including actions outside the agreed assignment.

This makes the permission setting specific enough to use. An instruction such as 'handle the inbox' leaves too much room for interpretation. 'Read messages in this folder, label them, prepare reply drafts and leave all sending to me' gives the agent a defined job and gives the owner a clear review point.

Budgets limit how far a run can go

Permissions control what an agent can do. A budget controls how much it can spend while doing it. Both matter because an agent can stay within its action permissions and still consume too much time, tool usage or paid resources.

Set a hard budget for every delegation before the work begins. The limit should reflect the expected size of the task, not the amount you happen to have available. A short competitor research brief does not need the same allowance as a detailed report covering several markets. If the agent reaches its cap, the run should stop and wait for a decision rather than quietly continuing.

A budget also changes how you write the brief. Tell the agent what a completed result should contain and what it should do if it cannot finish within the limit. For example, a research analyst might be instructed to prioritise the five most relevant sources, record unresolved questions and stop if further research would exceed the budget.

This is better than giving an open-ended instruction to keep researching until the answer feels complete. The owner gets a defined piece of work, and the agent has a clear stopping condition.

Put checkpoints where mistakes become expensive

A checkpoint should appear at the point where an agent is about to cross a boundary. Asking for permission after every search or classification creates needless interruptions. Asking only after an external action has happened defeats the purpose.

The most useful checkpoint is one that gives the reviewer enough information to make a decision without reconstructing the entire assignment. The person should be able to see the proposed action, its likely effect, the cost so far and the time available to respond.

For example, imagine an agent preparing a refund. It has checked the relevant order, matched the customer's request against the refund policy and calculated the amount. The next step is to issue the money. That is where the run should pause. The reviewer can check the amount and the underlying record before approving, changing or rejecting the proposed action.

We built the Delagents approvals inbox around this kind of decision. Actions that affect anything outside the workspace wait for a human sign-off. Each approval card shows the exact proposed action, the cost so far and a deadline. A person can approve it, change it or reject it.

Some boundaries should remain fixed, regardless of how well an agent performs. First contact with someone outside the workspace, moving money, deleting or overwriting records the agent did not create, changing roles or its own policy, widening integration access, accepting terms, publishing publicly and acting in another workspace all require a person.

These are not routine interruptions to be removed after a few successful runs. They are decisions with consequences that belong to the person responsible for the work.

Expand freedom only after reviewing the work

An agent should not receive broader permissions simply because it has completed several assignments. The owner needs to know what went well, what needed correction and how the agent behaved when instructions were incomplete.

Look at completed deliverables alongside the activity behind them. Did the agent follow the brief? Did it stay within the budget? Were its classifications and matches accurate? Did it flag missing information instead of filling gaps with assumptions? Did it stop at the agreed checkpoints?

The last question deserves particular attention. An agent that notices uncertainty and asks for help is often easier to trust than one that produces a confident-looking result from incomplete information.

Keep a record of corrections and recurring problems. An append-only activity log can help an owner inspect tool calls, approvals and policy changes in the order they happened. It gives the reviewer something concrete to examine when deciding whether a particular permission should change.

When the evidence supports more freedom, expand one permission at a time. If an inbox triager consistently sorts messages accurately, you might let it handle another approved category of messages. That does not automatically justify giving it permission to send replies. A successful research assignment does not prove that the same agent is ready to change customer records.

Keep the previous limits until the new setting has been reviewed. If the agent starts making avoidable mistakes, reduce its freedom and examine the instructions, available information and access it received. Sometimes the problem is a poorly defined brief rather than an unreliable agent.

Choose one job and set its limits today

The easiest way to test an autonomy policy is to start with a job that already has a clear output. Inbox classification, meeting preparation or invoice matching are reasonable candidates because the work can be inspected before anything consequential happens.

Write a brief that names the expected deliverable, the information the agent may access and the actions it may take alone. Add a hard budget. Then identify the first point at which the agent must stop and ask for approval.

For the first run, keep the permission boundary narrow. Review the finished work, check the activity log and record any corrections. If the agent followed the brief and produced work that needed little intervention, consider one small increase in autonomy for the next assignment.

Pick one recurring task on your team's list this week. Define what the agent can read, what it can prepare and which single action must remain with a person. That first boundary will tell you far more about the right level of autonomy than giving an agent unrestricted access and hoping it behaves.