Why does running Claude on Amazon Trainium matter for enterprise AI deployments?

The real benefit of Claude on Amazon Trainium for enterprise is not raw chip performance but improved supply, capacity, and price stability for inference workloads. Enterprises building production automations have historically struggled with throttling and unpredictable costs tied to GPU scarcity, and Trainium offers a credible path to more reliable, affordable access.

Why does my Power Automate flow keep getting slow or failing when using Claude?

The most common culprit is shared inference pool capacity, especially during peak hours, which causes latency spikes and occasional rate limit errors. Even with a retry policy in place, the delay is often long enough that users abandon the process before it completes.

How do I control Claude API costs in a high-volume Power Automate flow?

Treat your system prompt like code and review it regularly, because prompts tend to grow over time as edge cases and guardrails are added, multiplying your input token costs across every invocation. Moving context that is only relevant to certain topics into retrieval rather than including it in every call can significantly reduce per-run costs.

When should I start worrying about token cost drift in an AI automation?

Token cost drift can begin within weeks of deploying an agent as system prompts expand to handle new requirements and edge cases. The per-call cost often still looks small, so the problem tends to go unnoticed until the monthly total becomes difficult to justify.

What is Power Platform governance and why does it matter?

Power Platform governance is the set of policies, environments, and controls that shape how people build and share apps, flows, and agents in your organisation. When designed well, it protects the business without slowing down the people trying to do useful work. When designed poorly, it either locks everything down or lets chaos grow unchecked.

How do I set up Power Platform governance without killing adoption?

Treat governance as a product where makers are the users, not a security checklist applied on top of them. Give people a managed environment they can access quickly, document the DLP policies clearly, and make the approved path easier than any workaround. If the process to get started takes weeks, people will find another way.

Why does my Power Platform app break when it moves from Dev to Production?

This usually happens because DLP connector policies differ between environments and those differences are not documented anywhere. A connector allowed in your Dev environment may be blocked in Production, which silently breaks apps or flows at go-live. Writing down the DLP differences for each environment and testing against them before promotion prevents this.

When should I reassign Power Platform flows and apps after someone leaves the organisation?

Reassignment should happen within a defined window as soon as someone leaves, not reactively when something breaks. Flows and apps owned by former employees can keep running in production for years with no clear owner, which creates a serious operational and security risk. Power Platform PowerShell modules can automate much of this process.

Which is better, Claude vs ChatGPT for automation workflows?

Choosing between Claude and ChatGPT for automation is less about which model performs better in general benchmarks and more about how each behaves inside a pipeline. The criteria that matter are structured output reliability, tool-calling accuracy, and how well the model holds instructions as context grows. Testing both models against your specific workflow conditions will tell you far more than any consumer comparison.

Why does my AI agent start producing errors after working fine at first?

This often happens because the model experiences instruction drift as context accumulates over time. Long flows gather user inputs, tool results, and retrieved documents, and some models struggle to maintain consistent behaviour at high token counts. Testing your model under realistic context lengths before going to production can help catch this early.

How do I choose an AI model for a Power Automate or Copilot Studio flow?

Focus on how the model handles structured outputs, selects the right tools when multiple connectors are available, and behaves when context is long rather than short. Consumer benchmarks test models in isolation, but real automation pipelines require consistent, predictable behaviour across repeated calls with varying inputs. Running your own tests against your actual schema and tools will give you more reliable answers.

What causes silent failures in AI automation workflows?

One of the most common causes is inconsistent structured output, where a model occasionally adds unexpected formatting, drops required fields, or wraps a response in a code block instead of returning clean JSON. These errors can pass through without triggering obvious alerts while still breaking downstream actions. Testing output stability across many varied inputs is one of the most important steps before deploying a model-powered flow.

What are codex automations scheduled AI runs and how do they work?

Codex automations scheduled AI runs are recurring AI tasks that fire on a set schedule, where the model performs reasoning rather than following a fixed, pre-wired set of actions. Unlike a traditional scheduled flow, the AI decides what to read, compare, summarise, or flag each time it runs. This makes them suited to tasks where the inputs vary but the goal stays the same.

How do I know when to use a scheduled AI run instead of a Power Automate flow?

If you can map out every branch and action of a task before it runs, a standard flow is the right tool. When the output requires interpretation, prioritisation, or judgement based on inputs that change each time, a scheduled AI run is a better fit. Tasks like triaging alerts, reviewing documents for meaningful changes, or summarising error logs fall into this second category.

Why does a scheduled Power Automate flow struggle with fuzzy or variable logic?

Power Automate flows are deterministic, meaning they follow the same paths every time regardless of context. When the logic requires understanding nuance or making a judgement call, the flow typically ends up forwarding everything to a human rather than completing the work itself. The flow becomes a delivery mechanism rather than a true automation.

When should I consider replacing a recurring manual review task with an AI automation?

If a task runs on a regular cadence, involves inputs that vary in structure, and produces an output that is a summary, ranking, or decision rather than a fixed result, it is a strong candidate for AI automation. Examples include weekly pull request reviews, overnight alert triage, and monthly document audits where a human currently does the interpretation work.

How do I set up a Power Platform agent GitHub integration in an enterprise environment?

Start by mapping which Power Platform environments need to connect to which GitHub organisations, and what DLP policies apply to each. You cannot assume a connection that works in Dev or UAT will behave the same way in Production, since connector classifications can differ across environments. Sorting out service account credentials and token rotation policies before you build will save significant rework later.

Why does my Power Platform agent work in UAT but fail in Production when connecting to GitHub?

The most common cause is a difference in DLP policies between environments. The GitHub connector may be classified as allowed in your UAT environment but blocked or restricted in Production, which stops the connection from loading at all. The agent will often still respond but return empty results, making the failure easy to miss until users report it.

What is environment sprawl and why does it matter for Power Platform agent deployments?

Environment sprawl refers to the accumulation of multiple Power Platform environments across an organisation, each with its own DLP rules, security posture, and connector permissions. It matters for agent deployments because a GitHub connection that is permitted in one environment may be completely blocked in another, and most teams do not map these differences before they start building.

When should I use a service account instead of personal authentication for a GitHub connector in Power Platform?

Any time the agent is intended for a team or production use case, a service account is the right choice over personal authentication. Personal credentials tie the connection to an individual user, which creates access and continuity risks when that person changes roles or leaves the organisation. A shared service account also makes token rotation and permission auditing much easier to manage.

What are OpenAI Workspace Agents?

