1. Task automation is not workflow delegation
Asking a model to turn meeting notes into three key points is task automation. The input and output are relatively clear: provide text and receive text. Even if the result needs editing, the error usually remains inside the document. Give the same notes to a system that can read calendars, find project documents, decide which items require follow-up, create tasks and notify the people responsible, and the arrangement becomes workflow delegation. The system must retain context, choose tools and decide whether to ask a question, skip a step or escalate when information is missing. It must also produce effects beyond its own interface.
In its discussion of agentic systems, Anthropic deliberately distinguishes two architectures: workflows, in which models and tools follow predefined code paths, and agents, in which the model dynamically directs its own process and use of tools. [3] This is a useful distinction because the word 'agent' often collapses very different degrees of automation into one category. A fixed extract-validate-write sequence and a system that can choose its own search scope, call interfaces, retry and revise its plan may both use tools, but their risk structures are quite different.
The decisive question is not whether the interface contains a chat box. It is whether the object of work has changed from a single action into a stateful process. Workflow delegation introduces at least three changes.
First, the system has to manage state. A customer service assistant needs to know whether an order has already been refunded and whether the customer has already received an exception under the policy in the past 30 days; otherwise, it may refund the same payment twice. Second, the system has to manage branches. Replenishment, replacement and refund follow different paths when stock is unavailable. The model must match the facts to policy rather than merely generate an explanation that sounds plausible. Third, the system creates side effects. Writing back to a CRM, sending an email, closing a ticket and changing permissions are all actions on which other people may rely. Incorrect prose can be rewritten. An incorrect payment has to be recovered.
This is why gains in local speed can so easily create the wrong impression. Participants in the Copilot experiment completed a clearly bounded programming task, and the study's abstract reported that the treatment group was 55.8% faster than the control group. That finding shows that code production accelerated for that task and that version of the tool. It does not show that testing, review, deployment and maintenance accelerated by the same proportion. [2] The NBER customer support study likewise observed a productivity change inside an existing business system; it did not place an agent in a completely open organisational environment. [1]
Long workflows also magnify small errors. In its evaluation of long software tasks, METR used the time a human would need to complete a task to predict model success rates, and found that models had lower success rates on longer tasks. [4] That result does not directly establish why failures occur, but it offers organisations an engineering warning: as workflows grow longer, teams cannot substitute a one-step demonstration for end-to-end validation. A process with eight steps, each of which appears to work reasonably well, is not necessarily capable of delivering a reliable final result. One extra search, one misread field or one outdated policy mistaken for the current one can send every later step in the wrong direction. Human employees also make mistakes, but organisations generally know who acted and on what basis. Without records, an agent's error can be as difficult to reconstruct as a trail of unattributed clicks.
The first step, then, is not to give every department an 'autonomous agent'. It is to map the real workflow: where inputs come from, which actions alter external state, which judgement cannot be reversed, and who should be contacted when something exceptional occurs. Conventional automation or a templated workflow is enough where the process is fixed, errors are reversible and data sensitivity is low. Letting a model participate in planning is worth considering only where rules cannot be exhaustively specified and evidence must be gathered dynamically. Calling task automation workflow delegation expands permissions before the organisation has prepared an evidence trail.
2. When AI takes over execution, the location of judgement must be designed deliberately
With earlier assistants, a person's main actions were to pose a question, read the answer and decide whether to use it. A workflow agent changes that sequence. It may first decide which email has priority, which policy applies and which customer needs escalation, then present a conclusion that has already passed through several steps. If the person merely clicks 'approve' at the end, it is difficult to know which alternatives have already been filtered out and which judgements the system has already made.
This does not mean that human judgement will naturally move upstream, nor does it mean that judgement must disappear. The more precise claim is this: once AI takes over more execution steps, the organisation must decide where judgement remains. At a minimum, three kinds of judgement should be made explicit in the workflow: people define the objective, people set the boundaries of delegation, and a named accountable person handles exceptions. The objective is not simply to close the ticket; it also includes maintaining customer trust, complying with contracts and retaining evidence that can be explained. A boundary is not merely a word count or format. It defines which data may be read, which actions may happen automatically and when customers must be told that AI has been used. Exceptions arise where policy is incomplete: a customer supplies new evidence, an order involves a minor, or the system detects possible account theft. Any one of these conditions can turn the most common path into the wrong one.
Research by the International Labour Organization (ILO) on the occupational effects of generative AI predicts that the technology is more likely to augment occupations than to automate entire occupations. [5] That conclusion places a useful boundary around the discussion: a role does not necessarily disappear merely because several of its actions become faster. But the abstract does not show that decision-making authority moves upstream in real organisations, and it does not decide for any team which actions require human approval. A job title may remain unchanged while authority within the role shifts through interfaces, defaults and permission settings. That is an organisational design question to investigate, not a universal outcome already observed by the ILO study.
Consider a recruitment process that uses a model to organise CVs. The model can extract skills, arrange candidates against job requirements and even draft interview invitations. The recruitment team still has to decide whether those requirements are fair, which information should be excluded from ranking, how candidates can appeal, and whether the model's recommendations reproduce past bias. If people examine only the three highest-ranked candidates, review can shrink from independent judgement to rubber-stamping. Alternatively, the team could set rules such as: 'The model may organise information but may not reject a candidate; every rejection must have a readable reason; missing information must never be filled with a guess.' No principles document has validated this as the best process. It is one way to turn the question of which judgements people retain into rules that can be inspected.
The OECD AI Principles place human-centred values and fairness, transparency and explainability, robustness and safety, and accountability within the same set of principles, while also calling for continuous risk management of AI systems. [6] These are normative principles, not field research on how decision-making authority changes. In day-to-day work, they can be translated into governance questions. When a model's recommendation changes how a customer is treated, can the accountable person explain what informed it? Who notices when the system's information is out of date? If an employee disagrees with a model's ranking, is there a route for review that does not depend on the model? The organisation still has to supply the specific answers.
Without deliberate design, interfaces and defaults can also delegate judgement to the system implicitly. An interface may give 'accept' the most prominent position and hide 'view original evidence' one level down. Even when a person makes the final click, that does not mean they have fully examined the preceding reasoning. Pre-filled justifications, actions selected by default and displays that present only one option all narrow the choices the reviewer actually sees. Formal final approval may remain with a person while the substantive trade-offs have already taken place in the model output and product design.
The NBER results show that, on average, AI provided greater help to novice and lower-skilled workers, with little effect on experienced and highly skilled workers. [1] The study demonstrates heterogeneous gains in a particular customer support environment and suggests that the practices of high-performing workers may be transmitted to novices. It did not directly measure whether novices treated suggestions as judgements, still less establish where authority moved within the organisation. The question advanced here is therefore one for teams to test: can employees inspect the basis of a suggestion, offer counter-evidence and reject it, rather than merely approve it more quickly?
One division of labour that organisations can test is to separate what a model may propose from what it may decide. A model may propose a ranking of candidates but may not decide on rejection by itself. It may generate a recommendation from approved refund rules but may not issue a payment automatically above a threshold. It may classify fault logs but may not change production configuration without confirmation. People, in turn, need to practise more than prompting. They need to verify assumptions, look for missing evidence and explain trade-offs. This arrangement does not emerge automatically when a model is deployed. It has to be established deliberately through policy, permissions and interface design.
3. Authority to act and the evidence trail determine the shape of risk
Moving AI from 'advice' to 'execution' may technically require only one additional API permission. In governance terms, it is a qualitative change. Reading a public knowledge base is not the same action as reading a customer's health record. Drafting an email is not the same action as sending an email on behalf of a company. Once permissions are granted, model errors cease to be only content errors. They can become data disclosures, contractual commitments, incorrect payments or records that cannot be undone.
An agent's tool inventory therefore has to be written alongside its responsibility inventory. Every action should answer at least five questions: what data does it read, which system does it write to, on whose behalf does it make a change, can that change be reversed, and what evidence remains afterwards? Giving every tool the same administrator account is convenient. But if independent invocation identifiers and application-level logs are also absent, a shared privileged account makes it difficult for an audit to distinguish whether the model, an employee or a script performed the action. Least privilege is a better design: the agent sees only the fields required for the current step, can call only specified interfaces, and may act only under low-risk conditions. Once a threshold is crossed, the task goes to a named accountable person.
The EU Artificial Intelligence Act places these concerns within the institutional requirements for high-risk systems. Article 12 requires logging, Article 13 requires sufficient transparency information for deployers, Article 14 provides for human oversight, and Article 26 sets out deployers' obligations in use and monitoring. [7] These provisions do not mean that every internal chatbot is automatically a high-risk system. They do make one point clear: a system capable of affecting people cannot be delivered as a model file alone. It also requires logs, instructions, oversight and responsibility for its use.
Suppose a finance agent processes supplier invoices. It can extract an amount from an email, compare it with a purchase order, and place invoices below £1,000 that match exactly into a payment queue. If the amount does not match, the account has not appeared before or contractual terms are missing, it may create a task but may not make the payment. Each execution must retain the hash of the original attachment, the policy version used, the model output, the interface called, the identity of the approver and the final outcome. If an anomaly appears at the end of the month, finance staff do not have to guess why the model acted as it did. They can follow the evidence trail back to the relevant fields.
NIST's AI Risk Management Framework (AI RMF 1.0) organises risk work around Govern, Map, Measure and Manage, and states that the framework is intended to help organisations incorporate trustworthiness considerations when designing, developing, using and evaluating AI systems. [8] In operational terms, those four terms mean first establishing who is responsible, then understanding the business context in which the system operates, measuring real performance and disparities, and finally adapting or stopping the system in light of the results. The framework's value does not lie in providing a one-size-fits-all template. It reminds teams that risk is not a single pre-launch review but an ongoing activity as data, models and processes change.
The UK government's AI regulation white paper sets out five cross-sectoral principles: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; and contestability and redress. It also emphasises implementation by existing regulators in context. [9] The lesson for organisations is that AI governance should not be handled through a new process entirely detached from procurement, information security and customer complaints. An agent's permissions, logs and shutdown conditions should be embedded in existing approval, audit and incident-response systems.
Nor is it an answer to require a person to confirm every action. If a low-risk, reversible formatting change triggers a pop-up at every step, employees will soon learn to approve on autopilot or turn to personal tools that nobody can see. Permissions should be tiered by impact, reversibility, data sensitivity and external commitment. A summary of a public web page might automatically be published as a draft. An email concerning compensation requires human review. Changing production data, making a payment or adopting a legal position requires higher-level approval and a two-person review. The aim is not to have people watch the agent continuously. It is to prevent high-impact actions from occurring without evidence and an accountable person.
4. Skill development is a risk to monitor; responsibility is an organisational choice
When repetitive actions are delegated to AI, organisations need to monitor one risk scenario. If junior customer service staff no longer handle simple tickets, junior engineers no longer fix small defects themselves, and new operations staff see only the emails that a system has already filtered, they may receive fewer opportunities to practise the independent judgement they need. The word 'may' matters. Neither the existing NBER customer support study nor the Copilot experiment directly measured skill development years later, and neither established that long-term deskilling has already occurred. This article treats deskilling as a risk because delegation changes a novice's access to the complete process. Whether development actually slows must be tested with subsequent organisational data.
The NBER customer support study found that the tool helped novice and lower-skilled workers substantially more than experienced workers, and suggested that AI might disseminate the practices of more experienced colleagues and help novices move along the experience curve. [1] This is a positive result, and it warns against assuming that AI must weaken skill. The study did not, however, answer two long-term questions: did novices understand the conditions behind the suggestions, and could they still exercise independent judgement without the tool or when encountering a novel exception? Organisations cannot infer from improved short-term output that capability has already developed. Nor can they treat skill erosion as an established fact.
The Copilot experiment draws a similarly local boundary. Researchers asked developers to implement a JavaScript HTTP server as quickly as possible, and the treatment group was 55.8% faster than the control group. [2] The experiment did not cover requirements clarification, architectural trade-offs, code review, production monitoring or incident repair, and it did not track participants' later rate of learning. It therefore proves neither that the entire software engineering process will accelerate by the same amount nor that users will lose their ability to debug or design. It leaves a more useful question: as local output becomes faster, is the team still observing people's ability to verify results and handle exceptions?
The allocation of responsibility is not a technical outcome that an organisation can wait for research to reveal. It is a choice the organisation must make. A report might involve a model retrieving material, an operations employee selecting the prompt, an engineering team configuring permissions and a manager clicking 'publish'. That chain does not automatically produce a single accountable person. An organisation can designate an owner for the outcome at the start of the process and give that person the authority to inspect evidence, pause the system and restore the manual process. It can also appoint different approvers for different levels of impact. Whatever arrangement it chooses should be written into the process, rather than allowing participants to point at a 'system recommendation' after something goes wrong. This is the article's governance proposition, not a conclusion derived directly from the productivity experiments above.
None of this supports the claim that 'AI will replace everyone'. The ILO research predicts that generative AI is more likely to augment occupations than to automate entire occupations. [5] A product manager may write fewer pages of requirements but spend more time checking whether a model has misread user feedback. A lawyer may perform less retrieval but need to verify citations, conflicts of interest and client authorisation more carefully. These scenarios illustrate why preserving a role does not mean leaving its content unchanged. They are not occupation-by-occupation predictions validated in the ILO abstract. How a particular role changes still depends on its tasks, tools and organisational arrangements.
Monitoring skill also has to account for changes in models and costs. Stanford HAI's 2025 AI Index places model capabilities, inference costs, responsible AI practices and labour trends within the same annual review. [10] Changes from one year to the next mean that a single benchmark result cannot serve as permanent proof of capability. Model updates, changes to tool interfaces and shifts in data distributions can all alter the checkpoints that were previously appropriate. If an organisation records only that 'the agent is now faster than a person', without recording the inputs on which it fails, it will later struggle to decide which human capabilities need to be retained.
If a team wants to establish whether opportunities to practise are genuinely declining, it can make the question a pilot metric alongside speed. Can novices handle a small set of cases without model suggestions? How long does it take employees to detect errors? Do exceptional cases reach the right person? Can reviewers explain the original evidence? No-AI drills, rotations through the complete process and reverse reviews are monitoring methods proposed here. They are not the only possible methods, nor have the studies above jointly validated them. Their value lies in turning the concern that employees' capabilities may be eroding into an observable question. The result may reveal the opposite: once AI removes mechanical work, novices might encounter complex problems earlier. Organisations need to let data answer the question rather than treating either an optimistic or pessimistic narrative as the conclusion.
5. A five-step proposal: start with a responsibility table
The five-step framework below is an editorial organisational-design proposal built from the empirical boundaries, regulatory examples and governance principles discussed above. It is neither the only method nor a 'best practice' jointly validated by NBER, the ILO, NIST, the OECD or any other source. Organisations of different sizes, in different industries and risk environments, will need to adjust the steps, thresholds and responsible roles. To make the method concrete, the example is a 30-day pilot that is low-risk, reversible and clearly bounded. Thirty days is simply a practical period, not a universal duration established by research. The pilot might classify internal knowledge-base tickets or draft emails from approved templates. It should first test outcomes, exceptions, evidence, learning and shutdown mechanisms, then decide whether permissions should be expanded.
The first step is to define the outcome, not the model. Replace 'process it faster' with checkable objectives: a specified field-accuracy rate; no increase in customer waiting time; an approval record for every external message; and no sensitive data leaving the designated system. Without a defined outcome, a team can mistake the fluency of a demonstration for success in production and has no basis for deciding when to pause.
The second step is to decompose the workflow into actions and assign each a tier. One useful scheme has four levels: reading and organising only; producing a draft for a person to edit; carrying out a reversible internal change; and carrying out an irreversible action or making an external commitment. Each level receives a different data scope, set of tool permissions and human check. A classification error can be rolled back automatically. Deleting records, making payments and sending legal commitments must be escalated. The point of classification is not to manufacture layer upon layer of approval. It is to make the boundary of automation visible.
The third step is to build a permissions and evidence table. At a minimum, its columns should cover the action, input data, tool called, permitted account, approver, log fields, rollback method and retention period. The agent runs under a service account rather than borrowing an employee's privileged access. Every material judgement by the model must point to the original material, the policy version and a timestamp. A guess with no source must not become an external fact. A change of model or default setting by the supplier should also trigger reassessment.
The fourth step is to place people at checkpoints that genuinely matter. A check is not an opportunity to read a polished summary. It must answer specific questions: are the underlying facts still valid, has counter-evidence been omitted, is the action within the authorised scope, and does the customer need to be told? The interface should let reviewers see the original evidence, the model's tool calls and options for reversal, rather than presenting only one enormous 'accept' button. Low-risk actions can be reviewed by sampling; high-impact actions require individual review. Sampling rates should change in response to historical errors and effects on users.
The fifth step is to review incidents and learning metrics. Speed and hours saved can be recorded, but so should rework rates, time to error detection, whether exceptions reached the right person, user appeals, denied permissions, missing evidence and employees' ability to solve problems independently. METR's evaluation of long software tasks found that models had lower success rates on longer tasks. [4] The research did not directly validate this five-step framework. Here, it supplies only a boundary condition: completing continuous work is not the same as making a single-step demonstration look impressive. Each week, a team could take several real logs and rehearse the question, 'What would have happened if nobody had stopped it?' This tests whether its thresholds work.
Once a workflow crosses departmental boundaries, the responsibility table must describe handovers as well as execution. A marketing agent creates a campaign list, a sales system sends invitations, a finance system calculates discounts, and legal rules check the commitments. Four teams may maintain those four stages. If the final email is wrong, the investigation cannot stop at the sending system. It must show how the list was created, which version informed the discount and which rule permitted the text. Each stage should hand structured state and evidence to the next rather than pass on an ambiguous natural-language summary. If upstream material is missing, the downstream system must be able to refuse to continue. The accountable person must also be able to see where the refusal occurred.
Teams can also give an agent a 'failure budget'. This does not mean tolerating high-impact errors. It means defining in advance the range within which a pilot may continue under observation. For example, errors in internal classification can be discovered by sampling and rolled back; an incorrectly sent customer email triggers an immediate pause in automatic sending. A failure budget turns risk tolerance into an executable threshold. It also prevents a pilot from being abandoned hastily after one minor error or, conversely, being kept alive through repeated anomalies because of sunk cost. When a pause condition is reached, the system should withdraw write permission automatically, preserve the logs at the point of failure and return unfinished work to a human queue. Restarting requires a new sign-off from the accountable person; the agent should not simply retry until it appears to succeed.
This proposal also allows an organisation to acknowledge failure. If a pilot finds that the agent repeatedly mistakes outdated policy for the current version, narrow its information scope, add version checks or suspend it. If employees approve everything, redesign the interface and training instead of blaming people for 'not reviewing carefully'. If the agent is reliable only on the most common cases, position it as a triage and drafting tool rather than pursuing imagined full automation. NIST's risk framework treats governance, mapping, measurement and management as a cycle, not as a one-off launch checklist. [8] This article adopts that direction of continuous governance; the particular five-step sequence remains a practical proposal organised for this article.
Efficiency remains worth pursuing. Faster responses can reduce waiting, and less repetitive work can free people to concentrate on customers, products and judgement. But when an organisation delegates both a continuous process and authority to act, efficiency should be an outcome constrained by boundaries, not a reason to remove them. The organisation needs to know what the agent completed, what it did not complete, the basis on which it acted, and who has the authority to change the rules before the next run.
When AI starts working for you, the important move is not to write a longer prompt. It is to redraw the delegated work: which step is execution and which requires human judgement; which permission can be granted and which must be retained; which piece of evidence allows the accountable person to explain a decision; and which kind of failure triggers shutdown. Not every organisation will reach this point, and no framework can guarantee the same result everywhere. But once AI is allowed to act continuously, faster models will not resolve these choices by themselves. What truly changes work is where the organisation chooses to place judgement, how far it grants authority, who bears the consequences, and whether it continues to preserve a visible path for people to develop capability.
