Which tasks or decisions are businesses ready to delegate to AI agents today, and what makes them suitable for autonomous execution?

“Businesses should first ask whether the task needs judgement at all. If a task has one correct answer that can be worked out through fixed rules, ordinary code will usually do it faster, more cheaply and more consistently. Checking whether a price falls between £10 and £100 is a good example. An agent adds little there.

“Agents are more useful where the work involves interpretation. Reading a customer’s refund request and judging the tone of the message is a better fit because no fixed rule covers every version of the request.

“Most business processes contain both types of work. Code can look up the order and check it against the policy, such as whether it falls within 30 days or under a set value. An agent can read what the customer has written, work out what they want and draft a response. Anything outside the policy should go to a person.

“Keeping agents focused on the judgement-based steps also makes their work easier to check. Each action still needs a clear boundary, a way to verify the result and a manageable consequence if it fails.”

Where should a person retain the final decision, even if an agent can complete the work faster? What would change your answer?

“Human approval should sit where an action is hard to reverse or could seriously affect someone else. Deleting data and committing significant spend are clear examples. For any decision where a mistake could cost a life, or where no margin of error is acceptable, the decision should remain with a person.

“Risk is the real test. The question is what happens if the agent gets it wrong and how much error the business can tolerate. These systems will never be right every time, so their performance has to be compared with how people perform the same task today.

“The choice does not have to be all or nothing. A know-your-customer check could use an agent to review documents and flag anything missing, while a person still handles disputed or higher-risk cases. Another option is to replace one of two human checks with an agent, so oversight remains, but the workload is reduced.

“Evidence should decide whether the boundary moves. That means repeated testing, hostile inputs, live monitoring and scoring the agent’s work for correctness and whether its answers are grounded in source data. The boundary should also be able to move back if the model changes, the data changes or the agent’s performance drops.”

How should an organisation define the limits of an agent’s authority when it can take actions across several systems?

“Scope should be the first limit. One large agent that can do everything is usually the wrong pattern. It often needs an expensive frontier model and can end up with more access than any employee would be given.

“A better approach is to break the process into smaller tasks, give agents only the tasks that need judgement and wrap them in a workflow. The workflow can handle fixed-rule steps such as routing, validation and approvals, and check what an agent proposes before anything happens.

“Each agent also needs its own identity in the systems it touches, so actions are logged against the agent rather than a shared account or borrowed user. Limits should cover which systems it can reach, what it can change and how much it can spend. Read access should be treated separately from permission to make changes.

“Tools are usually the safest way to connect an agent to a system. A tool is a narrow, defined action, such as reading a cost report or raising a ticket. The agent can only do what the tool allows, so limits on scope and spend can be enforced in one place. Start with read-only tools, then add write actions only once the agent has proved reliable.”

What happens when multiple agents pursue different goals within the same business? How can leaders detect and resolve conflicts between them?

“Most conflicts between agents can be designed out if each agent has a narrow job and reports back to an orchestration layer. The agents do not need to negotiate with each other or act directly on the same systems.

“For example, one agent might propose scaling a service down to reduce cloud costs, while another proposes scaling it up to meet a performance target. Both recommendations may make sense in isolation. The orchestrator should see both proposals, apply the priority set by the person responsible for the service and use code checks before anything changes.

“The same principle applies across teams. A person decides which goal wins, and that rule is built into the workflow. The risk is highest where agents can act directly on the same systems with nothing above them. Both may appear successful on their own measures while the service becomes less stable or the bill grows.

“Repeated changes and reversals are a clear warning sign that agents are working against each other. Leaders should monitor the overall service as well as each agent’s own measures, and the workflow should be easy to pause while the conflict is resolved.”

If an agent makes a costly mistake, how can a business establish what happened and who was responsible for approving its scope of action?

“Start with the audit trail, because it is impossible to reconstruct what was never recorded. Each agent needs its own identity, so its actions are logged against it rather than a shared account. Identity and permissions should be recorded separately. Identity shows who the agent is, while permissions show what it is allowed to do.

“The record should include the agent’s requests, its responses and every tool it calls. The system being changed should also keep its own audit log showing that the agent made the change, so the two records can be checked against each other. Sensitive details, such as personal data, can be redacted from those logs.