OpenAI Workspace Agents let users describe a repeatable task, connect tools, and have an agent run it on a schedule or on demand. They use a conversation-first approach, meaning you define what you want through chat rather than building a visual workflow diagram.

How do OpenAI Workspace Agents compare to Power Automate?

Both handle triggers, actions, and conditions to automate tasks, so they overlap significantly in what they can do. The key difference is how you build them: Power Automate starts from a visual flow diagram, while Workspace Agents start from a conversation with the model.

When should I use Power Automate instead of a conversational agent?

Power Automate is better suited when you need clear error handling, version control, and a fully inspectable execution path. Conversation-first tools like Workspace Agents work well when you want to define an outcome and let the model determine the steps.

Why does the rise of OpenAI Workspace Agents matter for enterprise automation builders?

As more people use conversational AI tools like ChatGPT in their personal lives, they will expect a similar experience in workplace tools. This raises the bar for how automation platforms present themselves, even if enterprise governance and compliance requirements still favour established platforms.

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.

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.

When should I use SharePoint lists for Power Platform apps instead of Dataverse?

SharePoint lists are a strong fit when your app is internal, used by fewer than a few hundred people, and will never exceed tens of thousands of items in a single list. Common examples include approval queues, request forms, training trackers, and asset inventories where a flat schema with a few lookup fields covers everything you need.

Why does using SharePoint as a Power Platform backend save money on licensing?

Power Automate flows that connect to SharePoint use the standard connector, which does not require a premium licence. In large organisations where thousands of users might trigger a flow indirectly, avoiding premium connector requirements can add up to significant budget savings compared to a Dataverse-backed solution.

What are the security and governance features available with SharePoint lists?

Modern SharePoint lists authenticate through Entra ID and are covered by your organisation's DLP policies. Audit logs feed into the same Purview tenant as your other Microsoft 365 services, so governance and compliance requirements are met without additional configuration.

How do I know if Dataverse is actually necessary for my Power Platform project?

If a solution is genuinely enterprise in scale, involving complex relational data, high record volumes, or advanced role-based security requirements, Dataverse earns its place. However, if the data model is a few flat lists with simple lookups and the user base is a small internal team, reaching for Dataverse by default adds cost and complexity without a clear engineering benefit.

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.

Category: Artificial Intelligence in Business

Anthropic Running Claude on Trainium Matters More for Enterprise Than the Benchmarks Suggest

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

Most of the coverage of Anthropic running Claude on Amazon’s Trainium chips frames it as a benchmark race. Faster training. Cheaper inference. Another shot at Nvidia. That framing misses what actually matters if you are building production automations. The thing that should make enterprise Power Platform and AI people pay attention to claude on amazon trainium for enterprise is not raw performance. It is supply, capacity, and price stability.

I have been building Claude-backed flows internally for a while now. The model quality has not been my problem. The economics and the throttling have.

Why the Trainium Story Is Actually a Capacity Story

When you read about Anthropic moving serious training and inference onto Trainium, the interesting part is not whether the chip beats an H100 on some synthetic benchmark. The interesting part is that for the first time there is a credible path to Claude pricing that is not entirely tied to Nvidia GPU scarcity.

If you have ever tried to scale a customer-facing agent on a shared inference pool, you know what I mean. Peak hours hit. Latency drifts up. Occasionally you get a 429. Your Power Automate flow has a retry policy, sure, but the user already saw the spinning circle for nine seconds and moved on.

Capacity is the silent killer. Benchmarks are the loud distraction.

What Token Cost Drift Looks Like in a Real Power Automate Flow

Here is the thing nobody tells you when you slot Claude into a flow through Bedrock or the API. The first version of your agent has a tight system prompt. Maybe 800 tokens. Then someone asks for a new edge case. You add a few examples. Then someone reports a wrong answer, so you add a guardrail paragraph. Then you add tool descriptions. Then you add a few more examples because the tool descriptions confused the model.

Six weeks later your system prompt is 4,200 tokens. Every single invocation pays for those tokens. If your flow runs 12,000 times a month, you just multiplied your input cost by five and nobody noticed because the per-call cost still looks tiny on the invoice.

I learned this the hard way on an internal agent. The unit cost looked fine. The monthly bill did not. The fix was not switching models. The fix was treating the system prompt like code, with a review step, and splitting context that only some topics need into retrieval rather than baking it into every call.

This is the part where chip economics actually touch your Power Automate flow. If inference cost per token drops because Anthropic has cheaper compute, that bloated prompt hurts less. If it does not drop, your business case erodes quietly while you build more features on top.

Bedrock vs Direct Anthropic API for Enterprise Automation Workloads

People ask me which one to use. The honest answer is it depends on what your governance team will sign off on, not what the model does.

Bedrock gives you the AWS contract, the data residency story, the IAM model your security team already understands, and provisioned throughput as an option. The direct Anthropic API gives you faster access to new models and sometimes better pricing on burst usage.

For anything customer-facing or anything that touches regulated data, Bedrock usually wins on the paperwork alone. For internal experimentation and prototypes, the direct API is fine. The mistake I see people make is prototyping on the direct API and then trying to lift and shift to Bedrock at the last minute. Region availability, model version naming, and quota structure are different enough that you will burn a sprint on it.

Pick the path your production version will live on. Build there from day one. If you are still weighing how Claude fits into your automation architecture more broadly, Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now covers where it actually earns its place as a reasoning layer.

How I Would Plan Claude Capacity for an Agent You Actually Depend On

If the agent matters, on-demand inference is not enough. Provisioned or reserved capacity is starting to look less like a luxury and more like a baseline. Latency Is the Quiet Killer of Agentic Workflows and Almost Nobody Talks About It goes into how to budget round-trip time before you build, and the same logic applies to capacity. A flow that works at 2pm on Tuesday and times out at 10am on Monday is not a production system. It is a demo with good luck.

Three things I would actually do.

Measure your real token distribution. Not the average. The 95th percentile input and output. That is what your capacity needs to handle, not the median case.

Separate your workloads. The agent that drafts an email for an internal user can sit on shared on-demand inference. The agent that responds to a customer in under three seconds cannot. Different SLAs, different capacity tiers.

Track cost per successful outcome, not cost per call. An agent that fails 20 percent of the time and gets retried is twice as expensive as the invoice suggests. This is where bad tool design quietly destroys your unit economics. If you are unsure whether the model choice even matters as much as you think for automation workloads, Claude vs ChatGPT Is the Wrong Question When You Are Building Automations is worth reading before you optimize the wrong variable.

