Automation projects often begin with a visible burden: a repetitive task, a slow queue or a team spending too much time moving information between systems. The temptation is to place an agent over the existing process and call the result transformation.
That approach can make the process faster without making it better. If ownership is unclear, the agent will route uncertainty more quickly. If the data is unreliable, it will scale bad decisions. If the workflow contains unnecessary approvals, it will generate more work for the same bottleneck.
Microsoft’s 2026 research on AI at work argues that organizations need to redesign the work itself rather than fit increasingly capable models into old structures. That is the correct starting point for automation.
Define the outcome before the task
A process exists to produce an outcome: resolve a customer issue, close the books, approve a claim, launch a product or fulfill an order. Teams should begin by defining that outcome and the conditions that make it successful.
Only then should they examine the tasks. Some tasks create value, some control risk and some exist because another part of the system is weak. Automating all three categories without distinction preserves waste.
Remove ambiguity from ownership
Agents perform poorly when the organization has not decided who owns an exception. A workflow may move cleanly until two records disagree or a request falls outside policy. At that point, the system needs a named decision owner and a clear escalation path.
“Send to a human” is not a complete design. The human needs the relevant evidence, authority to decide and a way to return the decision to the workflow. Otherwise, the agent creates another queue.
Fix source data at the origin
Automation frequently exposes the same data defect again and again: inconsistent customer names, missing product attributes, outdated policies or fields used differently by each department.
An agent may infer or repair some of those problems, but repeated inference is expensive and risky. The durable solution is to improve the source, define ownership and validate information when it enters the system.
Good automation is often less impressive than a demo because it depends on unglamorous work: data definitions, required fields, permissions and exception rules.
Separate judgment from execution
A strong workflow identifies where probabilistic reasoning is useful and where deterministic control is required. An agent may classify a request or prepare a recommendation. A rules engine can enforce a transaction limit. A person can approve an exception with material consequences.
Blurring those roles makes the system difficult to evaluate. If every action is described as “AI,” teams cannot tell whether an error came from interpretation, policy, integration or data.
Use incidents to redesign the process
NIST’s review of AI agent security comments found that familiar cybersecurity practices remain relevant but require adaptation. The same is true of operational improvement. Teams need logs, incident classification, containment and a method for preventing recurrence.
A failed agent run should produce more than a corrected output. The organization should determine whether to change the instruction, restrict permission, improve data, add a validation or redesign the handoff.
Automation is the final step, not the first
Before deploying an agent, teams should be able to describe the workflow on one page: the purpose, inputs, owner, rules, exceptions, controls and measures. If that description produces disagreement, the process is not ready for automation.
AI can make a well-designed system more responsive and scalable. It cannot resolve organizational ambiguity the company has chosen not to confront. Automation is a multiplier. The result depends on what the organization asks it to multiply.
The hard work remains managerial: simplify the process, make responsibility explicit and give the system trustworthy inputs.