Halilcan Soran

Category: Artificial Intelligence in Business

  • Power Platform Agents Talking to GitHub Sounds Simple Until You Hit Enterprise Environment Sprawl

    Power Platform Agents Talking to GitHub Sounds Simple Until You Hit Enterprise Environment Sprawl

    Power Platform agent GitHub integration enterprise environment mapping diagram

    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.

  • Workspace Agents Are ChatGPT’s Answer to Power Automate and That Comparison Matters

    Workspace Agents Are ChatGPT’s Answer to Power Automate and That Comparison Matters

    OpenAI Workspace Agents compared to Power Automate flow diagrams

    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).

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

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

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

    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).

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

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

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

    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).

  • SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

    SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

    SharePoint lists for power platform apps backend architecture decision

    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.

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

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

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

    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.

  • Power Pages Just Got Server-Side Logic You Can Actually Generate With AI

    Power Pages Just Got Server-Side Logic You Can Actually Generate With AI

    Power Pages server side logic AI code generation with GitHub Copilot and Claude Code CLI

    Power Pages server-side logic has always been where the low-code promise quietly falls apart. You get a clean design studio, drag-and-drop layouts, reasonable out-of-the-box forms. Then someone asks for server-side validation that cannot safely run in the browser, a secure external API call where the key can never touch the client, or a multi-table transaction that needs to complete before a Dataverse record is committed. And these three new skills are for modern single-page application (SPA) Power Pages sites specifically — not the classic Liquid-templated architecture — which matters if your audience spans both worlds. And suddenly you’re either writing it from scratch by hand, spending an afternoon in documentation, or handing it off to someone on a proper dev team and waiting. I came across a post from the Microsoft Power Platform Blog about three new agentic code skills for the Power Pages plugin, and it hit on something I’ve been thinking about for a while: the ceiling for what a single automation developer can ship in Power Pages without a dedicated dev team behind them just moved.

    What Server-Side Logic in Power Pages Actually Means and Why It Was Always the Hard Part

    Power Pages is a low/no-code portal builder sitting on top of Dataverse. The studio handles most of the front-end work reasonably well. But portals have always had a split personality. There’s what you can configure visually, and then there’s the layer underneath. For modern SPA-style Power Pages sites, that means server-side JavaScript endpoints that handle validation, secrets, and external API calls; Cloud Flow connections for backend automation; and integrations with systems that can’t be wired directly from the browser. That second layer is not configuration. It is code. And it requires context about your specific environment to write correctly.

    This is why generic AI code generation has never worked well here. Asking an LLM to write you a server-side endpoint without knowing your Dataverse schema, your table structure, or your page context produces something that compiles and fails as soon as you wire it to real data. The model doesn’t know your environment. You end up doing the real work yourself anyway, just with a plausible-looking starting point that may or may not match reality.

    What These Agentic Code Skills Actually Do When You Run Them

    The specific thing that matters here is scope. These are not general-purpose code suggestions. The plugin is grounded in your actual Power Pages site. It understands your tables, your site settings, your page context — because architect agents analyze your actual code and query your Dataverse environment before generating anything. Then they propose specific changes for your review before anything is applied. That propose-then-approve loop is not a limitation; it is a selling point. You stay in control of what lands in your site. When you describe the server-side behaviour you need, the generated code is scoped to your environment, not a hypothetical portal that shares no properties with yours.

    That is the distinction most people will miss when they skim the announcement. The three new skills are /add-server-logic, which generates server-side JavaScript endpoints for validation, secrets management, and cross-entity operations; /add-cloud-flow, for connecting backend automation; and /integrate-backend, for wiring in external systems. These join six existing skills in the plugin — nine total. Each one is pulling from what the plugin already knows about your site structure. The output is contextually aware in the same way that Claude operating with good tool design returns useful results because it has real signals to work with, not because the model is smarter in isolation. I wrote about this in the context of agentic workflows generally: tool design is an API design problem, and what makes these skills interesting is that Microsoft has done that tool design work to give the model actual environmental context to reason against. If you want to go deeper on how Claude functions as that reasoning layer in enterprise contexts, Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now covers the architecture side of that in more detail.

    The Claude Code CLI path is worth calling out specifically. If you’re already working with Claude for orchestration or code tasks outside the Power Platform, having it also handle your Power Pages server-side work inside the same workflow is practically useful. You’re not switching contexts or tools.

    The Specific Scenario Where I Would Use This First

    The scenario I keep running into internally is validation logic that cannot run client-side — business rules that reference data from other tables, check against external state, or need to complete before a Dataverse write is committed. That is exactly the /add-server-logic case: a server-side JavaScript endpoint that runs the check first, keeps any secrets out of the browser, and returns a clean result to the form. Describing that condition and getting generated code that already references your actual table names and schema cuts the build time significantly. That’s the first thing I’d point this at.

    The second would be secure external API calls where credentials cannot touch the browser at all. You describe the integration — what the endpoint expects, what you need back — and /add-server-logic generates an endpoint that already references your actual environment. That is a different kind of useful than autocomplete, and it removes a class of security mistake that comes from passing keys through the client.

    Where This Still Has Limits and What You Still Need to Know Yourself

    I want to be direct about this because I’ve seen the same pattern play out with AI-assisted flow building in Power Automate: faster to working and closer to production are not the same thing. Generated server-side code that looks correct can still have permission boundary issues, silent failures on edge case inputs, or endpoint logic that works on the happy path and throws an unhandled error when a value comes back null from Dataverse. The model generates against your environment, but it does not run your QA process.

    You still need to understand how Power Pages table permissions actually interact with Web API calls. You still need to know what a plugin execution context looks like and where it can fail. If you’re purely vibe building with generated code and no mental model of what’s running underneath, you’ll ship something that passes your own demo and fails on the first real user submission. This is the same problem that comes up when adding Copilot to a Power App gets treated as a shortcut around understanding what’s actually running under the surface. The same principle I keep coming back to on my own work applies here: the AI is the generation layer, you are still the verification layer.

    That said, for an automation developer who already understands the Power Pages architecture and just needs to move faster on the server-side code parts, this is genuinely useful. The ceiling for what one person can build without a dedicated dev team behind them has moved. I’ll be testing this on the next portal build that needs real server-side work, and I’m curious how much of the scaffolding holds up in practice.

    Frequently Asked Questions

    How do I generate server-side logic for Power Pages using AI?

    You can use the three new agentic code skills available through the Power Pages plugin, which work with tools like GitHub Copilot or Claude Code CLI. Unlike generic AI tools, these skills are grounded in your actual site environment, so the generated server-side endpoints, Cloud Flow connections, and backend integrations are written against your specific Dataverse schema and site structure rather than a generic example. Note that these three skills are designed for modern SPA-style Power Pages sites, not classic Liquid-based portals.

    What is the difference between Power Pages server-side logic and front-end configuration?

    Front-end configuration in Power Pages covers layouts, forms, and visual design handled through the studio. For modern SPA-style Power Pages, server-side logic refers to the layer underneath the client: JavaScript endpoints for validation and external calls, Cloud Flow integrations for backend automation, and connections to external systems. This layer is not configuration — it is code that requires environment-specific context to write correctly. This second layer requires actual coding knowledge and environment-specific context to get right.

    Do these Power Pages agentic code skills work with classic Liquid-based sites?

    No. The three new skills — /add-server-logic, /add-cloud-flow, and /integrate-backend — are designed for modern single-page application (SPA) Power Pages sites, not classic Liquid-templated portals. If your Power Pages work is primarily in the classic architecture, these skills do not apply to your current stack.

    When should I use AI-generated plugin logic in Power Pages instead of writing it manually?

    AI-generated plugin scaffolding is most useful when you need to enforce business rules on record creation or updates and want a working starting point built around your actual Dataverse tables. It reduces the time spent in documentation and removes the dependency on a dedicated development team for straightforward but environment-specific server-side requirements.

    Source: Build your server-side logic with AI: new Power Pages Agentic Code skills (Microsoft Power Platform Blog).

  • Why Power Automate Is Still Worth Learning in 2026

    Why Power Automate Is Still Worth Learning in 2026

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

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

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

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

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

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

    What Power Automate Actually Does That Nothing Else Replaces

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

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

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

    What I Would Focus on Learning First

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

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

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

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

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

    Where This Knowledge Starts Paying Off in More Advanced Work

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

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

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

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

    Frequently Asked Questions

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

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

    What is the difference between Copilot Studio and Power Automate?

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

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

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

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

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

  • RPA Is Not the Right Tool for Every Repetitive Task

    RPA Is Not the Right Tool for Every Repetitive Task

    Robot arm reaching for a keyboard representing when RPA is the wrong solution for automation

    The pitch for RPA is always the same: if a human can do it on a screen, a bot can do it instead. That is technically true. It is also one of the most misleading framings in enterprise automation, because it skips the question that actually matters. Just because RPA can do something does not mean RPA should do it. Picking the wrong solution for repetitive task automation is how teams end up six months later maintaining a bot that breaks every time someone resizes a window.

    I have run into this repeatedly. A team identifies a manual, high-volume task, someone says “let’s automate it with RPA,” and the project moves forward before anyone asks whether the underlying system has an API, a database, or a native integration point that would make the whole thing unnecessary. The bot gets built. It works in UAT. It fails in production three weeks later because the source application pushed an update that shifted a button two pixels to the left.

    When RPA Is the Wrong Solution From the Start

    RPA exists to solve a specific problem: you need to automate interactions with a system that offers no other integration path. Legacy applications with no API. Green screen mainframes. Vendor portals that will never expose a connector. When you are genuinely stuck at the UI layer, RPA is the right call and often the only call.

    The problem is that most enterprise environments are not purely legacy. They are a mix. And teams apply RPA uniformly across that mix without checking what integration options actually exist. I have seen bots built to extract data from a SharePoint list by navigating the browser UI, click by click, when a Power Automate flow with the SharePoint connector would have done the same thing in a fraction of the time with none of the fragility. That is not an edge case. That is a recurring pattern.

    If the system you are automating has an API, use it. If it has a native connector in Power Automate, use that. If it can trigger on a database event, trigger on the event. RPA should sit at the end of that decision chain, not the beginning. Reaching for it first because the task looks manual is where the wrong solution gets chosen.

    The Fragility Cost Is Not Theoretical

    UI-based automation is inherently fragile. That fragility has a real maintenance cost that rarely gets priced into the original build decision. Every application update is a potential break. Every UI refresh, every layout change, every new mandatory field added by the vendor is an incident waiting to happen. The bot does not adapt. It fails, usually silently, and keeps “running” in a state that looks like success until someone notices the output queue has been empty for three days.

    I have written before about how Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat, and RPA compounds this problem. A Power Automate flow will at least throw an error you can catch and alert on. An RPA bot that loses its UI anchor can spin through retries, log nothing meaningful, and give every appearance of normal operation while doing nothing at all. The silent failure mode in RPA is worse than most other automation approaches because the bot looks busy.

    The maintenance burden is also not evenly distributed. It tends to land on whoever built the bot, which in most enterprises is a small team. When three bots break in the same week because the same vendor pushed an update, that team is doing triage instead of building anything new. You do not feel that cost during the build. You feel it six months later.

    Process Quality Matters Here Too

    Even when RPA is the correct tool choice, the process underneath still has to be solid. I covered this properly in Automating a Bad Process Just Makes It Fail Faster, but it is worth saying directly in the RPA context: a bot has no instinct. A human doing a repetitive UI task will notice when something looks wrong and stop. The bot will not. It will execute the wrong steps with full confidence until it either crashes or produces consistently incorrect output.

    If the manual process has exceptions, workarounds, and undocumented judgment calls baked in, those do not disappear when you automate it with RPA. They become bot failures with no one to catch them.

    The Decision Should Take Five Minutes

    Before any RPA build starts, the question has to be asked directly: does this system expose any programmatic integration point? API, connector, database access, file-based trigger, anything. Power Automate alone covers hundreds of connectors that eliminate the need for UI automation entirely. If any of those paths exist, take them. They are faster to build, easier to maintain, and more reliable under load.

    RPA earns its place when none of those paths exist. When you are genuinely locked to the UI layer and there is no other way in. That is a real scenario and it happens often enough in large enterprises that RPA is a legitimate part of the toolkit. But it is a last resort, not a default.

    The teams I talk to that are happiest with their RPA implementations are the ones that use it precisely. One system, no API, high volume, stable UI. That is the sweet spot. The ones that are drowning in maintenance are the ones that used it everywhere because it felt like the fastest path to a demo.

    Fast to demo is not the same as right to build. I learned that the hard way. You can connect with me on LinkedIn if you want to talk through where RPA actually fits in your stack.

    Frequently Asked Questions

    When is RPA the wrong solution for automating a repetitive task?

    RPA is the wrong solution when the system you want to automate already has an API, a native connector, or a database trigger available. In those cases, tools like Power Automate or direct integrations are faster to build, more reliable, and far easier to maintain than a UI-based bot.

    Why does RPA break so often in production?

    RPA bots interact with applications at the UI layer, which means any visual change to the application can cause them to fail. A button that moves, a new mandatory field, or a layout refresh pushed by a vendor update can all break a bot that worked perfectly during testing.

    When should I use RPA instead of an API or native connector?

    RPA makes sense when you are working with a system that has no API, no integration connectors, and no way to trigger automation through a database event. Legacy applications and vendor portals with no developer access are the clearest use cases where RPA is genuinely the right call.

    How do I decide whether to use RPA or a different automation tool?

    Start by checking whether the target system exposes an API, supports a native connector, or can trigger on a data event. Only if none of those options exist should RPA be considered. Treating it as a last resort rather than a first choice avoids most of the fragility and maintenance problems teams run into.

  • Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now

    Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now

    Most of the conversation around Claude in enterprise automation circles is stuck on the wrong question. People are comparing it to GPT-4o or Gemini as a text generator, debating which one writes better emails or summarises documents more accurately. That framing completely misses what makes Claude enterprise automation orchestration genuinely interesting right now.

    The practitioners I talk to who are getting real results are not using Claude as a chatbot. They are using it as the reasoning layer that decides what to do next in a multi-step, stateful workflow. That is a different problem than answering a question, and it changes everything about where Claude fits in your architecture.

    The chatbot framing is getting in the way

    When a team says they want to “add Claude” to something, the default mental model is a chat interface. User sends message, model replies. Maybe it calls a tool or two. That is not orchestration. That is a smarter input box.

    Orchestration is what happens when you need a model to receive a complex goal, break it into sequenced steps, call different tools at different points, evaluate intermediate results, and decide whether to continue, retry, or escalate. The model is not answering a question. It is managing execution across a process that has state, has branching conditions, and has consequences if it goes wrong.

    I wrote about this problem directly in the post on agentic workflows. The LLM is not the agent. The LLM is the reasoning layer. If you treat them as the same thing, you end up bolting a model onto the response step of what is really just a structured flow. That is not orchestration. That is decoration.

    What makes Claude specifically interesting for orchestration logic

    Two things stand out when I look at how Claude behaves in multi-step contexts compared to other models at similar capability levels.

    First, instruction following under load. When you give Claude a detailed system prompt with conditional logic, constraints, tool-use rules, and output format requirements, it holds those instructions across a long session more reliably than most alternatives. With other models I have tested, instruction drift starts showing up once you push past a few thousand tokens of context. Claude handles longer, more complex prompts without silently dropping constraints mid-execution. For orchestration, where the system prompt is essentially your process logic written in natural language, that matters a lot.

    Second, the extended context window is not just about volume. It is about statefulness. A workflow that processes a contract, then a set of approval records, then a policy document, then makes a decision that references all three needs a model that can hold all of that in scope simultaneously. Losing context partway through an orchestration run means the model makes decisions with incomplete information. It does not know it has incomplete information. It proceeds confidently anyway. I have seen exactly this failure mode in Copilot Studio agents, where silent context loss leads to confident-sounding responses for tasks that were never properly evaluated.

    Where I would actually slot this into a Power Platform architecture

    I would not replace the existing orchestration layer in a Power Automate flow with a Claude prompt. That is not the use case. Power Automate is still the right place for deterministic, sequential steps with connectors, triggers, and error handling you can inspect.

    Where Claude earns its place is in the decision layer that sits above or between those steps. Think of a workflow that processes incoming requests, where each request has variable structure, ambiguous intent, and routing logic that depends on context that changes week to week. A hard-coded set of conditions in Power Automate will break the moment the business logic shifts. A Claude orchestration layer that reads the request, evaluates the current context loaded from Dataverse, and decides which downstream flow to invoke handles that variability without you rewriting conditions every time.

    In practice, I would build it as a Copilot Studio agent backed by Claude through a custom connector or direct API call, where Claude handles the reasoning and routing logic and Power Automate handles execution of the discrete steps. The agent decides. The flows act. The separation matters because it keeps your execution logic testable and your reasoning logic flexible. Before wiring any of this together, it is also worth auditing what adding Copilot to an existing app actually changes versus what it just surfaces differently.

    The governance piece from the post on enterprise Power Platform applies here too. Calling an external Anthropic API endpoint means your orchestration reasoning is leaving the tenant. That is an audit trail split and a DLP conversation you need to have before you build, not after.

    The honest constraints before you redesign anything

    Claude is not a free variable. Longer context windows mean higher token costs per run, and orchestration workflows that run hundreds of times a day will surface that quickly in billing. Model latency at high context volumes is also real. If your process requires sub-second decisions, this is not your tool.

    The other constraint is testability. When your orchestration logic lives in a system prompt rather than a flow diagram, reproducing a failure is harder. The model made a bad routing decision on Tuesday afternoon. Why? You need logging at the prompt level, not just at the action level. Most teams I see building this way have not set that up, and they hit the same silent failure problem I described in the Copilot Studio testing post: everything looks fine until a real user finds the edge case.

    Claude as an orchestration brain is a genuinely different capability than what most teams are building with today. The question is not whether it is smarter than the last model. The question is whether your architecture is designed to use a reasoning layer at all, or whether you are still just looking for a better chatbot to put at the front of a process that was never designed to be orchestrated.

    Frequently Asked Questions

    What is Claude enterprise automation orchestration and how is it different from using Claude as a chatbot?

    Claude enterprise automation orchestration means using Claude as the reasoning layer that manages multi-step workflows, rather than as a simple question-and-answer interface. Instead of responding to single prompts, Claude receives a complex goal, breaks it into steps, calls tools, evaluates results, and decides how to proceed. This requires stateful, branching logic that goes well beyond what a chat interface is designed to handle.

    Why does instruction drift matter when using an LLM for workflow orchestration?

    In orchestration, your system prompt acts as the process logic for the entire workflow, so if the model quietly forgets constraints or rules mid-execution, the whole process can break or produce incorrect outcomes. Some models begin losing adherence to instructions as context grows, which is a serious problem in long-running enterprise workflows. Consistency across extended sessions is one of the key reasons practitioners favour certain models for this use case.

    When should I use an LLM as an orchestration layer instead of a traditional workflow tool?

    An LLM-based orchestration layer becomes valuable when your workflow involves conditional reasoning, ambiguous inputs, or decisions that depend on synthesising information from multiple sources rather than following a fixed rule set. If your process logic can be fully mapped in advance and never changes based on context, a traditional workflow tool is likely simpler and more reliable. The LLM adds value where judgment and adaptability are required at execution time.

    How does a large context window improve multi-step enterprise workflows?

    A large context window allows the model to hold all relevant documents, intermediate results, and prior decisions in scope at once, rather than losing earlier information as the workflow progresses. This matters in processes that require a final decision to reference multiple earlier inputs, such as reviewing a contract alongside approval records and a policy document. Losing that context mid-run can lead to decisions that are inconsistent with earlier steps in the same workflow.