Halilcan Soran

Tag: AI Agents

  • Latency Is the Quiet Killer of Agentic Workflows and Almost Nobody Talks About It

    Latency Is the Quiet Killer of Agentic Workflows and Almost Nobody Talks About It

    Diagram showing agentic workflow latency across multiple model calls in a Copilot Studio and Power Automate loop

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

    Everyone obsesses over model quality, tool design, and prompt structure when building agents. The thing that actually kills adoption in production is something else entirely. Agentic workflow latency is the quiet killer, and most Power Platform and Copilot Studio builders are not thinking about it until users start abandoning the tool.

    I came across a post from OpenAI about using WebSockets and connection-scoped caching in the Responses API to speed up their Codex loop. It confirmed something I keep running into building multi-step agents internally. The math is brutal once you do it honestly.

    Why Agent Loops Feel Slow Even When Each Call Is Fast

    A single model call at 800ms feels fine. A tool call at 300ms feels fine. A Dataverse lookup at 500ms feels fine. Everyone looks at these numbers in isolation and says the platform is fast enough.

    Then you build an actual agent. It reasons, calls a tool, reads the result, reasons again, calls another tool, checks a condition, calls a third tool, summarises, responds. That is 8 to 15 round trips for one user request. Each round trip carries connection setup, authentication overhead, token streaming setup, and the model’s own time to first token.

    A 400ms overhead per call sounds small. Multiply by 12 calls. That is almost 5 seconds of pure overhead before any actual thinking or work happens. Users do not wait 15 seconds for a confident answer. They ask once, get nothing for a few seconds, and switch back to the old way of doing it.

    I have watched this kill internal tools that were technically correct. The agent did the right thing. Nobody used it.

    What OpenAI Just Shipped and Why It Matters Beyond Codex

    The short version of what they did: move from repeated HTTP requests to a persistent WebSocket connection, and keep cache state scoped to that connection so repeat context does not need to be re-processed on every turn.

    This is not a Codex-only trick. It is a general pattern. Connection-scoped caching means the expensive part of a call, the part that handles your system prompt and tool definitions and prior context, does not get redone from scratch every time your agent takes another step.

    For anyone building agents that loop, this is the shape of the next year of infrastructure work. The platforms that expose this properly will feel instant. The ones that do not will feel like they are thinking through molasses.

    What This Looks Like Inside Copilot Studio and Power Automate

    Here is where it gets uncomfortable. In Copilot Studio, you do not see the round trips. You see a topic, a few actions, a generative answer node. The platform hides every call behind its own orchestration.

    That hiding is the problem. A Copilot Studio agent doing generative orchestration with three tool calls backed by Power Automate flows is making far more round trips than most builders realise. Each tool call is a Power Automate HTTP trigger plus whatever that flow does internally, often including another connector call to SharePoint, Dataverse, or an external API. The agent then reads the response and decides what to do next, which is another model call. And if you are hitting Power Automate throttling limits under real load, every one of those round trips gets longer.

    I built one recently that felt snappy in testing with one user. In production with ten concurrent sessions, response times doubled. Nothing in the flow was slow on its own. The sum was slow, and throttling on shared connectors made it worse. This is the same class of problem I wrote about in Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat. The difference between a real agent loop and a glorified flow shows up in latency first.

    How I Would Budget Latency Before I Build the Agent

    I treat latency as a first-class design constraint now, not something I measure after the fact. Before I build, I do this:

    • Estimate the number of model calls per user request. Not best case. Typical case.
    • Estimate the number of tool calls and what each one hits. A SharePoint list call in the same tenant is not a Graph API call with auth handshake.
    • Set a budget. I aim for under 4 seconds total for anything conversational, under 10 seconds for anything that is clearly doing work.
    • Cut calls aggressively. Can two tools be one? Can I pre-fetch context in a single call instead of three? Can the agent skip a reasoning step when the intent is obvious?
    • Parallelise where I can. Power Automate lets you run actions in parallel branches. Most builders do not use them.

    The other thing I stopped doing: chaining LLM calls for steps that do not need reasoning. If a step is deterministic, I call the tool directly, not through the model. Every model call I can remove from the loop gives me back 500 to 1500ms.

    Latency is also where the question of who owns the decision in an agentic workflow becomes a performance problem, not just a governance one. Every checkpoint that routes back to a human approver adds another wait state to the loop. The more of those you have, the more your total response time is dominated by human latency, not model latency.

    I have written more about my approach to this kind of trade-off on my LinkedIn, because I keep having the same conversation with people at other organisations who hit the wall when their demo hits real users.

    The agents that win in production are not the smartest ones. They are the ones that answer before the user gives up.

    Frequently Asked Questions

    Why does agentic workflow latency get so bad in multi-step agents?

    Each individual call in an agent loop may seem fast, but the overhead adds up across 8 to 15 round trips per user request. Connection setup, authentication, and token streaming costs stack on every single step, turning individually acceptable delays into a frustrating overall wait time.

    What is connection-scoped caching and how does it help agent performance?

    Connection-scoped caching keeps expensive context like system prompts, tool definitions, and prior conversation state ready across multiple calls instead of reprocessing it each time. This avoids redundant work on every step of an agent loop and significantly reduces the overhead that accumulates across a multi-turn interaction.

    How do I reduce latency in Copilot Studio and Power Automate agents?

    Start by auditing how many round trips your agent actually makes for a single user request, since this is where most hidden latency lives. Look for opportunities to batch tool calls, reduce unnecessary steps in your loop, and watch for platform-level improvements like persistent connections that reduce per-call overhead.

    Why do users abandon AI agents even when the agent gives correct answers?

    If the response takes too long, users lose confidence and revert to familiar alternatives before the agent finishes. Technical correctness does not matter if the experience feels slow enough to suggest something has gone wrong.

    Source: Speeding up agentic workflows with WebSockets in the Responses API (OpenAI).

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • The Real Shift Is Not Faster Work It Is Who Owns the Decision

    The Real Shift Is Not Faster Work It Is Who Owns the Decision

    AI automation decision ownership shifting from human approvers to agents in enterprise workflows

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

    I came across a post from the Microsoft Power Platform Blog about intelligent apps, human leadership, and the new shape of work. The framing is fine, but the speed angle buries what I think is the actual shift happening right now. The real story is about ai automation decision ownership, not output volume. Two years ago a flow ran rules and a human approved the exceptions. Now the agent handles the exceptions and the human sets the policy the agent operates under. That is a completely different job.

    Speed Was Never The Interesting Part Of Automation

    Every automation pitch I have seen in the last five years leads with hours saved. It is the easiest metric to put on a slide. It is also the least interesting thing about a good automation.

    The flows I am proud of did not win because they were fast. They won because they removed a decision that did not need a human in the loop. A purchase order under a certain threshold. A leave request that matches a pattern. A ticket that routes itself based on content. The speed was a side effect of letting the process run without waiting for someone to click approve.

    Speed framing also makes everyone lazy about design. If the only goal is faster, you end up automating a bad process and shipping the same broken logic at ten times the throughput. I have written about this before. Bad process plus automation equals faster failure.

    The Decision Boundary Is What Actually Moved

    Here is the shift I keep seeing internally and hearing from people at other organisations.

    Old model: deterministic flow runs the rules, human handles anything weird. The human owns judgment. The flow owns execution.

    New model: agent handles the weird cases too, because it can reason about context, read the attachment, compare against policy, and make a call. The human no longer sits in the approval step. The human sits above the agent, writing the constraints it operates under.

    That is not a speed change. That is a decision ownership change. The human used to approve ten exceptions a day. Now the human writes the rules for how exceptions should be resolved and reviews a sample at the end of the week.

    Most teams I talk to have not internalised this yet. They still put the agent in the response step of a structured flow, which I already called out as not really agentic. The interesting version is when the agent sits in the decision layer and the deterministic steps execute what it decides.

    What This Changes About How I Build Flows And Agents

    When I build a flow now, I spend less time on the happy path and more time on what the agent is allowed to decide on its own.

    Concretely:

    • I write the policy first in plain language, not the flow. What can the agent approve without escalation. What must it always escalate. What does good look like. What does a bad outcome look like.
    • I design the tools the agent calls as if I am writing an API contract, because that is what I am doing. A tool returning done is useless. It needs to return the state the agent can reason about.
    • I build the escalation path before I build the automation path. If the agent is uncertain, where does it hand off. To whom. With what context.
    • I log the decisions, not just the executions. A flow run log tells me what happened. A decision log tells me why the agent chose what it chose, which is the only way to improve the policy.

    This is closer to writing Power Automate flows with an orchestration brain on top than it is to classical automation. If you are curious about that orchestration layer, Claude has been the most interesting model for this in my testing. Anthropic is shipping the kind of stateful reasoning this job actually needs.

    Stop Measuring Hours Saved Start Measuring Decisions Delegated

    If your AI project feels underwhelming even when it technically works, look at what you are measuring. Hours saved is a dashboard metric. Decisions delegated is an architecture metric.

    Some questions I ask when I review an automation now:

    • How many decisions used to need a human that no longer do.
    • What is the policy the agent is enforcing, and who owns that policy.
    • When the agent is wrong, how do we find out, and how fast do we update the policy.
    • What decisions are we deliberately not delegating, and why.

    None of these show up on a time-saved slide. All of them determine whether the automation holds up six months in.

    The job is not building flows anymore. The job is writing the operating constraints for something that makes judgment calls. That is a different skill, and I think the teams that figure this out early will look very different from the ones still counting hours. In my own experience, the projects that aged well are the ones where someone owned the policy, not the flow.

    Frequently Asked Questions

    What is AI automation decision ownership and why does it matter?

    AI automation decision ownership refers to who or what holds responsibility for making judgment calls inside a workflow. It matters because modern AI agents can now handle exceptions and reasoning tasks that previously required a human approver, fundamentally changing the role people play in automated processes.

    How do I know if my automation is truly agentic or just a faster rule-based flow?

    A good indicator is where decisions actually happen. If a human or a rigid rule set still handles every exception and the AI only executes predefined steps, the workflow is not truly agentic. An agentic setup puts the AI in the decision layer, with deterministic steps carrying out what it concludes.

    Why does automating a bad process lead to worse outcomes?

    Automation removes the friction that sometimes forces people to notice problems. When a flawed process runs faster and at higher volume, errors multiply at the same rate as the throughput, making the underlying issues harder to catch and more costly to fix.

    When should I move a human out of the approval step in an automated workflow?

    A human can move out of direct approvals when the decision follows a consistent pattern that can be expressed as clear policy constraints. The better use of human judgment at that point is writing and periodically reviewing those constraints, rather than approving individual cases one by one.

    Source: Intelligent apps, human leadership, and the new shape of work (Microsoft Power Platform Blog).

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • If You Are Starting Copilot Studio in 2026 Skip the Chatbot Tutorials

    If You Are Starting Copilot Studio in 2026 Skip the Chatbot Tutorials

    Getting started with Copilot Studio 2026 using generative orchestration instead of topics

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

    I keep running into people getting started with Copilot Studio in 2026 who spent their first two weeks building a topic tree with trigger phrases and a node-by-node dialog flow. Then they ask me why their agent feels rigid and why every new question breaks something. The answer is not that they built it badly. They learned the wrong paradigm from tutorials written three years ago.

    If you are starting today, skip the chatbot tutorials. Go straight to a generative orchestration agent with a couple of tools and knowledge sources. That is how real agents are being built now.

    Why the 2023 Copilot Studio learning path is actively misleading in 2026

    The classic learning path walks you through creating a topic, adding trigger phrases, building a dialog tree with question nodes, conditions, and variables, then testing it with the exact phrases you wrote. It feels productive because you see progress quickly. It is also teaching you a way of thinking that does not scale past an FAQ bot.

    Microsoft itself has de-emphasised this path. Generative orchestration is the default for new agents. Topics still exist and still have their place, but as guardrails for specific flows that must follow a strict script, not as the primary way to build conversation.

    The problem with learning topics first is unlearning them later. People who start with trigger phrases end up writing dozens of them trying to catch every variation a user might type, then wonder why the agent still misroutes at the edges. Your Copilot Studio Agent Passed Every Test and Still Failed in Production explores exactly this kind of failure. Generative orchestration does not eliminate this, but it changes the shape of the problem entirely.

    The four things that actually matter when you start today

    When someone joins the team and asks where to begin with Copilot Studio, I tell them to focus on four things before anything else.

    Instructions. The system prompt is where most of the agent’s behaviour comes from now. Learning to write clear, specific, scoped instructions is more valuable than learning the node editor. Bad instructions cause instruction drift the moment real data hits the agent.

    Knowledge sources. Connecting a SharePoint site, a Dataverse table, or a public website and understanding how the agent grounds answers in them. This is where the actual information lives. Most agents do not need a dialog tree, they need good grounding.

    Tools. A tool is a Power Automate flow, a connector action, an MCP server, or a prompt. Learning how to design tools so the agent can call them reliably is the real skill. Returning a status of done is not enough. The agent needs structured output it can reason about.

    Orchestration behaviour. Understanding that the LLM picks which tool to call, in what order, and how to handle the result. You are not drawing the flow. You are writing instructions and designing tools so the LLM can draw the flow at runtime. If you are deciding whether Copilot Studio is even the right tool for what you are building, Copilot Studio Is Not Always the Answer is worth reading before you go further.

    A first build that teaches you the right mental model

    Pick a small real scenario. Something like: surface open tickets assigned to the current user and let them add a comment. Not a chatbot. An agent with a job.

    Create a new agent in Copilot Studio with generative orchestration enabled. Skip topics entirely for this first build. Write clear instructions describing what the agent does, what it does not do, and how it should respond when it cannot help.

    Add one knowledge source. A SharePoint site or a Dataverse table works well. Ask it questions against that knowledge and watch how it grounds.

    Add two tools. One Power Automate flow that reads data, one that writes. Make sure both return structured output, not just a success flag. Test what happens when the write fails. If the agent does not know it failed, fix the tool, not the agent.

    That is the entire first build. No trigger phrases. No dialog tree. No variables you manage manually. You will learn more in a week of this than a month of the traditional tutorial path.

    What to learn next once your first agent works

    Once that agent behaves reliably, then learn topics. Use them for the narrow cases where you need a deterministic script. Identity confirmation. Regulated disclosures. Multi-step forms with strict validation. Topics are good at this. They are bad as the primary way to build an agent.

    After topics, learn evaluation. Not just output testing. Behavioural testing. Does the agent handle incomplete questions, mid-conversation intent switching, and edge case inputs the way you expect? Most agentic workflows that feel intelligent in a demo turn out to be just fancy if/then logic in a trench coat when real users hit them. This is the single skill that separates agents that pass a demo from agents that survive production.

    Then learn MCP, custom connectors, and multi-agent orchestration. By that point you will have the mental model to evaluate whether you actually need them or whether a simpler design solves the problem.

    The fastest way to be useful with Copilot Studio in 2026 is not to learn every feature. It is to learn the four things above, build one real agent, and resist the pull of outdated tutorials that still dominate the first page of search results.

    Frequently Asked Questions

    How do I get started with Copilot Studio in 2026 without wasting time on outdated tutorials?

    Skip the classic topic-and-trigger-phrase approach and go straight to building a generative orchestration agent. Focus on writing clear instructions, connecting knowledge sources, and designing reliable tools rather than learning the node-based dialog editor.

    What is generative orchestration in Copilot Studio and why does it matter?

    Generative orchestration is now the default approach for new agents in Copilot Studio, where the agent uses AI to handle conversation flow rather than following a rigid dialog tree. It reduces the need to manually write dozens of trigger phrases and scales far better than the older topic-based model.

    Why does my Copilot Studio agent feel rigid and break when users ask unexpected questions?

    This usually happens when the agent is built around a topic tree with trigger phrases, which only handles the exact variations you anticipated. Switching to a generative orchestration approach with well-written instructions and grounded knowledge sources makes the agent much more flexible.

    When should I still use topics in Copilot Studio?

    Topics are still useful when a specific flow must follow a strict, predictable script, such as a regulated process or a form-style interaction with no variation. They work best as guardrails for those edge cases rather than as the foundation of the entire agent.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Why Power Automate Is Still Worth Learning in 2026

    Why Power Automate Is Still Worth Learning in 2026

    Developer reviewing Power Automate flow structure on screen, representing why you should learn Power Automate in 2026

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

    I keep hearing a version of the same idea from people just getting into the Microsoft stack. Why spend time learning Power Automate when you can describe what you want to a Copilot Studio agent and have it figure out the execution? The assumption behind that question is that Power Automate is scaffolding you work around, not something you need to understand. That assumption is costing people real time. If you want to learn Power Automate in 2026, the argument for doing it has not weakened. It has gotten stronger.

    The ‘Just Use an Agent’ Shortcut Has a Hidden Cost

    Copilot Studio agents and AI-assisted flow building have made it faster to get something working. That part is real. The problem is that faster to working and closer to production are not the same thing.

    I have seen this pattern repeatedly. Someone builds an agentic workflow, the demo runs cleanly, and then it breaks in production in a way they cannot explain. Not because the agent reasoning was wrong. Because the underlying flow had no retry logic, the connection was using a shared credential that hit a rate limit under load, or a step was silently failing and passing a null value forward. The agent kept going. The result was wrong. Nobody knew until downstream.

    I wrote about this dynamic in the context of agentic workflows before. An agent that generates a confident-sounding response for a task that did not complete destroys user trust faster than almost any other failure mode. The agent is the reasoning layer. Power Automate is still the execution layer. If you do not understand the execution layer, you cannot debug what the reasoning layer is telling you went wrong.

    What Power Automate Actually Does That Nothing Else Replaces

    Power Automate is where things actually run inside a Microsoft-stack enterprise. SharePoint events, Teams messages, Dataverse writes, approval routing, HTTP callouts to external APIs, scheduled jobs, document generation triggers. The connectors, the authentication, the retry behaviour, the action limits. All of it lives here.

    Copilot Studio can call a Power Automate flow. An AI Builder model can feed into one. An agent can trigger one. But the flow is what actually touches the system of record. When something goes wrong at 2am and you are looking at a run history, you need to know what you are reading. You need to know whether a 429 error is platform-level throttling or connector-level throttling, because the fix is different. I spent a full post on exactly that distinction and it is still one of the most common misdiagnoses I hear about. Applying the wrong fix because you conflated the two layers is a common reason throttling problems persist after troubleshooting.

    That kind of mechanical understanding does not come from describing what you want to an agent. It comes from building flows, watching them fail, and understanding why. The Microsoft Learn documentation for Power Automate covers the connector model and trigger types well, but the intuition for where things go wrong only comes from time in the tool.

    What I Would Focus on Learning First

    If I were starting today, I would ignore the visual polish and go straight to the things that bite you in production.

    Trigger types first. Automated, scheduled, and instant triggers behave differently. Understanding which one is firing your flow, and why, is foundational. A flow that should run once per item can run multiple times if the trigger is misconfigured and the conditions are wrong.

    Then connector authentication. Service principal vs. shared connection vs. connection reference. In enterprise environments, shared personal connections on flows that other people own is a support incident waiting to happen. Connection references and service principals exist for a reason. Learn them before you need them.

    Then error handling. Specifically, configure run after on every branch that matters. A flow that has no error path is a flow that fails silently. Silent failures in automation are worse than loud ones. I have written about how automated processes have no equivalent to a human noticing something feels off and escalating. Automating a bad process just makes it fail faster, and the exception silently propagates instead. Configure run after is the closest thing Power Automate gives you to that instinct.

    Apply to each concurrency settings come next. The default behaviour is sequential. Changing it to parallel speeds things up and introduces race conditions if you are not careful. Knowing when to use which, and how to tune it, matters the moment you are processing more than a handful of records.

    Where This Knowledge Starts Paying Off in More Advanced Work

    Once you understand how flows are structured and where they fail, everything built on top of them becomes more readable. Copilot Studio action steps that call flows stop being black boxes. You can look at what a cloud flow is doing inside an agent and understand whether the tool response is reliable. You can design the tool contract properly instead of returning a status that gives the agent nothing to evaluate.

    The people I talk to at other organisations who are building agentic workflows that actually hold up in production share one thing. They did not skip the foundation. They know what happens inside the flow the agent is calling. They know what a bad intermediate result looks like and they have built the error paths to catch it before it propagates.

    The practitioners skipping straight to orchestration are building things that look impressive in demos and require constant firefighting after launch. That gap in reliability traces back to the same place every time. They do not know the execution layer well enough to control it.

    Learning Power Automate in 2026 is not about catching up on something old. It is about having the mechanical understanding that makes everything else you build on the Microsoft stack actually reliable. That foundation is still the thing that separates flows that work from flows that work until they do not.

    Frequently Asked Questions

    Is it still worth it to learn Power Automate in 2026?

    Yes, learning Power Automate in 2026 remains valuable because it is the execution layer for almost everything that runs inside a Microsoft-stack enterprise. AI tools and agents can help you build flows faster, but you still need to understand how flows work to debug failures, handle errors, and get workflows into production reliably.

    What is the difference between Copilot Studio and Power Automate?

    Copilot Studio handles the reasoning and decision-making layer, while Power Automate is the execution layer that actually interacts with systems like SharePoint, Dataverse, and external APIs. An agent can trigger a flow, but the flow is what performs the real work and touches the system of record.

    Why does my Power Automate flow work in testing but fail in production?

    Common causes include missing retry logic, shared credentials hitting rate limits under load, or steps that silently fail and pass null values forward. These issues are easy to miss during demos but become serious problems at scale, which is why understanding flow structure matters beyond just getting something running.

    When should I learn Power Automate instead of relying on AI-generated flows?

    You should invest in learning Power Automate when you are responsible for workflows that need to be reliable in production, not just functional in a demo. If you cannot read a run history or diagnose a throttling error, you will struggle to fix failures that AI tooling alone cannot explain.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat

    Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat

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

    People keep asking in the community what makes an agentic workflow actually useful. The honest answer is that most things being called agentic workflows right now are not. They are linear automations with a language model bolted on for the response step. That distinction matters more than most teams realise when they start building.

    What a Useful Agentic Workflow Actually Does

    A useful agentic workflow does something a standard Power Automate flow cannot: it makes decisions mid-execution based on context it discovered during the run, not based on conditions you hard-coded before it started.

    That sounds obvious. It is not, in practice.

    A flow that checks a field value and routes left or right is not an agent. An agent is something that can retrieve information it did not start with, reason about what that information means for the current task, and take a different action than you would have anticipated when you designed it. The key word is discovered. The agent had to go and find out something, then act on it.

    If you can fully diagram the execution path before the workflow runs, it is probably not agentic. It is a well-structured flow. There is nothing wrong with a well-structured flow. But you should not be paying the overhead of agent infrastructure to build one.

    Where Teams Go Wrong Building Agentic Workflows

    The most common mistake I see is treating the language model as the agent. The LLM is not the agent. The LLM is the reasoning layer. The agent is the system that decides when to call what tool, handles what comes back, and determines whether the result is good enough to proceed or whether it needs to try something else.

    When that orchestration layer is weak or missing, you get a workflow that calls one tool, takes the output at face value, and moves on. That is not reasoning under uncertainty. That is a glorified lookup with a friendly response message.

    I wrote about silent action failures in the context of Copilot Studio earlier (the production testing post covers this in detail). The same failure mode appears in agentic workflows, but it is worse because the agent has more steps where it can silently accept a bad result and keep going. A flow fails at a specific action. An agent can propagate a bad intermediate result through three more steps before anything looks wrong.

    The Two Things That Make or Break an Agentic Workflow

    Based on what I have built internally and what I hear from people at other organisations, it comes down to two things.

    First: tool design. The actions available to your agent need to return enough context for the agent to evaluate them, not just a success or failure signal. If your Power Automate flow returns {"status": "done"}, the agent has no way to assess whether done means what the user needed. It will treat it as success. Your tools need to return structured, interpretable output. This is not a language model problem. It is an API design problem.

    Second: failure handling that is explicit, not optimistic. A useful agent knows when it is stuck and does something about it. That might mean escalating to a human, asking the user for clarification, or stopping cleanly with an honest message. What it does not do is generate a confident-sounding response for a task that did not complete. That is the failure mode that destroys trust in agents faster than anything else, because the user finds out later, not immediately.

    I covered how this plays out in Copilot Studio specifically in the post on when Copilot Studio is the wrong choice. But the principle applies regardless of the tooling. An agent that cannot fail gracefully is not useful in production. It is a liability.

    What Agentic Workflows Are Actually Good For

    The use cases where agentic workflows justify their complexity share a few characteristics. The task has multiple possible paths and you cannot enumerate them all upfront. The inputs are unstructured or variable enough that rule-based routing breaks down. The system needs to recover from partial failures without a human in the loop for every edge case.

    Document processing that involves extracting, validating, cross-referencing, and then acting on extracted data is a reasonable fit. Multi-step research tasks where what you search for next depends on what you found are a reasonable fit. Anything where the decision logic changes frequently and hard-coding it into a flow becomes a maintenance problem is worth evaluating. Before committing to that architecture, though, it is worth asking whether the underlying process is actually sound — automating a bad process just makes it fail faster, and agentic workflows are no exception.

    A status check is not a fit. A single-action task triggered by a button is not a fit. Anything you can build cleanly as a Power Automate flow with proper error handling is probably not worth the overhead of an agentic architecture. The orchestration cost is real and the debugging surface is larger.

    The Test I Use

    Before committing to an agentic workflow architecture, I ask one question: does this task require the system to discover something during execution that changes what it does next, and would that discovery be different for different runs? As Halilcan Soran on LinkedIn, I have found this single question filters out more false positives than any other test I use.

    If yes, agents are worth the investment. If no, you are adding complexity to solve a problem that a well-built flow could handle, and you will spend more time debugging Claude or other AI agent behaviour than you saved on logic design.

    The technology is not the constraint. Knowing what you are actually building is.

    Frequently Asked Questions

    What

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Adding Copilot to Your Power App Is Not the Same as Making It Smarter

    Adding Copilot to Your Power App Is Not the Same as Making It Smarter

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

    Microsoft published a post this week about making business apps smarter by embedding Copilot, app skills, and agents directly into Power Apps. The features are real and some of them are genuinely useful. But I keep seeing teams read announcements like that and immediately open their existing apps to start wiring things in. That is where it goes wrong. Adding Copilot to Power Apps does not make the app smarter. It makes the AI visible. Those are different things.

    What App Skills and Agent Integration Actually Do Under the Hood

    When you expose a Power App as an app skill or embed a Copilot Studio agent into a canvas app, you are giving the AI a surface to operate on. The agent can read context from the app, trigger actions, and return responses into the UI. In theory, the AI bridges what the user needs and what the app can do.

    In practice, the agent is only as capable as what you hand it. It reads data from your app’s data sources. It calls the actions you have defined. It interprets user intent against the topics and instructions you have written. If your data model is inconsistent, your actions are incomplete, or your process logic has gaps, the agent does not compensate for any of that. It just operates on top of it and returns confident-sounding responses anyway.

    I wrote about this problem in a different context when covering why Copilot Studio agents fail in production. Silent action failures are one of the nastiest issues: the agent completes its response, the user thinks something happened, nothing actually did. That risk does not disappear when you move the agent inside a Power App. If anything, it gets harder to spot because users expect the app to be reliable.

    Why the Data Model and UX Structure Matter More Than the AI Feature

    Most Power Apps I have seen built inside large organisations were designed around a specific, narrow workflow. The data model reflects decisions made at the time of build, often under time pressure, often by someone who is no longer on the team. Fields are repurposed. Status columns hold values that mean three different things depending on which team is using them. Lookup tables have orphaned records nobody cleaned up.

    When you put an agent on top of that, the agent queries this data and tries to give useful answers. The answers will be coherent. They will not be correct. Not reliably.

    The UX structure compounds this. Canvas apps built for point-and-click navigation do not automatically become good AI surfaces. If a user can ask the agent to update a record, but the app’s own form has fifteen required fields and three conditional rules that only run client-side, you now have a conflict between what the agent can do via a Power Automate action and what the app enforces through its UI. One of them will win. It will not always be the right one.

    This is the same argument I made about automating a bad process. The automation does not fix the process, it executes it faster and more consistently, including the broken parts. Embedding AI into a poorly structured app works the same way.

    What I Check Before Wiring Any Agent Into an Existing App

    Before I connect anything to a Copilot Studio agent or enable app skills on an existing Power App, I go through a short audit. Not a formal document. Just four questions that save a lot of cleanup later.

    • Is the data model clean enough to query? If the same concept is stored in three different columns across two tables with inconsistent naming, the agent will surface that inconsistency directly to the user. Fix the model first.
    • Are the actions the agent can trigger complete and safe? Every Power Automate flow an agent can call needs proper error handling and a defined failure response. Silent failures inside agent topics are a known problem. If the flow does not return a clear success or failure, the agent cannot respond accurately.
    • Does the app enforce rules that the agent needs to know about? If business logic lives only in Power Fx expressions inside the app’s forms, the agent does not see it. Validation that matters needs to exist at the data layer or inside the flows the agent calls.
    • Is the process the app supports well-defined enough to describe to an AI? If I cannot write a clear system prompt describing what the agent should and should not do in this app, the process is not ready. Ambiguity in the process becomes ambiguity in agent behaviour.

    When Embedding AI in a Power App Is Worth It and When It Is Not

    There are genuinely good cases for this. An app where users regularly need to find records across complex filters is a reasonable candidate. Surfacing a conversational shortcut to navigate a large dataset, trigger a common action, or get a summary of a record without clicking through multiple screens can reduce real friction. I have seen it work well when the underlying data is clean and the scope of what the agent can do is narrow and explicit.

    The cases where it is not worth it yet are more common. An app with inconsistent data. A process with unresolved exceptions. A UX that was never designed with AI interaction in mind. In those situations, embedding an agent creates a new layer of support burden without a proportional benefit.

    I also want to be direct about something I mentioned in my post on when Copilot Studio is the wrong choice: not every interaction benefits from being conversational. Some things in a Power App are faster as a button. The AI control is not always an upgrade on a well-placed filter or a clear form layout.

    Connect with Halilcan Soran on LinkedIn for more insights on Power Apps and AI integration.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Most Copilot Studio Agents Should Have Been Flows

    Most Copilot Studio Agents Should Have Been Flows

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

    Updated August 2026 rewritten to cover agent flows, multi-agent orchestration, and consumption billing, all of which changed the decision math since this post first went up.

    I keep seeing this on LinkedIn and in community forums. Someone describes an internal use case, and the first five replies are all “have you tried Copilot Studio?” The tool has gotten good enough that it has become the reflexive answer to any question involving automation, conversation, or AI. That reflex is causing real problems, and it got worse over the past year, not better. Knowing when Copilot Studio is the wrong tool is as important as knowing how to build with it well.

    When Copilot Studio Is the Wrong Tool for the Job

    Most misuse I see falls into one of three situations. The use case is purely transactional. The interaction model is not conversational. Or the team wants a workflow, not an agent.

    If someone needs to submit a form, approve a request, or trigger a process on a schedule, that is Power Automate territory. Putting a conversational interface in front of a single-action task does not make it better. It makes it slower, harder to test, and harder to maintain. Users do not want to type a sentence to do something they could do in two clicks.

    The second situation is harder to spot. Some interactions look conversational but are not. A knowledge base search, a document lookup, a status check. These are point-in-time queries with no real back-and-forth. You could build them in Copilot Studio. You could also build them as a Power Apps canvas app with a simple search interface and ship it in a day with fewer moving parts and a much more predictable failure surface.

    The Hype Got Louder, the Question Stayed the Same

    Since I first wrote this post, Copilot Studio picked up autonomous agents, multi-agent orchestration, MCP tool connections, and agent flows. That is a genuinely bigger toolbox. It also means the “have you tried Copilot Studio?” reflex now covers even more ground, because the tool can technically do almost anything.

    Notice what Microsoft did with agent flows, though. They put deterministic, workflow-style automation inside the agent product. That is a quiet admission of the exact point this post makes: a large share of what people were building as conversational agents never needed a conversation. It needed a sequence of steps that runs the same way every time.

    The other change that matters is billing. With consumption-based messages, every generative answer and every agent action has a metered cost. A flow that runs a thousand times a day is a known quantity. An agent that reasons its way through a thousand sessions a day is a variable one. I ran into this internally on a triage agent where the message consumption was several times the initial estimate, purely because users chatted more than the design assumed. If your use case can be a flow, the flow is cheaper, and the cost is predictable before you ship.

    The Agent Complexity Problem

    There is also a complexity ceiling that teams hit faster than expected. Copilot Studio agents work well when the conversation scope is tight. One domain. A few topics. Defined intents. When someone tries to build a single agent that handles HR queries, IT requests, and finance approvals inside the same session, topic routing starts failing at the edges. I wrote about this in Your Copilot Studio Agent Passed Every Test and Still Failed in Production. When a user’s phrasing sits between two topics, the agent picks one confidently and gets it wrong.

    Multi-agent orchestration was supposed to fix this, and it helps. You can now build narrow specialist agents and route between them instead of stuffing everything into one. But orchestration does not remove the routing problem. It moves it up a level. Now the orchestrator can hand off to the wrong specialist, and you are debugging a conversation across agent boundaries instead of across topics. It is a better architecture for genuinely complex domains. It is not a reason to make a simple use case complex.

    Where the Wrong Choice Usually Starts

    It usually starts with the framing of the requirement. Someone says “we want an agent” and that phrase triggers Copilot Studio before anyone has defined what the interaction actually needs to do. Two years ago the phrase was “we want a chatbot.” The word changed, the mistake did not. I have watched teams spend weeks building agent topics, writing instructions, and wiring up actions, when what the users actually wanted was better SharePoint search and a weekly digest email.

    The honest question to ask before opening Copilot Studio is this: does this use case genuinely require back-and-forth conversation, or does it just need to surface information or move data? If the answer is the second one, there is almost always a simpler path.

    This is not a knock on Copilot Studio. The tool is genuinely capable when it fits the problem. Multi-turn conversations, routing across complex intent patterns, integrating generative answers with structured actions, autonomous work over connected tools. Those are things it does well. But that capability comes with real operational cost. There is a topic structure to maintain, instructions that drift when production data introduces edge cases, and actions that can fail silently inside a topic and return a confident-sounding response for work that was never done.

    What to Reach for Instead

    Power Apps for anything with a fixed interaction model. Canvas apps are underrated for internal tooling. They give you a defined UI, predictable state, and a clear place to debug when something breaks.

    Power Automate for anything triggered, scheduled, or event-driven. If there is no user in the loop having a conversation, there is no reason for a conversational agent to be involved. Keep in mind that even straightforward flows run into issues at scale, as Power Automate throttling limits will break your flow in production under real load if you have not accounted for them.

    SharePoint or Dataverse with a search interface for knowledge retrieval. If users are looking something up, build a search experience, not a conversational one.

    In enterprise environments, the governance overhead also matters. You are managing an agent that generates natural language responses. That quality needs to be reviewed, monitored, and occasionally corrected. People I talk to at other orgs consistently underestimate this cost until the first bad answer lands in front of a director. Add the consumption billing on top and the total cost of an agent is much higher than the demo suggests.

    My working rule after a few years of building these things full time: reach for Copilot Studio when the conversation is the product. Reach for everything else when the conversation is decoration. If you disagree, or you have hit a case that breaks this rule, tell me about it. I collect these on LinkedIn and they regularly change how I think about this.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Your Copilot Studio Agent Passed Every Test and Still Failed in Production

    Your Copilot Studio Agent Passed Every Test and Still Failed in Production

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

    I came across a post from Zapier Blog about AI agent evaluation, and it described something I keep seeing inside large organisations: an agent that looks perfect in a demo, gets signed off, goes live, and then immediately starts doing things nobody expected. Wrong tool calls. Conversation loops that never resolve. Outputs that look confident and are completely wrong. The post frames this well as a sandbox problem. But the fix it describes, better test coverage and smarter metrics, only gets you partway there. The deeper issue with Copilot Studio agent testing is not the quantity of your tests. It is what you are actually testing for.

    Why Demo-Passing Agents Break in Real Workflows

    When a team builds an agent in Copilot Studio, they test it against the happy path. A user asks a clean question. The agent triggers the right topic or action. The response looks good. Someone in the review meeting says it works great. The agent gets promoted to production.

    The problem is that real users do not ask clean questions. They ask incomplete ones. They switch intent halfway through a conversation. They paste in text that includes formatting your prompt never anticipated. They use your agent for things it was never designed to do, because nothing in the interface tells them not to.

    None of that shows up in a demo. It shows up three days after go-live when someone forwards you a conversation log that reads like a stress test you forgot to run.

    The Three Failure Modes I Keep Seeing in Copilot Studio Agents

    After building and reviewing a number of agents internally, the failures cluster into three patterns.

    Topic misrouting at the edges. Your agent routes correctly when the user says exactly what you expected. But natural language is messy. When a user’s phrasing sits between two topics, the agent picks one confidently and gets it wrong. You only discover this when someone captures a failed session and traces it back. By then, a dozen other users have hit the same wall and just stopped using the agent.

    Action failures that degrade silently. A Power Automate flow or a connector action fails in the background and the agent carries on as if nothing happened. No error surfaced. No fallback triggered. The user gets a response that implies the task completed. It did not. This is the agent equivalent of a flow that retries quietly and masks the problem until the load goes up. I wrote about that pattern in the context of Power Automate throttling limits breaking flows under real load. The same logic applies here: silent success is not success.

    Prompt instruction drift under real data. Your system prompt was written against clean test data. Production data is not clean. It has unexpected characters, long strings, mixed languages, or values that push the model toward an interpretation you did not intend. The agent’s behaviour drifts. Not catastrophically. Just enough to become unreliable in ways that are hard to reproduce and harder to explain to stakeholders.

    How to Build a Behavioral Test Suite Instead of an Output Checklist

    Most teams build an output checklist. Did the agent return the right answer for these ten questions? That tells you almost nothing about production behaviour.

    What you actually need is a behavioral test suite. The difference is this: output testing checks what the agent said. Behavioral testing checks how the agent handled the situation.

    Here is how I approach it inside Copilot Studio before promoting anything to production.

    Build adversarial input sets, not just representative ones. For every topic your agent handles, write three versions of the trigger: the clean version, an ambiguous version that could belong to two topics, and a broken version with incomplete or oddly formatted input. If the agent routes all three correctly, you have something worth shipping. If it fails on the ambiguous case, you have a routing gap that will hit real users constantly.

    Test conversation state, not just single turns. Copilot Studio agents hold context across a conversation. Test what happens when a user changes their mind on turn three. Test what happens when they ask a follow-up that assumes context the agent should have retained but might not. Single-turn testing misses an entire class of failure that only appears in multi-turn sessions. This is also why agentic workflows require a fundamentally different design approach, not just an AI layer placed on top of existing processes.

    Inject real data samples into action inputs. Pull a sample of actual data from your environment and run it through the actions your agent calls. Do not use synthetic test data if you can avoid it. Real data has edge cases your synthetic data will never cover. If your agent calls a flow that queries a SharePoint list, run the query against the actual list with actual entries, including the ones with blank fields and formatting you did not anticipate.

    Define explicit fallback behaviour and test it deliberately. Every agent should have a defined behaviour for when it cannot complete a task. Most teams add a fallback topic and assume it works. Test it by constructing inputs that should trigger it. If the fallback does not fire, or fires on the wrong inputs, fix it before go-live. A graceful failure is far better than a confident wrong answer.

    What to Monitor After Go-Live and When to Pull an Agent Back

    Testing before launch is necessary but not sufficient. Agent behaviour shifts as the inputs it receives in production diverge from what you tested against. You need monitoring in place from day one.

    Track escalation rate and abandon rate per topic. If a topic is seeing significantly higher escalations than others, that is a signal of routing or response quality problems, not user error. Track action failure rates separately from conversation outcomes. An agent can complete a conversation and still have failed to do the thing the user needed.

    Set a threshold before launch. If escalation rate exceeds a number you agree on in advance, or if a specific action is failing more than a defined percentage of the time, you pull the agent back or disable the affected topic. The threshold is arbitrary. Having no threshold at all is not.

    The agents I have seen hold up in production are not the ones with the most sophisticated prompts. They are the ones where someone spent real time on the failure cases before launch and built actual monitoring into the plan from the start.

    If you are still signing off agents based on demo performance, you are not testing. You are hoping.

    Frequently Asked Questions

    Why does my Copilot Studio agent testing pass in demos but fail in production?

    Most Copilot Studio agent testing is built around ideal user inputs and predictable conversation paths, which do not reflect how real users actually behave. In production, users ask incomplete questions, switch intent mid-conversation, and use the agent in unintended ways that no demo ever surfaces. Testing needs to go beyond the happy path to catch these edge cases before go-live.

    What are the most common failure modes in Copilot Studio agents?

    The three patterns that appear most often are topic misrouting when user phrasing falls between two intents, action failures that complete silently without triggering any error or fallback, and prompt instructions that break down when they encounter messy real-world data. Each of these can go undetected in testing because they only emerge under realistic conditions.

    How do I know if a Power Automate action failed inside my Copilot Studio agent?

    Silent action failures are a serious risk because the agent can continue the conversation and imply a task completed when it did not. You need explicit error handling and fallback logic in your flows so that failures surface to the user rather than being masked by a confident-sounding response.

    When should I test my Copilot Studio agent against real production data?

    You should test against realistic data before promotion to production, not after. System prompts written against clean test data can behave unpredictably when they encounter unexpected characters, mixed languages, or long strings that only appear in live environments. Incorporating a sample of real or representative data into your test suite is a necessary step before sign-off.

    Source: AI agent evaluation: How to test + improve AI agents (Zapier Blog).

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn