Automation and Augmentation Need Different Evaluation Criteria

Picture two tasks sitting in front of you this week. One is routing standard invoices against purchase orders, the same rule applied the same way every time. The other is a renewal conversation with your most difficult account, where tone, timing, and history all matter. Ask “can AI do this?” about both, and you get the same shallow answer twice. That question was never the one that mattered.

Automation should remove work only after your organization can define how that work begins, proceeds, ends, and fails. Augmentation belongs where context, judgment, creativity, relationships, or accountability shape the outcome. Most companies skip this distinction and ask one question about every task: can artificial intelligence (AI) do this?

That question measures technical capability. It says nothing about how work should divide between people and systems. Leaders who rely on it end up automating decisions that needed judgment. They also ask employees to review work that never needed review at all. The result is a workforce that feels busier and less trusted at the same time.

The stronger question is different. It asks what kind of work sits in front of your organization, and which operating model that work requires. That question produces two categories with different evidence requirements, different risks, and different measures of success. Confusing the two categories is one of the most common reasons artificial intelligence initiatives disappoint.

Know that these are two different categories of work

An automation candidate needs predictable demand, dependable inputs, stable rules, manageable exceptions, and a clear completion condition. An augmentation candidate needs a qualified person who can interpret the output and improve the final decision. These are not two points on one scale. They are two different operating designs, each with its own requirements.

The Massachusetts Institute of Technology (MIT) supplied some of the clearest evidence for why this distinction matters. Researchers at the MIT Sloan School of Management reviewed more than 100 experiments measuring human performance, system performance, and combined performance on the same tasks. On average, the combination performed worse than the stronger of the two working alone. The pattern reversed for tasks that involved creating content, where combinations often produced real gains. It held most consistently for tasks that involved making a decision, where combinations more often produced a loss. Combining people and artificial intelligence is not automatically an improvement. It becomes an improvement when the task, and the design built around it, calls for both contributors.

Stanford University reached a related conclusion from a different direction. Its Human Agency Scale (HAS) measures how much human involvement each task should retain as artificial intelligence capability increases. Researchers built the scale by auditing more than 800 tasks across over 100 occupations. Tasks inside the same job carry different scores. A single role can include work that belongs at one end of the scale and work that belongs at the other. The task, the decision, or the discrete action inside a job is the real unit of analysis, not the job itself.

This reframes the evaluation question you should be asking. You are choosing which operating model each piece of work inside a role requires, task by task, rather than judging the whole role at once.

Use Decision Rights Architecture as your core thesis

Every workflow assigns decision rights, whether anyone designed them or not. Someone, or something, decides what happens next, under what conditions, and with what accountability attached. When you skip this design step, decision rights default to whoever installed the tool, and your organization inherits an operating model nobody chose.

Decision Rights Architecture is the discipline of assigning decision rights deliberately. It sorts work into three layers. The system layer covers work a system can complete because it meets defined conditions. The support layer covers work artificial intelligence can assist because a qualified person still owns the outcome. The governance layer keeps both assignments honest over time.

The architecture asks who, or what, should hold authority over each decision, and what evidence justifies that authority. Technical capability is only one input into that answer.

Layer one: give system rights to the automation candidates

A task earns system rights when you can answer nine questions with confidence.

• The workflow has a dependable trigger, such as a new record, a status change, or an approved request, that identifies real work requiring action.
• The required inputs are defined, including approved sources, accepted formats, and a clear response when information is missing or conflicting.
• Normal cases follow rules that experienced employees can explain and apply the same way every time.
• Exceptions are detectable, countable, and routable, even when the exception rate runs high.
• Completion has a business definition, such as an approved record with the correct destination and assignment, rather than a generated output alone.
• Failures remain visible, with monitoring that shows which case entered the workflow, which step failed, and who owns recovery.
• Actions are reversible or limited in consequence, or the system can prepare the action and route it for human approval.
• The business case accounts for the complete continuing cost, including development, monitoring, support, training, and governance, not only the time saved per task.
• The process is stable enough to maintain, without policy or system changes so frequent that upkeep exceeds the value delivered.

