Category: Artificial Intelligence in Business

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published April 13, 2026

Updated July 2026 rewrote the orchestration section now that multi-agent handoffs and MCP tool access are generally available, and added a section on the accountability problem nobody designed for.

The mistake I keep seeing

A team hears about AI agents. They want to add AI to their approval workflow. So they take the existing 10-step Power Automate flow, stick a Copilot Studio agent somewhere in the middle, and call it an agentic workflow.

It isn’t. It’s the old process with a chatbot attached.

I ran into this internally, and people I talk to at other orgs describe the exact same pattern. The agent becomes a fancy input form. The process stays broken. And when it fails, and it does, everyone blames the AI. Then the whole automation program takes a credibility hit for a design mistake that had nothing to do with the model.

What actually makes a workflow agentic

An agentic workflow is not about adding a language model to a flow. It’s about giving the system the ability to reason about what to do next, not just execute a predefined sequence.

The difference matters. In a traditional flow, you define every branch. Every condition. Every outcome. The machine follows instructions. In an agentic workflow, the agent interprets a goal, decides which tools or actions to use, and adjusts based on what it gets back.

Anthropic made this distinction cleanly in their Building Effective Agents piece: workflows are systems where you orchestrate the steps, agents are systems where the model directs its own process. Most of what I see labeled agentic in enterprise Power Platform work is still a workflow. That’s fine. Workflows are great. Just call them what they are and design them accordingly.

Agentic design requires a fundamentally different approach. You’re not mapping steps. You’re defining boundaries, tools, and acceptable outcomes.

Three things that have to change in your process design

• Stop thinking in sequences. Agentic workflows are goal-driven, not step-driven. Define what done looks like, not every micro-step to get there. If your flow diagram looks like a subway map, you’re still in traditional automation mode.
• Give the agent real tools, not just data. An agent that can only read a SharePoint list and send an email is not doing much reasoning. It needs to call APIs, query systems, write back to records, trigger sub-flows. This got significantly easier once MCP support in Copilot Studio matured. You can now expose internal systems as tool servers instead of building a custom connector for every single action. But the design question hasn’t changed: people still give agents access to everything or nothing. Neither works. Scope each tool to the narrowest useful action.
• Build in failure handling at the goal level. Traditional flows handle errors at the step level. If this action fails, go here. Agentic workflows need you to think about what happens when the agent reaches a dead end, produces a low-confidence result, or loops without resolution. I’ve seen agents spin for 40 iterations on a task that should have escalated to a human after three. Set iteration caps. Set confidence thresholds. Define the escalation path before you define anything else.

Where this actually works in business processes

Not everywhere. I want to be direct about that.

Agentic design makes sense when the process has variability you cannot fully predict upfront. Invoice exceptions. Complex customer complaints. Multi-system data reconciliation where the right answer depends on context you only know at runtime.

It does not make sense for processes that are well-defined and stable. If your purchase order approval follows the same 6 steps every time, a standard Power Automate flow is the right tool. It’s deterministic, cheap to run, and easy to audit. Don’t add an agent to it because a roadmap slide told you to.

The teams getting real results are the ones who identify a process where exceptions are eating their staff’s time, then let the agent handle the exceptions rather than replacing the whole flow. The happy path stays deterministic. The agent works the mess.

The orchestration layer, revisited

When I first wrote this post, coordinating multiple agents in the Power Platform meant building the handoff logic almost entirely yourself. That has changed. Multi-agent orchestration in Copilot Studio now handles agent-to-agent handoffs natively, and connected agents can share context across a task.

Here’s what hasn’t changed: the platform routes the handoff, but it doesn’t design your boundaries for you. Agent B still won’t know what Agent A already tried unless you decide what context gets passed and what gets dropped. I’ve watched a document processing agent and a system update agent duplicate work for weeks because nobody defined which one owned the retry logic.

Document your agent boundaries explicitly. What does each agent know? What can it do? What should it never do? Treat it like designing a team of junior staff who are fast and tireless but have no common sense unless you’ve given them the right context. The tooling got better. The thinking is still on you.

The accountability gap

One thing I underweighted the first time around: agents don’t take responsibility. A colleague put it to me bluntly. You can’t have the numbers sometimes right and sometimes not. Enterprise processes need someone accountable for the outcome, and an agent is not someone.

This is a design constraint, not a reason to avoid agents. It means every agentic workflow needs a named human owner, a decision log the owner can actually read, and a clear line for which decisions the agent makes autonomously versus which ones it recommends. If you can’t answer “who is responsible when this agent gets it wrong” in one sentence, the workflow isn’t ready for production. I’ve written about this pattern before and it comes up in nearly every conversation on my LinkedIn.

Start smaller than you think you should

Pick one process. One that has clear exceptions, high manual effort, and a measurable outcome. Build the agent, give it two or three tools, test it against real historical cases before you deploy it anywhere near live data.

The teams succeeding with agentic workflows in 2026 are not the ones with the biggest ambitions. They’re the ones who are rigorous about scope, honest about where the agent is making decisions versus guessing, and fast to pull the agent out of the loop when something looks wrong.

Agentic is a design philosophy. Apply it where it earns its complexity.