The Trainium news matters because it changes the long-term curve on what any of this costs. But the curve only helps you if your architecture is set up to benefit from it. Bloated prompts, on-demand only inference, and no measurement of cost per outcome will eat any savings the chip story delivers.

Read the news through that lens. The benchmarks are not the point.

Frequently Asked Questions

Why does running Claude on Amazon Trainium matter for enterprise AI deployments?

The real benefit of Claude on Amazon Trainium for enterprise is not raw chip performance but improved supply, capacity, and price stability for inference workloads. Enterprises building production automations have historically struggled with throttling and unpredictable costs tied to GPU scarcity, and Trainium offers a credible path to more reliable, affordable access.

Why does my Power Automate flow keep getting slow or failing when using Claude?

The most common culprit is shared inference pool capacity, especially during peak hours, which causes latency spikes and occasional rate limit errors. Even with a retry policy in place, the delay is often long enough that users abandon the process before it completes.

How do I control Claude API costs in a high-volume Power Automate flow?

Treat your system prompt like code and review it regularly, because prompts tend to grow over time as edge cases and guardrails are added, multiplying your input token costs across every invocation. Moving context that is only relevant to certain topics into retrieval rather than including it in every call can significantly reduce per-run costs.

When should I start worrying about token cost drift in an AI automation?

Token cost drift can begin within weeks of deploying an agent as system prompts expand to handle new requirements and edge cases. The per-call cost often still looks small, so the problem tends to go unnoticed until the monthly total becomes difficult to justify.

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

April 25, 2026
Power Platform Governance That Does Not Kill Adoption

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

I keep seeing the same pattern on LinkedIn and in conversations with people at other organisations. Power Platform governance gets handed to a security team, they lock everything down, and six months later nobody is building anything. Then someone writes a post about low adoption and blames the makers. It is not the makers. It is the governance design.

Good Power Platform governance is not about stopping people. It is about making the safe path the easy path. If your governance model forces a citizen dev to file three tickets and wait two weeks to use a SharePoint connector, you do not have governance. You have a queue.

The two failure modes of Power Platform governance

Every governance setup I have seen fails in one of two ways.

The first is the lockdown. Default environment is disabled for everyone. Every connector is in the Blocked DLP group unless explicitly approved. New environments require a business case signed by three people. Makers give up and go back to Excel macros. Shadow IT grows in Teams and OneDrive where nobody is watching.

The second is the free-for-all. Everyone builds in the default environment. No DLP. No naming conventions. Flows owned by people who left two years ago still run in production because nobody knows what they do or who to ask. The CoE Kit is installed but nobody looks at the dashboards.

Both end in the same place. Leadership decides Power Platform does not work for the enterprise. The real problem was never the platform.

What actually works

The teams I talk to who have this working treat governance as a product with makers as the users. That framing changes everything.

They have a managed maker environment that anyone in the org can request access to in under an hour. Standard connectors are in the Business group. Premium and risky connectors need justification but the path is documented. People know where to go.

They have a promotion path from maker environment to a shared Dev, then UAT, then Prod. Each environment has different DLP settings and the differences are written down. This is the part most teams miss. I wrote about this before in the context of Power Platform agents and GitHub integration, where a connector sitting in Business in Dev and Blocked in Prod silently kills an agent at go-live. Same pattern applies to any flow or app that crosses environments.

They have an ownership policy that actually runs. When someone leaves, their flows and apps get reassigned within a defined window, not forgotten. The Power Platform PowerShell modules handle most of this if you script it. The CoE Kit is fine for inventory but I have stopped relying on it as the source of truth for ownership because the lag is too long.

DLP policies that do not punish makers

Most DLP policies I see are written by someone who has never built a flow. They block the HTTP connector by default and then wonder why nobody integrates with anything. Or they put SharePoint and Outlook in different data groups and break every approval flow in the tenant.

The approach that works is starting from what makers actually need and working backwards. Look at what the top 50 flows in your tenant use. Build your Business data group around that. Put the genuinely risky stuff like custom connectors to unknown endpoints in Blocked. Review quarterly, not yearly.

And write the policy down in plain language somewhere makers can find it. Not a SharePoint page buried in the IT site. Pin it in the Teams channel where makers ask questions.

The CoE Kit is not a governance strategy

I see this a lot. A team installs the CoE Kit, enables a few flows, and calls it done. The CoE Kit is a starting point. It is inventory and some reporting. It is not a governance strategy on its own.

The manual updates every few months genuinely do break things. The premium license requirement for some of the governance features is a real cost. The handoff complexity when the person who installed it leaves is a known problem. None of this is a secret.

What I have seen work is using the CoE Kit for what it is good at, which is discovery, and building lightweight custom tooling for the parts that matter to your org. Inactivity policies. Ownership reassignment on leaver events. Environment request intake. None of this needs to be fancy. A few flows and a SharePoint list go a long way, which ties back to a point I have made before about SharePoint being the right backend for most Power Platform needs.

Governance is a product

The shift that changed how I think about this is treating governance as a product with makers as the customer. If makers avoid your governance model, it is broken. If they route around it, it is broken. If they ask for exceptions constantly, it is broken.

The safe path has to be the easy path. Otherwise adoption dies and you spend the next year explaining to leadership why the platform did not deliver. If you are still building out the foundation, understanding why Power Automate is still worth learning in 2026 is a good place to start before layering governance on top of a platform your team is not yet fluent in.

Frequently Asked Questions

What is Power Platform governance and why does it matter?

Power Platform governance is the set of policies, environments, and controls that shape how people build and share apps, flows, and agents in your organisation. When designed well, it protects the business without slowing down the people trying to do useful work. When designed poorly, it either locks everything down or lets chaos grow unchecked.

How do I set up Power Platform governance without killing adoption?

Treat governance as a product where makers are the users, not a security checklist applied on top of them. Give people a managed environment they can access quickly, document the DLP policies clearly, and make the approved path easier than any workaround. If the process to get started takes weeks, people will find another way.

Why does my Power Platform app break when it moves from Dev to Production?

This usually happens because DLP connector policies differ between environments and those differences are not documented anywhere. A connector allowed in your Dev environment may be blocked in Production, which silently breaks apps or flows at go-live. Writing down the DLP differences for each environment and testing against them before promotion prevents this.

When should I reassign Power Platform flows and apps after someone leaves the organisation?