Strong system-rights candidates include applying approved classifications, matching standard records, routing requests against defined criteria, sending scheduled reminders, and monitoring operating thresholds. The value comes from dependable execution across recurring demand. A task does not qualify because employees find it repetitive. You must first understand the decisions hidden inside that repetition.

Layer two: give support rights to the augmentation candidates

A task earns support rights when you can answer nine different questions with confidence.

• A qualified person’s judgment changes the result, through expertise, customer knowledge, ethical reasoning, or accountability the system cannot supply.
• The work contains meaningful ambiguity, where the right answer depends on audience, timing, risk tolerance, or precedent.
• A qualified person can evaluate the output, rather than accepting a polished answer on faith.
• The output supports a defined decision, with a named owner, stated criteria, and a next business action.
• Alternatives genuinely improve the decision, because the system expands the option set instead of replacing it with one answer.
• Context changes between cases in ways no static rule set can anticipate.
• A person remains accountable for the outcome, particularly where the decision touches employment, money, contracts, or reputation.
• Ongoing interaction improves the work, because the person can challenge assumptions, add evidence, or redirect the approach.
• The design preserves the skills your organization will keep needing, rather than letting employees accept recommendations without understanding them.

Strong support-rights candidates include developing market strategy, preparing for high-value customer conversations, interpreting unusual financial results, drafting sensitive communications, and diagnosing unfamiliar operating problems. The value comes from improving a person’s preparation, range, and decision quality. A human review step adds nothing when the person repeats a mechanical check without real authority or context.

Layer three: use governance rights to keep both layers honest

Automation and augmentation need different measures, and neither should be judged on time saved alone.

Automation measures should track eligible demand, completed volume, cycle time, exception rate, failed runs, rework, and business outcome. Augmentation measures should track preparation time, output acceptance, correction severity, decision quality, employee confidence, and business outcome. McKinsey’s 2025 State of AI research found that fundamental workflow redesign showed the strongest correlation with enterprise earnings impact among the organizational practices it tested. Assigning decision rights correctly is what that redesign work looks like at the task level.

Treat human review as a protection for judgment, not a repair layer for weak design. Teams often add a review step after an automated process performs inconsistently, and the reviewer quietly absorbs missing fields, weak sources, and recurring errors. A growing review queue usually signals unstable rules or poor exception detection, not a permanent need for human correction. The National Institute of Standards and Technology (NIST) recommends defining human oversight, testing conditions, and continuing monitoring based on the task’s specific risk. One oversight model should not cover everything. That guidance applies directly here. Weak observability should delay automation until you can detect failures dependably.

Watch how the architecture works inside one workflow

Decision Rights Architecture rarely assigns an entire process to one layer. Consider a customer renewal.

A system can gather contract dates, product usage, open issues, payment history, and recent activity, then flag missing records and prepare a structured account summary. That work carries system rights. Artificial intelligence can then suggest questions and highlight possible risks inside that summary, supporting the account owner’s preparation. That work carries support rights. The account owner interprets the relationship, defines the commercial position, and approves the conversation. That decision stays with the person, fully.

The same pattern applies to a sales opportunity review. A system gathers account activity and communication history. Artificial intelligence highlights patterns and unanswered questions. The salesperson decides whether to advance, restructure, or close the opportunity. A system then updates fields and schedules the next review. Give each stage the operating model its own evidence supports, rather than one model applied to the whole process.

Apply the architecture across your functions

Marketing. System rights fit approved metadata tagging, channel queue placement, publication record updates, and routine reporting from defined data. Support rights fit market research, positioning alternatives, gap analysis in an argument, and campaign performance interpretation. Final positioning, claims, and publication approval stay with qualified people.

Sales. System rights fit research triggers tied to approved signals, routine activity updates, follow-up task creation, and routing inactive opportunities for review. Support rights fit interpreting account signals, preparing meeting questions, identifying stakeholder concerns, and comparing opportunity strategies. Relationship strategy and commercial commitments stay with the salesperson.