“Accountability should be agreed before the agent goes live. Every agent should be risk-assessed, and each risk should have a named owner. That does not mean the owner takes the blame. Post-incident reviews should still be blameless. However, someone needs to own the issue, lead the clean-up and write the post-incident report.

“Recording approval for the agent’s permissions matters as much as recording approval for an individual task. It shows who authorised the scope in which the mistake happened, as well as how the mistake happened.”

What changes to management roles and employee skills are needed when people supervise outcomes instead of carrying out every step of a process?

“Supervision only works if someone can recognise a problem and step in while the work is happening. Managers need to decide where an agent should stop and ask for help, but those points should be kept rare. If a person is asked to approve 99 actions in every 100, they are likely to miss the one that matters. Approval fatigue becomes a real risk.

“Human approval should be reserved for actions that are hard to reverse or have serious consequences. The reviewer also needs enough context to make a judgement; otherwise, approval becomes a rubber stamp.

“The skills needed are practical. People need to write clear instructions and spot when an agent is making things up. None of that works without understanding the underlying process and knowing what good looks like. Scale Factory teaches prompt engineering and related skills through its Academy, with training shaped around what businesses currently need.

“There is also a longer-term skills risk. If agents take on the routine work, junior staff may lose the experience that helps them become senior. Early-career staff should still carry out some tasks themselves, compare their results with the agent’s work, and take part in reviewing and testing agents so they build judgement.”

“Value should be measured across the whole service, compared with what it cost before. That includes the tokens the agent uses, the system around it, and the human time still needed to review or rework its output. The ongoing operating costs are easy to overlook. Prompts need refining, models need updating, and the data an agent relies on has to be kept current.

“Turnaround time matters, but only alongside quality. Customer waiting times, first-time resolution and incident rates are better indicators of whether the service has improved. Those measures should be taken before the agent is introduced, then compared over a meaningful period afterwards.

“A higher task count means little if quality falls or the total cost rises. An agent may complete its own part quickly while creating extra work for another team.

“Some benefits will not show up as simple cost savings. Agents can make routine work more consistent. In case management, for example, an agent could handle simple cases such as a standard return, while people focus on the complex cases. That can improve the service and free staff for more critical and more interesting work.”

What is the most important question leaders should ask before allowing an AI agent to move from making recommendations to taking action?

“Leaders should start with the impact of a mistake. What happens if the agent gets it wrong, can the team contain it, and who owns the risk? The agent should only move from recommending to acting once it has earned that trust through testing and comparison against how people perform the task today.

“The answer depends heavily on the job. In a financial services regulatory process, for example, an agent may be allowed to complete part of the workflow while a person still signs off the final output. That can still save a great deal of time without giving the agent full authority to publish or act alone.

“Difficult cases should be rehearsed before access is granted to live systems. Give the agent outdated information, interrupt a connected service and test what happens when an action would exceed its spending limit. Staff should be able to see what occurred, stop further action and recover where possible. Some actions cannot be recalled, including a message already sent to a customer, so those should require approval before the agent acts.

“Agent systems should be designed with replacement in mind. Models keep getting smarter, faster and cheaper. Tools move on, and frameworks are still evolving. A business may want to swap one provider’s model for another, or replace a large general model with a smaller specialist one.

What lasts is the process itself. That process needs to be mapped out and broken into steps, so any individual task can be changed without rebuilding everything around it. This also helps if an agent, model or provider becomes unavailable.

“Before reaching for an agent at all, businesses should ask whether ordinary code would do the job. If a task has one right answer, a script is cheaper, faster and identical every time. Most of the controls needed for agents are unnecessary in that case. Agents should be saved for the steps that need judgement. Once an agent is being used for those steps, the controls around scope, testing, audit trails, ownership and recovery become essential.”

.

Mike has spent the past 12 years helping organisations undertake large-scale cloud migrations and oversees Scale Factory’s AWS partnership initiatives for its enterprise cloud consulting services. He could contribute to the part of your feature concerning what happens when agents are given permission to act across live systems. His comments would focus on the technical controls businesses need to consider, including who or what can access a system, how changes are tracked and how unexpected costs are caught.