Reassignment should happen within a defined window as soon as someone leaves, not reactively when something breaks. Flows and apps owned by former employees can keep running in production for years with no clear owner, which creates a serious operational and security risk. Power Platform PowerShell modules can automate much of this process.

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

April 24, 2026
Claude vs ChatGPT Is the Wrong Question When You Are Building Automations

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

Another Claude vs ChatGPT comparison landed in my feed this week. I came across a piece on the Zapier Blog running the usual head-to-head: reasoning, coding, writing, ethical dilemmas. Useful if you are picking a chat assistant for personal use. Almost useless if you are deciding claude vs chatgpt for automation inside a real enterprise flow.

I keep seeing people pick a model based on a consumer benchmark and then act confused when their Copilot Studio agent starts returning malformed JSON in week three. The criteria that matter when a model sits behind a connector are not the criteria that make for a good blog post.

Why Head to Head Model Comparisons Stop Being Useful the Moment You Add a Connector

Consumer comparisons test the model in isolation. One prompt in, one answer out, a human judges the output. That setup tells you nothing about what happens when the model has to call a tool, parse a response, call another tool, and feed a structured result into a downstream action.

Inside an automation, the model is not the product. The model is one component in a pipeline. The question is not which one writes better poetry. The question is which one fails in ways your orchestration layer can actually handle.

I wrote about this angle in a previous post on agentic workflows. The LLM is the reasoning layer, not the agent. Picking the reasoning layer on vibes from a consumer benchmark is how you end up with a beautifully worded confident response for a task that never completed.

The Four Things That Actually Matter When a Model Sits Inside an Automation

These are what I actually test for. None of them show up in head-to-head comparisons.

Structured output stability under load. Ask the same model for the same JSON schema a hundred times with slightly different inputs. Count how often it adds a trailing comma, drops a required field, wraps the JSON in a code fence, or decides today is the day to add a helpful explanation before the response. This is the single biggest source of silent failures I see in production.

Tool-calling predictability with multiple connectors. Give the model five tools. Watch how it picks. A model that is 95 percent accurate on tool selection with two tools can drop to 70 percent with five because the descriptions start competing. Consumer tests never measure this.

Behaviour when context gets long. Most real flows accumulate context: user input, previous tool results, system instructions, retrieved documents. I want to know how the model behaves at 40k tokens of accumulated state, not at 500. Instruction drift usually shows up here first.

Pricing behaviour under loops. An agent that retries three times on a failed tool call can quietly 10x your cost. The cheaper model on paper is not always the cheaper model in production once you account for retry patterns and token accumulation. Latency Is the Quiet Killer of Agentic Workflows covers how round-trip costs compound in ways most people never budget for until it is too late.

How I Pick Between Claude and GPT for a Specific Flow

I do not pick a model for the whole platform. I pick per use case.

For long-context reasoning where the model needs to hold a lot of state and follow detailed instructions without drifting, Claude has been the more predictable option in my testing. Fewer surprise deviations from the system prompt when the context gets messy. If you want to go deeper on why Claude works well as a reasoning layer inside enterprise pipelines, Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now gets into the architecture side of that decision.

For fast, cheap, high-volume classification or extraction where the schema is simple and the input is short, GPT models tend to win on cost-per-call and latency. If the task is “read this email and return one of five categories,” I am not paying for a heavyweight reasoning model.

For tool-calling inside a Copilot Studio agent with multiple Power Automate actions, I test both. There is no universal winner. It depends on how the tool descriptions are written, how many there are, and how ambiguous the user input gets.

The honest answer most of the time is: it does not matter as much as the people arguing about it think it does. The bigger wins come from tool design, prompt structure, and failure handling. A well-designed flow with a mid-tier model beats a sloppy flow with the flagship every time.

What to Test Before You Commit a Model to Production

Before a model goes behind a production flow, I run four checks. Not benchmarks. Checks against the actual flow.

Run the real schema a hundred times with production-like inputs. Measure malformed output rate. Anything above one percent and you need a validation and retry layer, no matter which model you picked.

Run the tool-calling logic with the real connector set, not a simplified test set. Watch for the model picking the wrong tool when two descriptions overlap. This is where I lost the most time the hard way.

Simulate a long session. Feed it accumulated context that looks like a real user journey, not a single clean turn. Watch for instruction drift.

Load test with the pricing model in mind. Know what a retry storm costs you before it happens in production, not after finance asks questions. The Power Automate documentation covers retry policies, but most people never configure them until something breaks.

The Claude vs ChatGPT question is the wrong frame. The right question is: which model handles the specific shape of failure my flow is most exposed to. Answer that and the comparison stops mattering. That is the part I keep trying to explain when people ask me, and it still gets pushed aside for whichever model topped a benchmark last week.

Frequently Asked Questions

Which is better, Claude vs ChatGPT for automation workflows?

Choosing between Claude and ChatGPT for automation is less about which model performs better in general benchmarks and more about how each behaves inside a pipeline. The criteria that matter are structured output reliability, tool-calling accuracy, and how well the model holds instructions as context grows. Testing both models against your specific workflow conditions will tell you far more than any consumer comparison.

Why does my AI agent start producing errors after working fine at first?

This often happens because the model experiences instruction drift as context accumulates over time. Long flows gather user inputs, tool results, and retrieved documents, and some models struggle to maintain consistent behaviour at high token counts. Testing your model under realistic context lengths before going to production can help catch this early.

How do I choose an AI model for a Power Automate or Copilot Studio flow?

Focus on how the model handles structured outputs, selects the right tools when multiple connectors are available, and behaves when context is long rather than short. Consumer benchmarks test models in isolation, but real automation pipelines require consistent, predictable behaviour across repeated calls with varying inputs. Running your own tests against your actual schema and tools will give you more reliable answers.

What causes silent failures in AI automation workflows?

One of the most common causes is inconsistent structured output, where a model occasionally adds unexpected formatting, drops required fields, or wraps a response in a code block instead of returning clean JSON. These errors can pass through without triggering obvious alerts while still breaking downstream actions. Testing output stability across many varied inputs is one of the most important steps before deploying a model-powered flow.