Finance. System rights fit matching standard invoices to purchase orders, flagging duplicate records, routing approvals by defined thresholds, and formatting recurring reports. Support rights fit explaining unusual variances, preparing forecast scenarios, and summarizing model assumptions for leadership. Payments, forecasts, and financial commitments stay with authorized employees.

Customer service. System rights fit classifying common requests, routing cases to defined queues, retrieving approved account details, and monitoring response deadlines. Support rights fit summarizing complex case histories, preparing response options, and identifying relevant policy. Policy exceptions and financial remedies stay with accountable people.

Human resources. System rights fit interview scheduling, onboarding task creation, training tracking, and document organization. Support rights fit summarizing job-related evidence, identifying missing interview information, and preparing employee communications. Hiring, compensation, promotion, and discipline decisions stay fully human.

Run this decision sequence in one meeting

Seven questions, asked in order, will sort most of your tasks correctly.

1. Does the work repeat through a recognizable process? If not, treat it as a support-rights or fully human task.
2. Can your team define what successful completion looks like? If not, redesign the process before automating it.
3. Are the required inputs available and dependable? If not, use augmentation while your team repairs the information foundation.
4. Can normal cases follow stable rules that experienced employees agree on? If not, the work likely needs support rights instead.
5. Can the system identify and route exceptions reliably? If not, redesign the workflow or narrow its scope.
6. Can errors be detected before serious consequences occur? If not, keep a person inside the approval path.
7. Does human judgment materially improve the outcome in normal cases? A “no” points toward system rights. A “yes” points toward support rights.

A final question closes the sequence: does the expected result justify the complete operating cost, including monitoring, support, and governance? Only a clear yes should move the work into production.

Run this 30-day evaluation for one workflow

Week one. Observe the current work. Follow representative cases from trigger to completion, and record tasks, decisions, handoffs, and exceptions. Establish current volume, cycle time, quality, and cost.

Week two. Separate tasks from decisions. Mark each step as a system-rights, support-rights, hybrid, or redesign candidate, based on the criteria above.

Week three. Test the strongest options. Run system-rights tests against predictable cases and normal inputs. Run support-rights tests with qualified employees against judgment-heavy work, including known exceptions.

Week four. Select the operating model. Compare quality, time, cost, exceptions, and employee experience. Define ownership, monitoring, training, and fallback requirements before approving the design.

Watch for the mistakes that undermine the evaluation

Employee frustration with a task is a reason to examine it, not a reason to automate it. A strong prompt producing a good output is not the same as automation readiness, since the workflow still needs triggers, approvals, and exception handling. Evaluating an entire job, instead of the tasks inside it, produces designs that assign work incorrectly on both sides. Assuming that combining people and artificial intelligence always improves performance ignores what the MIT Sloan research found. Measuring generated drafts and reports instead of completed, accepted work hides whether the process delivered anything at all. Treating heavier automation as a sign of greater maturity is also a mistake, since some consequential decisions should keep direct human judgment permanently, by design.

Employees performing the current work already know most of this. They know which fields cannot be trusted, which exceptions happen every week, and which approvals add value versus persist through habit. NIST recommends including the people closest to the work during testing under realistic conditions. That participation should shape the architecture, not only validate it afterward.

What you tell them at the end

You decide where the released capacity goes once automation and augmentation free up time. That decision belongs in the business case from the start, not as an afterthought once the workflow ships. Released capacity can serve more customers, shorten response times, retire a backlog, or fund work your team never had room for. Left undirected, it tends to fill with more of the same low-priority activity that consumed the time before.

Automation removes defined work from the human path. Augmentation improves how people research, analyze, and decide. Neither approach replaces the other, and neither should be evaluated with the other’s criteria. The organizations getting real value from artificial intelligence in 2026 assign decision rights on purpose, task by task. They stop asking one question about every job and hoping the answer holds.