For years, most workplace AI followed a simple pattern:
A human does the work. AI helps with a task.
Write the email. Summarize the document. Find the information. Draft the report. Analyze the spreadsheet.
The workflow stays largely intact. AI simply makes one step faster.
AI agents introduce a different possibility.
Instead of helping with one step, an agent can retrieve information, use tools, reason across multiple steps, and take action within defined boundaries.
That changes more than productivity.
It changes the architecture of work.
The Workflow Used to Be the Interface
Consider a customer support request.
In a traditional organization, the path might look like this:
Customer request → Triage → Knowledge search → Account lookup → Specialist → Approval → Response → System update
The employee is effectively the interface connecting all these systems and teams.
They move between the CRM, knowledge base, ticketing system, internal documentation, and other applications.
Each handoff exists for a reason. But each one also introduces friction.
Now consider an agentic version of the same workflow:
Customer request → Agent → Knowledge + Customer data + Policy → Action or Escalation
The employee may no longer need to navigate every intermediate step.
The agent can potentially retrieve the relevant information, determine which policy applies, perform an authorized action, update the relevant system, and escalate when the case falls outside its boundaries.
This is not simply task automation.
It is workflow compression.
And once a workflow is compressed, the organization has to reconsider the architecture underneath it.
From Applications to Agents
There is another shift happening underneath the workflow.
For decades, enterprise software was organized around applications.
Employees learned which application to open for which task.
CRM for customer records.
ERP for financial and operational data.
Service management for tickets.
Knowledge systems for documentation.
The human connected these systems.
Agents can change that relationship.
Instead of:
Human → Application → Data → Action
the architecture can increasingly look like:
Human → Agent → Multiple Applications / APIs / Data Sources → Action
The applications do not disappear.
But the employee may interact less directly with each one while the agent handles more of the movement between them.
Salesforce provides a useful real-world example.
Salesforce says its internal Agentforce deployment now supports work across the sales cycle, including qualifying leads, answering product questions, generating quotes, creating briefs, and providing coaching. The company reports that its sales team creates quotes 75% faster and with 87% fewer clicks.
The interesting part is not simply that a quote can be created faster.
The path to the quote has changed.
Instead of navigating multiple sources, finding product information, checking pricing, and moving through repetitive steps, the seller can use an agent to coordinate much of the process.
The agent becomes a coordination layer.
That creates a new design problem.
If the agent becomes the interface through which work moves, the organization needs to know exactly what the agent can see, what it can change, and which systems it is allowed to act on.
The question is no longer only whether an agent can use a tool.
It is whether the organization is prepared to let that agent sit between the employee and the tools that run the business.
Handoffs Become Invisible, Not Irrelevant
Handoffs have always been one of the hidden structures of organizational work.
A support representative sends a case to a specialist.
A salesperson sends a quote to finance.
An employee sends a request to IT.
A manager approves an exception.
Agentic systems can remove some of these visible handoffs.
But removing a handoff does not remove the underlying responsibility.
It can simply make the handoff invisible.
Imagine an agent that checks a customer’s account, interprets a refund policy, determines that the request qualifies, and issues the refund.
Previously, several people might have been involved.
Now one agent may perform the entire sequence.
That is efficient.
But who owns the decision?
The support team?
The product team that defined the policy?
The engineer who built the agent?
The manager who approved its permissions?
The business owner responsible for customer refunds?
The old workflow often answered this implicitly because responsibility followed organizational roles.
The agentic workflow needs to make it explicit.
Fewer handoffs can therefore create a greater need for clear ownership.
The Exception Path Becomes the Real Workflow
This is where agentic systems become particularly interesting.
Most workflows are designed around the normal case.
But businesses rarely operate only in the normal case.
Consider a refund process.
The happy path is straightforward:
Check order → Check policy → Approve → Refund
But what happens when:
The order is outside the refund period?
The product was replaced?
The customer’s account has multiple previous refunds?
Two systems contain conflicting information?
The policy changed recently?
The customer claims the product was defective?
A human employee can often recognize that something is unusual and stop.
An agent needs the boundary to be designed.
This means organizations should think about two workflows, not one:
The execution path: what the agent normally does.
The exception path: what happens when the agent should not continue.
The second may ultimately matter more.
A useful agentic workflow therefore needs explicit answers to questions such as:
What can the agent decide?
What can it execute?
What requires approval?
When must it stop?
Who receives the escalation?
What context must be preserved when the case is handed back to a human?
Without these answers, an organization may have an autonomous agent without an actual operating model around it.
The New Bottleneck Is Often Outside the Model
This is why improving the model does not necessarily improve the workflow.
An organization can give an agent better reasoning capabilities while leaving the underlying process fragmented.
It can connect an agent to five systems while keeping the data inconsistent.
It can give the agent access to a policy while leaving ownership of that policy unclear.
It can automate the normal path while leaving exceptions undefined.
In each case, the technology may work exactly as designed.
The workflow still breaks.
Microsoft’s 2026 Work Trend Index points to a similar organizational gap. The research surveyed 20,000 AI-using knowledge workers across 10 markets and found that organizational factors such as culture, manager support, and talent practices were associated with more than twice the reported AI impact of individual mindset and behavior.
The report also found that more advanced AI users are already using agents for multi-step workflows and routinely rethinking workflows around what AI can do.
The technical question is:
Can the agent perform the task?
The operational question is:
Should the agent perform the task?
The architectural question is:
What should the workflow look like now that the agent can perform it?
The third question is the one companies often skip.
Don’t Put an Agent on Top of a Broken Workflow
There is a temptation to take an existing workflow and add an agent to it.
If employees currently complete ten steps, the goal becomes making the agent complete those same ten steps faster.
But that can preserve unnecessary complexity.
Suppose employees have to obtain three approvals because the organization historically required them.
If the agent can now perform the underlying checks automatically, perhaps one approval is no longer necessary.
Suppose employees manually transfer information between two systems.
If the agent can move the information reliably through an API, perhaps that handoff should disappear.
Suppose a manager reviews every request because there was no practical way to distinguish routine cases from unusual ones.
If an agent can classify routine cases and escalate only exceptions, the manager’s role may need to change.
The objective should therefore not be:
Automate the workflow.
It should be:
Redesign the workflow around the capabilities and limitations of the agent.
That is a much bigger change.
Agent Management Becomes Part of Enterprise Architecture
Once agents become part of operational workflows, another layer appears: managing the agents themselves.
This is already visible inside Microsoft.
In August 2026, Microsoft said its IT organization had visibility into more than 500,000 agents through Microsoft Agent 365, with information about agent categories, usage, ownership, lifecycle, and risk.
The important point is not simply the number.
It is what the company needs to track.
An agent now has something resembling an organizational identity.
It has an owner.
It has permissions.
It has a lifecycle.
It interacts with systems.
It creates outputs.
It can fail.
It can become outdated.
It may need to be retired.
That means agent management is moving beyond model selection and prompt design.
It starts looking much more like enterprise architecture.
A Practical Framework for Redesigning Agentic Work
Before introducing an agent into an existing process, organizations can map five layers.
1. Execution
Which steps can the agent perform reliably?
Separate information retrieval, reasoning, system actions, and external actions.
Not every capability should automatically receive the same level of permission.
2. Authority
What is the agent actually allowed to decide?
Capability and permission are different things.
An agent may be technically capable of issuing a refund, changing a customer record, or sending an external message without being authorized to do so.
3. Exceptions
Where must the agent stop?
Identify the conditions that require escalation before deployment, not after an incident.
4. Ownership
Who owns the workflow and its outcomes?
There should be a business owner who can answer when the process changes, the agent fails, or its behavior needs to be reviewed.
5. Feedback
What happens after the agent acts?
Agentic workflows should create a feedback loop.
Organizations need to know where agents succeed, where they escalate, where humans override them, and where the workflow repeatedly breaks.
Those patterns can reveal opportunities to redesign the process again.
Humans Move to a Different Layer
The natural conclusion is not that humans disappear from the workflow.
It is that their position within the workflow changes.
A support employee may spend less time searching for information and more time handling unusual customer situations.
A manager may approve fewer routine requests and spend more time setting boundaries for automated decisions.
An operations team may spend less time coordinating individual transactions and more time monitoring the system that coordinates them.
Microsoft’s 2026 research describes a similar shift: as agents take on more execution, humans can have more room to direct work, make decisions, and own outcomes.
The human role moves toward:
judgment → exception handling → supervision → process design → accountability
But this transition does not happen automatically.
If organizations simply remove routine tasks without redesigning roles, they can create a new problem: people become responsible for supervising systems without enough visibility, authority, or context to do that effectively.
The goal should not be a human in every step.
It should be a human with the right responsibility at the right point in the system.
The Architecture Has Changed
The most important change brought by AI agents may not be that machines can perform more tasks.
It is that the boundaries between tasks are becoming less important.
A traditional workflow is built around people moving information from one step to another.
An agent can potentially move across those steps itself.
That compresses the workflow.
It also exposes everything the old workflow was quietly relying on:
permissions, ownership, exceptions, policies, system boundaries, and human judgment.
This is why deploying an agent should not start with:
“Which task should we automate?”
It should start with:
“What should this workflow look like if an agent can perform several of these steps?”
The companies adopting agents are not just adding another layer of automation.
They are beginning to redesign where work happens, where decisions happen, and where responsibility sits.
And that may be the more consequential change AI agents bring to organizations.
About the Author
Zohre Shirazi is the publisher of AI Wide Open , a newsletter focused on how AI is changing work, workflows, and organizations in the real world. She writes about practical AI adoption, workflow redesign, and what happens when AI moves from experimentation into everyday business operations.
Keep Exploring AI in the Real World
If you’re interested in what happens when AI moves beyond demos and into real workflows, subscribe to AI Wide Open for practical analysis of how companies are actually adopting AI and redesigning the way work gets done.
The sharpest line here is that removing a handoff does not remove the responsibility - it just makes the handoff invisible. That maps exactly to what we keep seeing at the system level: the model is rented, but the harness - the permissions, the exception path, the memory that survives the session - is what the organization actually owns and must govern. Agent 365's 500,000 agents with owners and lifecycles is the tell that agency is an architecture problem, not a model problem: https://seldondance.substack.com/p/agents-dont-equate-to-agency