Source: Claude vs. ChatGPT: Which is best? [2026] (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

April 23, 2026
Scheduled Codex Runs Are the Missing Piece Between Chatbots and Real Automation

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

I came across a post from OpenAI about Codex Automations the other day, and it reminded me of a pattern I keep seeing people miss. Everyone is obsessed with chatbots. Meanwhile the real unlock is boring and familiar to anyone from the Power Platform world. It is the schedule. Codex automations scheduled ai runs are the bridge between cool demo and something that actually replaces a recurring job.

Most AI tooling still assumes a human is in the loop pressing a button. That assumption is the ceiling. Break it and the shape of what you build changes.

Why a scheduled AI run is different from a scheduled flow

A scheduled Power Automate flow is deterministic. Same trigger, same actions, same branches. You can draw it on a whiteboard before it runs and the drawing will be correct. I have written about this before. If you can fully diagram the execution path before it runs, it is not an agentic workflow. It is a flow.

A scheduled Codex run is the opposite. The trigger fires on a schedule, but the work happening inside is a reasoning step. The model decides what to read, what to compare, what to summarise, what to flag. You are not wiring actions. You are wiring a recurring thought.

That sounds fluffy. It is not. It changes what workloads are worth automating at all.

The workload shape where Codex automations scheduled ai runs actually fit

Here is the shape I look for. The task runs on a cadence. The inputs vary in structure every time. The output is a judgement, a summary, or a prioritised list. No two runs look the same but the goal is identical.

Think about the recurring jobs that never got automated because the logic was too fuzzy. The weekly review of open pull requests that actually need attention. The Monday morning scan of overnight alerts to decide which three matter. The monthly pass over a folder of documents to flag what changed in a way a human cares about.

In Power Automate you would try and fail. You would end up with a flow that emails everything to a human who then does the real work. The flow is a courier, not an automation.

A scheduled AI run is different. The reasoning is the automation. The delivery is the courier part.

What I would build with this tomorrow if I had it internally

A daily 7am run that reads the previous day’s pipeline run logs across a set of flows, clusters the failures by likely root cause, and posts a short Teams message with the three things worth looking at. Not the raw error list. The interpretation.

A weekly pass over a shared folder that produces a diff in plain English. What changed, who changed it, whether it looks like policy drift or normal edits.

A monthly review of connector usage that flags flows quietly heading toward platform-level throttling before they break in production.

None of these are chatbots. None of them need a human to press a button. All of them are reasoning tasks that happen on a clock. That is the fit.

Where Power Automate still wins and where it does not

Power Automate wins the moment the work is deterministic and the integrations are inside the Microsoft estate. Approvals. SharePoint updates. Dataverse writes. Email parsing with known templates. Anything with governance, DLP, and environment strategy attached. A scheduled AI run from outside the tenant does not solve those things. Power Automate does.

It loses the moment the work is a judgement call on messy inputs that change shape every run. That is where a scheduled Codex or Claude run wins by a wide margin. Trying to force that into a flow gives you the courier pattern. Useful, but not automation. Latency Is the Quiet Killer of Agentic Workflows and the same principle applies here — the more reasoning steps you stack inside a scheduled run, the more carefully you need to budget what actually happens inside that window.

The interesting move is using both. The scheduled AI run produces the judgement. Power Automate delivers it, logs it, routes approvals, writes to the system of record. The reasoning layer decides. The execution layer acts. I have said this more than once and I will keep saying it because most teams still collapse the two. If you are thinking about where Workspace Agents compare to Power Automate in this picture, that framing is worth reading before you decide which layer owns the work.

If you already think in triggers and schedules from the Power Platform world, you are better positioned than most to use this well. You know what a cadence looks like. You know what idempotent means. You know why retry logic matters. Now the thing running inside the schedule can think. That is the shift.

Stop waiting for someone to press a button.

Frequently Asked Questions

What are codex automations scheduled AI runs and how do they work?

Codex automations scheduled AI runs are recurring AI tasks that fire on a set schedule, where the model performs reasoning rather than following a fixed, pre-wired set of actions. Unlike a traditional scheduled flow, the AI decides what to read, compare, summarise, or flag each time it runs. This makes them suited to tasks where the inputs vary but the goal stays the same.

How do I know when to use a scheduled AI run instead of a Power Automate flow?

If you can map out every branch and action of a task before it runs, a standard flow is the right tool. When the output requires interpretation, prioritisation, or judgement based on inputs that change each time, a scheduled AI run is a better fit. Tasks like triaging alerts, reviewing documents for meaningful changes, or summarising error logs fall into this second category.

Why does a scheduled Power Automate flow struggle with fuzzy or variable logic?

Power Automate flows are deterministic, meaning they follow the same paths every time regardless of context. When the logic requires understanding nuance or making a judgement call, the flow typically ends up forwarding everything to a human rather than completing the work itself. The flow becomes a delivery mechanism rather than a true automation.

When should I consider replacing a recurring manual review task with an AI automation?

If a task runs on a regular cadence, involves inputs that vary in structure, and produces an output that is a summary, ranking, or decision rather than a fixed result, it is a strong candidate for AI automation. Examples include weekly pull request reviews, overnight alert triage, and monthly document audits where a human currently does the interpretation work.

Source: Automations (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

April 23, 2026
Power Platform Agents Talking to GitHub Sounds Simple Until You Hit Enterprise Environment Sprawl

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

I keep seeing the same demo on LinkedIn. Someone wires a Power Platform agent to GitHub in ten minutes, the agent answers questions about a repo, everyone claps. Then a team at a real enterprise tries to copy the pattern and stalls for three weeks. The problem is never the connector. The problem is power platform agent github integration enterprise reality, where you have twelve environments, three GitHub orgs, DLP policies that differ per environment, and a security team that wants tokens rotated quarterly.

The connector works. The environment strategy around it does not.

Why the GitHub Connector Demo Lies to You

In a demo, one person builds in their default environment, authenticates with their own GitHub account, and points the agent at a public or personal repo. Every layer of that setup is the easy path.

Personal auth hides the service account problem. Default environment hides the DLP problem. A single repo hides the org sprawl problem. Running it locally hides the fact that the Prod environment sits in a different security posture entirely.

I have watched teams ship an agent to UAT, watch it work, promote it to Prod, and then hit a wall where the connection simply cannot see the repo. No error message that is useful. Just empty knowledge and a confident agent saying it could not find the information. Same failure mode I wrote about in agent testing versus production behavior. The agent answers. The answer is empty. Nobody notices for a week.

The Environment Sprawl Problem Nobody Scopes For

Large enterprises do not have one Power Platform environment. They have Dev, multiple UAT environments per business unit, a shared services environment, regional Prod environments, a sandbox for citizen devs, and a couple of orphaned ones nobody wants to delete. Each one has its own DLP policy group at the tenant level.

GitHub is not one thing either. Most large orgs I hear about run at least two GitHub organisations. Sometimes an enterprise account with several orgs under it. One for platform code, one for product code, maybe one for security-sensitive work behind SSO with stricter SAML enforcement.

Now ask the real question. Which Power Platform environment is allowed to talk to which GitHub org, with which connector classification, using which identity? Most teams have never drawn this map. They build in Dev, it works, and they assume Prod behaves the same. It does not.

The GitHub connector can sit in the Business data group in one environment and the Blocked group in another. The agent that passed UAT will not even load the connection in Prod because the policy blocks it. You find out at go-live.

How I Would Map Power Platform Environments to GitHub Orgs and Repos

Start with the principle that environment design is the hard part, not the connector. Then draw the map before you build anything.

Dev Power Platform environment talks to a Dev GitHub org, or a dedicated sandbox org, with a scoped token and loose DLP. UAT talks to the same repos as Prod but through a read-only identity, so you are testing against real structure without write risk. Prod talks to Prod GitHub orgs through a managed service identity, with the connector in the Business data group and DLP exceptions documented.

The knowledge source in the agent has to point at a repo that the target environment’s connection can actually see. This is where most builds break. The agent was built in Dev pointing at a repo in the Dev org. In Prod, that repo does not exist, and the Prod connection has no permission on the Prod equivalent. The fix is not technical. It is an environment variable pattern where the repo reference is parameterised per environment, and solution deployment swaps the value.

The Microsoft Learn docs on environment strategy cover the platform side. They do not cover the mapping to external orgs. That part is on you.

Service Accounts Tokens and the Stuff That Actually Breaks in Prod

Personal Access Tokens are how every demo works and how no enterprise should run anything. The person who created the PAT leaves the company, the token is revoked, the agent goes dark. I have seen this happen. Twice.

GitHub Apps are the right answer for Prod. Fine-grained permissions, installable per org, rotate credentials without losing the identity. The connector supports GitHub App auth. Use it. The trade-off is setup time. You have to get the security team to approve the app installation on the target org, which takes weeks in a large enterprise. Plan for that before you commit to a go-live date.

Service account seats are the other thing that breaks quietly. The identity your Prod connection uses needs a seat on the target repo. In a GitHub Enterprise plan with seat limits, this is a budget conversation, not a technical one. I have seen agent deployments stall because nobody wanted to pay for an extra seat.

Token rotation policy is the last piece. If your security team rotates every ninety days, build the rotation into your deployment pipeline, not into a calendar reminder. Otherwise the agent fails silently on day ninety-one and the confident-but-empty response problem shows up again. And if those silent failures start compounding across chained steps, you are looking at the kind of agentic workflow latency problem that is easy to miss until it is already affecting users.

The connector is not the hard part. It never was. The teams that succeed stop treating integration as a connector problem and start treating it as an environment design problem. If you are still early in this process, getting started with Copilot Studio in 2026 means thinking through environment strategy from day one, not after your first failed Prod deployment. Draw the map first. Build second.

Frequently Asked Questions

How do I set up a Power Platform agent GitHub integration in an enterprise environment?

Start by mapping which Power Platform environments need to connect to which GitHub organisations, and what DLP policies apply to each. You cannot assume a connection that works in Dev or UAT will behave the same way in Production, since connector classifications can differ across environments. Sorting out service account credentials and token rotation policies before you build will save significant rework later.

Why does my Power Platform agent work in UAT but fail in Production when connecting to GitHub?

The most common cause is a difference in DLP policies between environments. The GitHub connector may be classified as allowed in your UAT environment but blocked or restricted in Production, which stops the connection from loading at all. The agent will often still respond but return empty results, making the failure easy to miss until users report it.

What is environment sprawl and why does it matter for Power Platform agent deployments?

Environment sprawl refers to the accumulation of multiple Power Platform environments across an organisation, each with its own DLP rules, security posture, and connector permissions. It matters for agent deployments because a GitHub connection that is permitted in one environment may be completely blocked in another, and most teams do not map these differences before they start building.

When should I use a service account instead of personal authentication for a GitHub connector in Power Platform?

Any time the agent is intended for a team or production use case, a service account is the right choice over personal authentication. Personal credentials tie the connection to an individual user, which creates access and continuity risks when that person changes roles or leaves the organisation. A shared service account also makes token rotation and permission auditing much easier to manage.

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

April 23, 2026
Workspace Agents Are ChatGPT’s Answer to Power Automate and That Comparison Matters

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

I came across the OpenAI page on Workspace Agents and my first thought was blunt. This is Power Automate with a chat interface sitting in front of it. That is not a dig. The fact that OpenAI Workspace Agents land so close to what Microsoft has been building for years is the interesting part, because it tells you where the bar is moving for every automation builder in the enterprise.

I have been building on Power Platform full time inside a large organisation for years. I am not worried about Workspace Agents replacing anything in my stack next week. I am thinking about what happens when the people I build for start using ChatGPT at home and walk into the office expecting the same feel.

What OpenAI actually shipped and why it looks familiar

Strip the marketing language and Workspace Agents are a way to let a user describe a repeatable task, connect some tools, and have the agent run it on a schedule or on demand. Triggers. Actions. Conditions. A reasoning layer that decides what to do next.

If that sounds like a Power Automate flow with a Copilot Studio agent sitting on top, that is because functionally it overlaps a lot. The difference is not in what it does. It is in how you build it.

Conversation-first automation versus flow-first automation

Power Automate starts from a diagram. You pick a trigger, you add steps, you see the branches. Even when Copilot writes the flow for you, the output is still a visual graph you can inspect, test, and version.

Workspace Agents start from a conversation. You tell the agent what you want. It figures out the steps. You refine by talking, not by dragging.

Neither approach is better. They attract different builders and produce different kinds of automations. Flow-first builders think in terms of state, error paths, and what happens when step 4 fails. Conversation-first builders think in terms of outcomes and trust the model to fill in the middle.

I have written before about what actually makes a workflow agentic, and the same rule applies here. If you can fully diagram the execution path before it runs, you built a flow with a chat skin. The interesting Workspace Agent use cases are the ones where the agent genuinely picks the path.

What this means if you already run on Power Platform

Workspace Agents are not going to displace Power Platform inside a large enterprise. Governance, DLP, environment strategy, audit, the whole compliance layer. None of that is solved by a chat interface on top of a model provider.

But the comparison matters for two reasons.

First, it shows what conversation-first building can feel like when it works. Power Automate with Copilot is moving in that direction, just slower and with more guard rails. If you want to understand where the platform is heading, watching how people actually use Workspace Agents is more useful than reading another Microsoft roadmap post.

Second, it exposes the parts of Power Platform that still feel heavy. Creating a solution, picking an environment, sorting out connection references, publishing, sharing. A business user who just had a working agent in ChatGPT in four minutes is going to ask why the internal version takes four days. Part of that friction is unavoidable — as I explored in why Power Automate is still worth learning in 2026, the platform carries real enterprise weight that consumer tools simply do not have to.

The expectation shift that is about to hit your intake queue

This is the part people I talk to at other organisations are not ready for.

The OpenAI Workspace Agents launch does not change what is technically possible inside your tenant. It changes what your users think should be easy. Someone who built an agent over the weekend to summarise emails and update a Google Sheet is going to file an intake ticket asking for the same thing against SharePoint and Outlook, and they will be confused when the answer is not “sure, by Friday.”

The honest answer is that the internal version has to handle auth, permissions, data residency, retention, and the fact that the output will be read by someone who makes a decision based on it. That is not bureaucracy. That is the cost of operating in a regulated enterprise. But nobody wants to hear it when the external version just works.

The teams that will handle this well are the ones that stop treating every request as a custom build and start shipping pre-approved agent templates with the governance already baked in. Citizen devs get conversation-first speed. The platform team keeps control of the risk surface. That is the only way the intake queue survives the next year. And it is worth remembering that who owns the decision inside these automations matters as much as how fast they run — shipping an agent template without settling that question just moves the risk downstream.

I have opinions on how to structure that, and I will write about it soon. You can follow along on my LinkedIn if you want the next piece when it lands.

Workspace Agents are not a threat. They are a preview of the conversation you are about to have with every business user who used ChatGPT over the weekend.

Frequently Asked Questions

What are OpenAI Workspace Agents?

OpenAI Workspace Agents let users describe a repeatable task, connect tools, and have an agent run it on a schedule or on demand. They use a conversation-first approach, meaning you define what you want through chat rather than building a visual workflow diagram.

How do OpenAI Workspace Agents compare to Power Automate?

Both handle triggers, actions, and conditions to automate tasks, so they overlap significantly in what they can do. The key difference is how you build them: Power Automate starts from a visual flow diagram, while Workspace Agents start from a conversation with the model.

When should I use Power Automate instead of a conversational agent?

Power Automate is better suited when you need clear error handling, version control, and a fully inspectable execution path. Conversation-first tools like Workspace Agents work well when you want to define an outcome and let the model determine the steps.

Why does the rise of OpenAI Workspace Agents matter for enterprise automation builders?

As more people use conversational AI tools like ChatGPT in their personal lives, they will expect a similar experience in workplace tools. This raises the bar for how automation platforms present themselves, even if enterprise governance and compliance requirements still favour established platforms.

Source: Workspace agents (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

April 22, 2026
Latency Is the Quiet Killer of Agentic Workflows and Almost Nobody Talks About It
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
April 22, 2026
The Real Shift Is Not Faster Work It Is Who Owns the Decision
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
April 21, 2026
SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

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

There is a pattern I keep seeing on LinkedIn and in conversations with people at other organisations. A team starts a new Power Platform project, someone labels it ‘enterprise’, and suddenly the backend discussion jumps straight to Dataverse. No one questions it. Licensing gets justified in a spreadsheet, premium seats get budgeted, and six weeks later the solution is a list of 4000 records with a status column and three lookup fields. That is the moment I want to push back. For a big chunk of internal work, SharePoint lists for power platform apps are still the right call, and treating that choice as amateur hour is costing teams real time and money.

Why SharePoint Lists Keep Getting Dismissed Unfairly

The dismissal usually comes from two places. First, the word SharePoint carries baggage from the 2013 era that has nothing to do with what Lists actually is in 2026. Second, Dataverse gets sold as ‘the proper enterprise choice’ in every Microsoft deck, so picking anything else feels like admitting you cut corners.

Neither of those is an engineering argument. They are vibes.

In practice, a modern SharePoint list gives you a REST and Graph API, column-level validation, versioning, item-level permissions if you really need them, native integration with every Power Platform connector, and a UI that business users can actually open and fix when something looks off. You get Entra ID authentication for free. DLP policies cover it. The audit log flows into the same Purview tenant everything else does. For an internal request tracker, an onboarding checklist, a small approval queue, or a reference table that three flows read from, that is the whole job.

The Workloads Where SharePoint Is Genuinely the Right Answer

I am not arguing SharePoint wins everywhere. I am arguing it wins for a specific and very common shape of work.

If the app is an internal tool, used by under a few hundred people, with a data volume that will never credibly pass 20 or 30 thousand items in any single list, and a schema that fits cleanly into flat records with a handful of choice and lookup fields, you are in SharePoint territory. Registrations, comms sign-offs, small approval workflows, asset inventories, internal request forms, training trackers, audit checklists. This is the bread and butter of Power Platform inside any large organisation.

Building on a list for that kind of workload is faster in almost every dimension. You spin up the schema in minutes. Makers on your team can read and edit the data directly in the browser without a model-driven app wrapper. Your Power Automate flows use the standard SharePoint connector, which means no premium licence for the thousand people who happen to trigger a flow indirectly. That last point alone saves real budget. I have written before about how licensing shapes architecture choices in enterprise environments, and this is one of the clearest examples.

The Real Limits You Need to Design Around

SharePoint lists are not magic. They have hard edges, and you need to know them before you commit.

The 5000 item view threshold is the one everyone quotes, and it is real, but it is a view and query limit, not a storage limit. A list can hold millions of items. You work around the threshold with indexed columns, filtered views, and delegable queries in Power Apps. If you are careful with your delegation, a list with 50,000 items performs fine for the usage patterns most internal apps actually have.

Throttling is the other one. The SharePoint connector has its own limits, and if you are running a flow that hammers a list in an Apply to Each loop at full concurrency, you will get throttled. Same story I covered in the throttling post. Drop concurrency, batch your reads, and stop treating the list like a transactional database.

Where SharePoint genuinely falls over is relational complexity. More than two or three lookups deep and you are building joins in Power Automate, which is painful to maintain. Row-level security beyond basic item permissions gets ugly fast. Calculated columns are limited. And if two users edit the same item in the same second, you can get conflicts the platform does not resolve gracefully. This is also where why Power Automate is still worth learning in 2026 becomes relevant — knowing how to structure flows around list limitations is a skill that pays off repeatedly.

When to Actually Move to Dataverse

Dataverse earns its licence cost when the workload has specific characteristics. Genuine relational depth with many-to-many relationships you actually traverse. Role-based security that needs to be enforced at the data layer, not the app layer. Business rules and calculated fields that are part of the data contract. Plugins, server-side logic, or integration with Dynamics. Auditing at the field level for compliance. Transactional guarantees where a failed write must roll back cleanly.

If your project has three or more of those, Dataverse is the right choice and the licensing conversation is easy to win because the alternative is building those features yourself and maintaining them forever.

If your project has none of them, and you are about to spend eight weeks justifying premium seats for 400 people so you can store a status column on 4000 records, stop. Build it on a list. Ship it next week. Spend the saved budget on something that actually needs it. And before you wire any intelligence layer into whatever you build, it is worth reading Adding Copilot to Your Power App Is Not the Same as Making It Smarter — the backend choice and the AI layer choice follow the same logic.

The backend choice is an engineering decision, not a status symbol. I write more about these kinds of trade-offs on my LinkedIn if this is the kind of call you are wrestling with right now.

Frequently Asked Questions

When should I use SharePoint lists for Power Platform apps instead of Dataverse?

SharePoint lists are a strong fit when your app is internal, used by fewer than a few hundred people, and will never exceed tens of thousands of items in a single list. Common examples include approval queues, request forms, training trackers, and asset inventories where a flat schema with a few lookup fields covers everything you need.

Why does using SharePoint as a Power Platform backend save money on licensing?

Power Automate flows that connect to SharePoint use the standard connector, which does not require a premium licence. In large organisations where thousands of users might trigger a flow indirectly, avoiding premium connector requirements can add up to significant budget savings compared to a Dataverse-backed solution.

What are the security and governance features available with SharePoint lists?

Modern SharePoint lists authenticate through Entra ID and are covered by your organisation’s DLP policies. Audit logs feed into the same Purview tenant as your other Microsoft 365 services, so governance and compliance requirements are met without additional configuration.

How do I know if Dataverse is actually necessary for my Power Platform project?

If a solution is genuinely enterprise in scale, involving complex relational data, high record volumes, or advanced role-based security requirements, Dataverse earns its place. However, if the data model is a few flat lists with simple lookups and the user base is a small internal team, reaching for Dataverse by default adds cost and complexity without a clear engineering benefit.

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

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

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

April 20, 2026

Category: Artificial Intelligence in Business

Why the Trainium Story Is Actually a Capacity Story

What Token Cost Drift Looks Like in a Real Power Automate Flow

Bedrock vs Direct Anthropic API for Enterprise Automation Workloads

How I Would Plan Claude Capacity for an Agent You Actually Depend On

Frequently Asked Questions

Why does running Claude on Amazon Trainium matter for enterprise AI deployments?

Why does my Power Automate flow keep getting slow or failing when using Claude?

How do I control Claude API costs in a high-volume Power Automate flow?

When should I start worrying about token cost drift in an AI automation?

The two failure modes of Power Platform governance

What actually works

DLP policies that do not punish makers

The CoE Kit is not a governance strategy

Governance is a product

Frequently Asked Questions

What is Power Platform governance and why does it matter?

How do I set up Power Platform governance without killing adoption?

Why does my Power Platform app break when it moves from Dev to Production?

When should I reassign Power Platform flows and apps after someone leaves the organisation?

Why Head to Head Model Comparisons Stop Being Useful the Moment You Add a Connector

The Four Things That Actually Matter When a Model Sits Inside an Automation

How I Pick Between Claude and GPT for a Specific Flow

What to Test Before You Commit a Model to Production

Frequently Asked Questions

Which is better, Claude vs ChatGPT for automation workflows?

Why does my AI agent start producing errors after working fine at first?

How do I choose an AI model for a Power Automate or Copilot Studio flow?

What causes silent failures in AI automation workflows?

Why a scheduled AI run is different from a scheduled flow

The workload shape where Codex automations scheduled ai runs actually fit

What I would build with this tomorrow if I had it internally

Where Power Automate still wins and where it does not

Frequently Asked Questions

What are codex automations scheduled AI runs and how do they work?

How do I know when to use a scheduled AI run instead of a Power Automate flow?

Why does a scheduled Power Automate flow struggle with fuzzy or variable logic?

When should I consider replacing a recurring manual review task with an AI automation?

Why the GitHub Connector Demo Lies to You

The Environment Sprawl Problem Nobody Scopes For

How I Would Map Power Platform Environments to GitHub Orgs and Repos

Service Accounts Tokens and the Stuff That Actually Breaks in Prod

Frequently Asked Questions

How do I set up a Power Platform agent GitHub integration in an enterprise environment?

Why does my Power Platform agent work in UAT but fail in Production when connecting to GitHub?

What is environment sprawl and why does it matter for Power Platform agent deployments?

When should I use a service account instead of personal authentication for a GitHub connector in Power Platform?

What OpenAI actually shipped and why it looks familiar

Conversation-first automation versus flow-first automation

What this means if you already run on Power Platform

The expectation shift that is about to hit your intake queue

Frequently Asked Questions

What are OpenAI Workspace Agents?

How do OpenAI Workspace Agents compare to Power Automate?

When should I use Power Automate instead of a conversational agent?

Why does the rise of OpenAI Workspace Agents matter for enterprise automation builders?

Why Agent Loops Feel Slow Even When Each Call Is Fast

What OpenAI Just Shipped and Why It Matters Beyond Codex

What This Looks Like Inside Copilot Studio and Power Automate

How I Would Budget Latency Before I Build the Agent

Frequently Asked Questions

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

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

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

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

Speed Was Never The Interesting Part Of Automation

The Decision Boundary Is What Actually Moved

What This Changes About How I Build Flows And Agents

Stop Measuring Hours Saved Start Measuring Decisions Delegated

Frequently Asked Questions

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

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

Why does automating a bad process lead to worse outcomes?

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

Why SharePoint Lists Keep Getting Dismissed Unfairly

The Workloads Where SharePoint Is Genuinely the Right Answer

The Real Limits You Need to Design Around

When to Actually Move to Dataverse

Frequently Asked Questions

When should I use SharePoint lists for Power Platform apps instead of Dataverse?