Halilcan Soran

Category: Artificial Intelligence in Business

  • Anthropic Just Launched Claude for Creative Work and It Is a Real Positioning Move

    Anthropic Just Launched Claude for Creative Work and It Is a Real Positioning Move

    Claude for Creative Work announcement from Anthropic targeting writers and designers

    Anthropic shipped Claude for Creative Work this week. It is a dedicated offering aimed at writers, designers, and other creative professionals. I spend most of my day in the automation side of AI, but I want to talk about this one because the positioning is more interesting than the product itself.

    This is the first time I have seen a major lab carve out creative work as a first-class lane, separate from coding and enterprise automation. That is a signal worth paying attention to.

    What Claude for Creative Work actually does

    The release packages Claude around the workflows that creative professionals actually run. Long-form drafting, editorial revision, voice and style consistency across a body of work, brainstorming with a model that pushes back instead of agreeing with everything. There are tighter integrations for the tools writers and designers already live in, and the framing leans heavily on Claude’s writing quality rather than benchmark scores.

    It is not a new model. It is a new product wrapper around Claude with prompts, defaults, and surfaces tuned for creative output. Think of it as Anthropic saying: we know writers were already using us, here is the version built for them.

    The technical novelty is limited. The positioning novelty is not.

    Why this segmentation matters

    For the last two years, model vendors have sold one product to everyone. Same Claude for the lawyer, the developer, the marketing copywriter, the Power Platform builder. Differentiation happened at the system prompt layer, which meant every team had to figure out their own configuration from scratch.

    Anthropic is now segmenting by job-to-be-done. Claude for coding. Claude for enterprise. Claude for creative work. This is closer to how Adobe, Microsoft, and Salesforce package software, and it is a meaningful shift in how AI gets sold and bought.

    Two things follow from this.

    First, procurement gets easier for non-technical buyers. A marketing director does not want to evaluate a foundation model. They want to know if the tool fits their team’s workflow. A clearly named product solves that.

    Second, the system prompt and tooling work that used to be invisible becomes the actual product. I wrote about this when I covered Claude on Trainium: prompt engineering is production code, and the cost of treating it casually compounds. Anthropic is now productising that layer for one specific audience. I expect the same move for legal, research, and analytics in the next year.

    The interesting question for anyone in automation is whether the enterprise lane gets the same treatment. A Claude for Enterprise Automation with first-class tool calling defaults, audit logging, and connection-scoped caching would do more for the agentic workflow problem than another model bump. If you are thinking about how Claude already fits into that orchestration layer, Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now is worth reading alongside this one.

    What I would do with it this week

    I am not a creative professional. But drafting is a real part of my week, and I want to test this against my current setup.

    I would use Claude for Creative Work to draft long-form posts and technical explainers, then compare the output against the same prompts run through the standard Claude interface. The thing I want to know is whether the tuned defaults actually change the output meaningfully, or whether a good system prompt gets you 90 percent of the way there. My bet is on the latter, but I want to be wrong.

    I would also try it on editorial revision passes. Take a 1500-word draft I already wrote, run it through with instructions to tighten and remove filler, and see how it handles voice preservation. This is where Claude has historically been strong, and a product surface tuned for it should make the loop faster.

    One thing I will not do is force this into a Power Platform flow. Power Automate already has decent options for content generation through the existing Claude and OpenAI connectors. A creative-tuned product surface does not change the connector story. If you are weighing which model to point at which workload inside those flows, Claude vs ChatGPT Is the Wrong Question When You Are Building Automations covers exactly that tradeoff.

    The real takeaway is not the product. It is the precedent. Vendors are starting to segment foundation models by job-to-be-done, and that changes how I will think about which model lane to point at which workload going forward. More on that as the other lanes ship. I have been tracking this shift closely because it changes the buying conversation as much as the building one.

    Watching to see if Anthropic ships a creative-equivalent for enterprise automation next.

    Source: Claude for Creative Work \ Anthropic (Anthropic).

  • Power Pages Agentic Code Now Supports Server-Side Skills

    Power Pages Agentic Code Now Supports Server-Side Skills

    Power Pages agentic code server-side skills generating Liquid and Web API logic

    Microsoft just shipped three new skills for the Power Pages agentic code plugin that finally let GitHub Copilot and Claude Code CLI generate server-side logic, not just front-end markup. The announcement landed on the Power Platform blog and this is the gap-closer I have been waiting for. Power pages agentic code server-side generation is the part that was missing.

    If you have built anything non-trivial on Power Pages you know the pattern. The studio handles the front-end fine. The moment you need a Web API call, a table permission rule, or a Liquid template that actually does work, you are out of the visual layer and into code that the AI tools could not see properly.

    What it actually does

    The plugin now ships three new skills focused on the server-side surface of a Power Pages site. From the post and what I have read so far, these cover generating and wiring up Liquid templates with the right context, scaffolding Web API calls against your actual Dataverse tables, and producing the configuration around table permissions and site settings that normally requires you to know exactly which knob to turn.

    The important detail is grounding. The plugin pulls from your real site context: the tables you have, the columns on them, the page structure, the site settings already in place. So when GitHub Copilot or Claude Code CLI generate Liquid or a Web API snippet, it is generated against your actual environment, not a hypothetical portal.

    I wrote about this grounding problem before in an earlier post on Power Pages and AI. Generic LLM output for Liquid looks correct and breaks immediately on deploy because the model has no idea what your tables are called or what permissions are wired up. Environmental grounding is the entire game here.

    Why server-side AI generation is different leverage

    Front-end scaffolding from AI is useful but cheap. Anyone can prompt a model to spit out HTML and CSS for a form. The hard part of Power Pages was never the markup. It was the layer underneath: Liquid templates, Web API permissions, plugin logic, the settings that decide whether a record is visible to an authenticated contact or not.

    That layer is where sites break. That layer is where you used to bolt on a Power Automate flow because it felt easier than figuring out the right server-side pattern. And bolting on a flow for what should be a server-side query is exactly the kind of decision that creates a silo three months later when nobody remembers why the form posts to a flow instead of using the Web API directly. Understanding Power Automate error handling patterns helps when those flows do need to exist, but the goal should be keeping server-side work on the server side.

    Generating server-side logic with proper grounding cuts that path off. You stay inside the site. You use the layer that was already designed for it. The trade-off is real though: you now have AI-generated Liquid and permissions in a place where mistakes are harder to spot than a broken button. Server-side bugs do not show up as the dreaded broken image icon. They show up as a record being visible to the wrong user, which is a much worse failure mode.

    This is why I keep saying tool design for AI agents is an API design problem. The quality of the environmental signals fed to the model matters more than the model itself. Microsoft Learn for Power Pages is the reference I keep open when I am sanity-checking what these skills produce.

    What I would do with it this week

    I would pick a small internal-style site with two or three Dataverse tables, authenticated users, and one workflow that currently lives in a Power Automate flow it should not live in. Something where a list view filters by the logged-in contact, and a form writes back to a related table.

    Then I would have Claude Code CLI do three things. First, generate the Liquid for the filtered list using the new skill, against the real tables. Second, generate the Web API call for the form submission with the right permissions, instead of the Power Automate detour. Third, write a small piece of logic that should obviously fail without context, like referencing a column that does not exist, just to see how the grounding holds up.

    The point is not to ship anything. The point is to find where it breaks. In my experience, the only honest way to evaluate one of these releases is to push it until it produces something wrong, then look at why. If you are thinking about where this fits in a broader agentic architecture, most agentic workflows are just fancy if/then logic until the grounding is solid enough to trust the generated output in production.

    If the grounding is as good as the announcement suggests, this changes how I would start any new Power Pages build going forward.

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

  • Microsoft Shipped Multi-Agent Orchestration in Copilot Studio and the Patterns Matter More Than the Feature

    Microsoft Shipped Multi-Agent Orchestration in Copilot Studio and the Patterns Matter More Than the Feature

    Multi-agent orchestration patterns in Copilot Studio diagram

    Microsoft shipped general availability of multi-agent orchestration in Copilot Studio this month, letting one agent call another agent as a skill, including agents built in Azure AI Foundry and external M365 Copilot agents. The announcement landed on the Copilot Studio docs and the blog feed last week. If you build agents inside Microsoft 365, this changes how you should think about agent design starting now.

    I have been testing it for a few days. The feature itself is straightforward. The interesting part is which multi-agent orchestration pattern you pick, because most teams will default to the wrong one and rebuild six months from now.

    What it actually does

    You can now register another agent as a connected agent inside Copilot Studio. The parent agent sees it as a tool. When the LLM decides the user request fits the connected agent’s described purpose, it hands off the conversation, gets a structured response back, and continues reasoning.

    Three things are worth knowing. The handoff is generative, meaning routing depends on the description you write for each connected agent, not on trigger phrases. The child agent runs with its own instructions, its own tools, and its own knowledge sources. And the parent agent receives the child’s output as context it can reason over, not as a final answer it must return verbatim.

    You can chain this. Parent calls child A, child A calls child B. You can also fan out, where the parent calls multiple children based on the request shape.

    Why it matters

    Single-agent designs hit a wall fast. I wrote about this in Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat. When one agent owns too many topics, routing fails at the edges, the system prompt balloons past 4000 tokens, and every change risks breaking three unrelated flows.

    Multi-agent orchestration lets you split by domain. One agent for HR queries, one for IT, one for finance, each with its own tight instructions and tool list. The parent becomes a router with personality. That sounds clean, and it can be, but only if you pick the right pattern.

    From what I have seen building and from what I hear from people at other organisations, three patterns keep showing up:

    Supervisor pattern. One parent agent owns the conversation, delegates to specialists, aggregates results. Best when the user does not need to know which agent is answering. Trade-off: the parent’s instructions become the bottleneck. If the parent picks the wrong child confidently, you get the same misrouting failure mode I described in my post on Copilot Studio agents passing tests and still failing in production, just one layer deeper and harder to debug.

    Sequential pipeline. Agent A produces output, agent B consumes it, agent C finalises. Best for structured workflows like draft, review, publish. Trade-off: latency stacks. Each hop adds seconds, and latency is the quiet killer of agentic workflows — budgeting round-trip time before you build matters more than most teams expect.

    Peer network. Agents call each other based on need, no fixed parent. Powerful, almost always premature. I have not seen a single internal use case where this beats a supervisor design once you account for debugging cost.

    The real win is not the multi-agent capability itself. It is the reduction in system prompt size per agent. When each agent has 400 tokens of focused instructions instead of 4000 tokens trying to cover everything, behavior gets predictable. Output testing gets meaningful. Drift gets easier to catch.

    What I would do with it this week

    Pick one existing Copilot Studio agent that has grown too many topics. Look at the system prompt. If it is over 2000 tokens or covers more than two distinct domains, it is a candidate.

    Split it. Create one child agent per domain. Move the relevant tools, knowledge sources, and instructions into the child. Write a clear description for each child, because that description is what the parent’s LLM uses to route. Vague descriptions kill routing accuracy faster than anything else. If you need to wire external capabilities into those child agents, building a custom connector for Copilot Studio is the practical path for connecting APIs that do not already have a prebuilt connector.

    Then test the edges. Phrasings that sit between two children. Requests that should hit two children sequentially. Requests that should fail cleanly when no child fits. The supervisor pattern looks great on the happy path. The behavior at the edges is what tells you whether the split was worth it.

    Multi-agent orchestration is not a silver bullet, it is a structural tool. Used right, it makes agents maintainable. Used wrong, it builds another silo with extra latency. The patterns matter more than the feature.

  • How to Build a Custom Connector for Copilot Studio Step by Step

    How to Build a Custom Connector for Copilot Studio Step by Step

    Building a custom connector for Copilot Studio with OpenAPI definition and authentication settings

    The built-in connectors cover a lot, but the moment you need to talk to an internal REST API from a Copilot Studio agent, you need a custom connector. This walkthrough builds a working copilot studio custom connector end to end, from the OpenAPI definition to the agent calling it as a tool with structured output the LLM can actually reason about.

    The result: an agent that calls an internal API, gets back a typed JSON response, and uses it in the conversation without guessing.

    Step 1: Get your API contract straight before you open the portal

    Do not start in Power Apps. Start with the API spec. You need an OpenAPI 2.0 (Swagger) file or a clear list of endpoints, methods, query parameters, request bodies, and response schemas.

    If your API returns 200 OK with an empty body on success, fix that first. An agent needs structured output to evaluate what happened. I learned this the hard way building agentic flows: returning {"status":"done"} is not enough. Return the actual record, the actual ID, the actual changed fields.

    Make sure every response has a defined schema. type: object with named properties. No loose additionalProperties: true dumps. The agent reads the schema to decide how to use the result.

    Step 2: Create the custom connector in the Power Platform maker portal

    Go to make.powerautomate.com, pick the right environment (this matters, custom connectors are environment-scoped), then Data, Custom connectors, New custom connector, Import an OpenAPI file.

    Upload your Swagger file. Fill in:

    • Host: api.yourdomain.com (no https prefix)
    • Base URL: /v1 or whatever your API uses
    • Scheme: HTTPS only. Do not ship HTTP.

    If you do not have a Swagger file, use the blank template and define operations manually. It is slower but gives you full control over operation IDs and summaries, which the agent uses to pick the right tool.

    Step 3: Configure authentication properly

    For internal enterprise APIs, OAuth 2.0 with Microsoft Entra ID is the only option I would ship. API key auth works for prototypes and falls apart the moment you need per-user identity in the agent. The same principle applies when thinking about Power Platform governance that does not kill adoption — authentication decisions made at the connector level affect every maker and every environment downstream.

    In the Security tab, pick OAuth 2.0, Identity Provider Azure Active Directory, and fill in:

    • Client ID: from your app registration
    • Client secret: from the same registration
    • Resource URL: the App ID URI of the API, for example api://your-api-app-id
    • Scope: the scope you exposed on the API app registration, e.g. access_as_user

    Save, then copy the Redirect URL Power Platform generates and add it to your Entra app registration’s redirect URIs. Skip this and you will get AADSTS50011 on every connection attempt.

    Step 4: Define operations with names the LLM can understand

    This is where most connectors fail as agent tools. The operation summary and description are not metadata. They are the prompt the LLM uses to pick the tool.

    Bad: GetData. Good: Get order details by order ID.

    For each operation set:

    • Summary: what the operation does, in plain English
    • Description: when to use it, what it returns
    • Operation ID: camelCase, descriptive, like getOrderById
    • Parameter descriptions: every parameter, including required vs optional

    Test each operation in the Test tab before moving on. If it does not return clean JSON here, it will not work in the agent.

    Step 5: Add the connector to a Copilot Studio agent as a tool

    Open your agent in Copilot Studio. Go to Tools, Add a tool, then pick Connector and find your custom connector. Microsoft’s docs on connector tools in Copilot Studio cover the UI changes if anything looks different in your tenant. If you are still getting oriented with the platform itself, If You Are Starting Copilot Studio in 2026 Skip the Chatbot Tutorials is worth reading before you wire up your first tool.

    For each operation you want to expose:

    • Review the auto-generated tool description. Rewrite it if it is vague.
    • Mark inputs as Dynamically fill with AI for parameters the LLM should infer from conversation, or Custom value for static config.
    • Set the connection. For testing, use your own. For production, configure end-user authentication so each user authenticates with their own identity.

    Step 6: Test it end to end with realistic input

    In the Test pane, do not type the obvious phrasing. Type how a real user would ask. Watch the activity map. You want to see the tool getting picked, the parameters extracted correctly, the response coming back as structured JSON, and the agent using specific values from that JSON in its reply.

    If the agent paraphrases instead of citing values, your response schema is too loose or the tool description is misleading. Tighten both.

    The final state and one common pitfall

    You now have a custom connector calling an authenticated internal API, registered as a tool the agent can invoke based on conversation context, returning structured data the LLM uses in its response.

    The pitfall to watch for: connection caching across environments. A connector that works in your dev environment will not auto-promote. You need to export the solution, import it into the next environment, and recreate the connection reference there. Skip that and your ALM pipeline will fail in ways that look like auth bugs but are really environment scoping. If your setup involves agents talking to external systems across multiple environments, the same scoping problems come up in Power Platform Agents Talking to GitHub Sounds Simple Until You Hit Enterprise Environment Sprawl.

    Frequently Asked Questions

    How do I create a custom connector in Copilot Studio?

    To build a Copilot Studio custom connector, start by preparing an OpenAPI 2.0 (Swagger) file that defines your API endpoints, parameters, and response schemas. Then go to make.powerautomate.com, navigate to Data, Custom Connectors, and import your Swagger file. From there you configure authentication, define your operations, and connect the connector to your Copilot Studio agent as a tool.

    What is the best authentication method for a custom connector in Power Platform?

    OAuth 2.0 with Microsoft Entra ID is the recommended approach for enterprise APIs, as API key authentication does not support per-user identity. Authentication choices made at the connector level affect every maker and environment that uses it downstream, so it is worth getting right from the start.

    Why does my Copilot Studio agent not understand the API response correctly?

    If your API returns a vague or empty response body, the agent has nothing structured to reason about. Every response should include a defined schema with named properties so the agent can interpret the result and decide how to use it in the conversation.

    When should I build a custom connector instead of using a built-in one?

    You need a custom connector when your Copilot Studio agent needs to call an internal or proprietary REST API that is not covered by the existing built-in connectors. If your use case involves company-specific data or internal services, a custom connector is the right path.

  • Power Automate Error Handling Patterns That Actually Work

    Power Automate Error Handling Patterns That Actually Work

    Power Automate error handling patterns with scopes and run after configuration

    Most Power Automate error handling I see in the wild is one Try scope, one Catch scope, and a Teams message that says Flow failed. That is not error handling. That is a notification with extra steps.

    Real Power Automate error handling patterns answer three questions. What failed. Why it failed. What happens to the work that was already in flight when it failed. If your flow does not answer all three, you are going to find out about problems from an angry colleague, not from your monitoring.

    I have rebuilt enough flows after silent failures to have strong opinions on this. Here is what I actually use.

    The Try Catch Finally pattern is the floor, not the ceiling

    Three scopes. Try runs your logic. Catch is configured with Run After set to has failed, is skipped, and has timed out. Finally runs after both, regardless of outcome. This is documented well in the Microsoft Learn Power Automate docs and most builders get this far.

    The problem is what people put inside Catch. Usually a single Post Message action with @{workflow()?['run']?['name']} and a generic failure string. That tells you the flow failed. You already knew that. It does not tell you which action failed inside the Try, what the actual error message was, or what input caused it.

    The fix is using result('Try') inside Catch and filtering for items where status is not Succeeded. That gives you the specific action name, the status code, and the error body. Now your alert is useful.

    Differentiate transient from terminal errors

    This is the pattern most flows skip and it is the one that matters most in production. A 429 from a connector is not the same problem as a 400 from bad input. One needs a retry with backoff. The other needs a human.

    Inside Catch, parse the error and branch. Status codes 408, 429, 500, 502, 503, 504 are transient. Retry them, ideally with a Do Until that has a delay and a max iteration count. Status codes 400, 401, 403, 404 are terminal. Do not retry. Log them and move on or escalate.

    Power Automate’s built-in retry policy on individual actions covers some of this, but it does not let you do anything intelligent with the failure. It just retries with exponential backoff and then gives up. For anything that touches an external system with rate limits, I wrote about how this connects to throttling limits and why default retry behaviour can mask problems until volume increases.

    Compensating actions for partial failures

    This is the one almost nobody does. If your flow creates a SharePoint item, then sends an email, then updates a Dataverse record, and step three fails, what happens to steps one and two? Nothing, by default. You have a SharePoint item that should not exist and an email that should not have been sent.

    The pattern is simple. Inside Catch, run compensating actions for whatever Try already completed. Delete the SharePoint item. Send a correction email. Mark the Dataverse record as Failed rather than leaving it half-updated. You do this by checking result('Try') for which actions actually succeeded before the failure, then reversing only those. If you are using SharePoint lists as your backend, as I covered in SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps, the compensating delete is straightforward because the list item ID is always available in scope.

    It is more code. It is also the difference between a flow that fails cleanly and a flow that leaves your data in a state nobody can reason about three weeks later.

    Centralise error logging

    Stop writing custom logging logic in every flow. Build one child flow that takes the run ID, the flow name, the failed action, the error body, and the input payload, and writes it to a single Dataverse table or SharePoint list. Every flow calls that child flow from its Catch scope.

    Now you have one place to look when things break. You can build a Power BI report on it. You can spot patterns across flows. You can see that 80 percent of your failures are coming from one connector and actually fix the root cause instead of patching individual flows.

    The notification trap

    If every failure sends a Teams message, people stop reading them within two weeks. I have seen this play out on multiple internal builds. Tier your alerts. Transient errors that self-recover do not need a notification. Terminal errors that need human input do. Compensating actions that ran successfully need a log entry, not a ping.

    The goal is that when a notification arrives, the person receiving it actually opens it. Anything else is noise. This connects to a broader problem I have written about in Power Platform Governance That Does Not Kill Adoption, where poorly designed alerting policies erode trust in automation the same way overly restrictive DLP policies erode maker trust in the platform.

    The pattern that ties it together

    Try Catch Finally for structure. Result filtering for specificity. Transient versus terminal branching for intelligence. Compensating actions for data integrity. Centralised logging for visibility. Tiered notifications for sanity.

    None of this is exotic. All of it is skipped because the happy path works in testing and the edge cases only show up at volume. Build the error handling first. The flow will be slower to ship and faster to trust. And if you are still deciding whether Power Automate is worth investing this depth of effort into, Why Power Automate Is Still Worth Learning in 2026 covers exactly that question.

    Frequently Asked Questions

    What are the best power automate error handling patterns to use in production flows?

    Effective power automate error handling patterns go beyond a basic Try and Catch scope. You should capture specific action-level failures using result(‘Try’), differentiate between transient and terminal errors, and include compensating actions to undo partial work when a flow fails midway.

    How do I find out which action failed inside a Power Automate Try scope?

    Use the result(‘Try’) expression inside your Catch scope and filter for items where the status is not Succeeded. This returns the specific action name, status code, and error body, giving you meaningful diagnostic information instead of a generic failure message.

    When should I retry a failed action in Power Automate versus escalate to a human?

    Retry transient errors such as 408, 429, 500, and 503 using a Do Until loop with a delay and a maximum iteration count. Terminal errors like 400, 401, 403, and 404 indicate a problem with the request itself, so retrying will not help and the failure should be logged or escalated instead.

    Why does Power Automate’s built-in retry policy not work well for rate-limited connectors?

    The default retry policy applies exponential backoff and then stops, but it does not let you inspect or act on the failure in a meaningful way. At low volumes this can go unnoticed, but as traffic increases the lack of intelligent handling can cause widespread failures that are difficult to diagnose.

  • Microsoft Discovery Is the First Real Glimpse of Domain-Specific Agent Platforms

    Microsoft Discovery Is the First Real Glimpse of Domain-Specific Agent Platforms

    Microsoft Discovery agentic RD platform sitting above Copilot Studio in the enterprise agent stack

    I came across the Azure Blog post about Microsoft Discovery expanding its preview, and it crystallised something I have been chewing on for months. Most enterprise AI conversation right now is stuck on horizontal agents. Generic copilots doing generic things across generic data. Microsoft Discovery agentic RD goes the other direction, and that direction is where the interesting architectural decisions are about to happen.

    What Microsoft Discovery Actually Is If You Skip the Marketing

    Strip the announcement language away and Discovery is a vertical agent platform shaped specifically for research and development workflows. It is not a chatbot. It is not Copilot Studio with a science skin. It is a purpose-built layer with domain primitives baked in: scientific data structures, simulation orchestration, multi-agent coordination tuned for R&D problems instead of generic enterprise tasks.

    The important word is shape. A horizontal agent platform gives you a blank canvas and a set of generic tools. A domain-shaped platform gives you a canvas where the grid lines already match the work. You give up flexibility. You gain a tenth of the build time when the shape fits.

    Why Domain-Shaped Agent Platforms Beat Generic Copilots for R&D Workflows

    I have written before about how most agentic workflows are just fancy if/then logic in a trench coat. The reason is almost always the same. Teams use a general-purpose tool to model a domain it does not understand, then spend weeks bolting domain logic on top through prompts and tool definitions.

    R&D is the perfect example. A real research workflow involves hypothesis tracking, simulation runs, candidate scoring, lineage of why a decision was made three steps ago. None of that is native to a generic Copilot Studio agent. You can build it. I have seen people try. It ends up as a fragile stack of topics, variables, and Power Automate flows pretending to be a state machine.

    A domain-shaped platform encodes those primitives directly. The agent does not need a 4000-token system prompt explaining what a candidate molecule is, because the platform already knows. That is the productivity unlock, and it is also why I think we are about to see a lot more of these.

    How This Changes the Build vs Buy Decision for Power Platform Teams

    Here is the part Power Platform people should pay attention to. The skill that matters going forward is not how well you can build in Power Automate or Copilot Studio. It is picking the right altitude for the automation in front of you.

    I keep seeing teams default to building everything in Copilot Studio because that is the tool they know. Someone wants a research assistant. Someone wants a contract review agent. Someone wants a finance close helper. All of it gets crammed into Copilot Studio topics and custom connectors, and six months later the build is brittle, slow, and three people deep in technical debt. If you are just getting started, getting started with Copilot Studio in 2026 means skipping the chatbot tutorials entirely and learning to think in terms of orchestration first.

    The decision tree is going to look more like this:

    • Is there a domain-shaped platform that already models this work? Use it. Customise on top.
    • Is the workflow generic but cross-system? Copilot Studio agent with deterministic Power Automate flows underneath.
    • Is the workflow narrow, predictable, high volume? Raw Power Automate. No agent. No reasoning layer. Just a flow.
    • Is the workflow heavy on judgment with messy unstructured inputs? Reasoning model in the orchestration layer, not the response layer. I covered this in my post on Claude as orchestration brain.

    Picking the wrong altitude is the most expensive mistake I see. Discovery is interesting precisely because it adds a new altitude that did not exist in the Microsoft stack before. R&D teams who would have been forced into Copilot Studio now have a layer that fits their work natively.

    What I Would Watch For Next in the Microsoft Agent Stack

    Discovery is the canary. R&D is just the first vertical because Microsoft has obvious customers there and the workflows are well-understood. The pattern will repeat. I would expect domain-shaped agent layers for clinical workflows, manufacturing operations, financial close, regulatory review. Each one will sit above the general-purpose Copilot stack and offer the same trade: less flexibility, much faster time to a working system.

    The thing I am watching is interoperability. Can a domain platform like Discovery call out to a Copilot Studio agent for a side task? Can a Power Automate flow trigger a Discovery workflow? If yes, the stack becomes composable and the architectural decisions get genuinely interesting. If no, we end up with another round of silos with their own latency problems and integration debt.

    For now, the practical move is to stop treating Copilot Studio as the universal hammer. In my experience, the teams who consistently ship working automations are the ones who match the tool to the shape of the work. Discovery just made that decision a little more interesting.

    Frequently Asked Questions

    What is Microsoft Discovery and how does it differ from Copilot Studio?

    Microsoft Discovery is a purpose-built agent platform designed specifically for research and development workflows, not a general-purpose copilot tool. Unlike Copilot Studio, it comes with domain-specific primitives like scientific data structures and simulation orchestration built in, so teams spend far less time engineering workarounds for R&D-specific tasks.

    How does Microsoft Discovery agentic RD improve research and development workflows?

    Because the platform already understands R&D concepts like hypothesis tracking, candidate scoring, and simulation runs, agents do not need lengthy prompts or custom-built logic to handle them. This reduces build time significantly compared to trying to model the same workflows on a generic agent platform.

    When should I choose a domain-specific agent platform over a generic one like Copilot Studio?

    A domain-specific platform makes sense when your workflows map closely to the vertical it was designed for, since the built-in primitives cut build time and reduce fragility. If your use case is too broad or does not fit the platform shape, a general-purpose tool with custom configuration will give you more flexibility.

    Why do generic agentic workflows often fail for complex enterprise use cases?

    General-purpose platforms require teams to manually encode domain logic through prompts, tool definitions, and automation flows, which produces brittle systems that are hard to maintain. When the platform has no native understanding of the domain, complexity accumulates quickly and the resulting agent is difficult to scale or debug.

    Source: Microsoft Discovery: Advancing agentic R&D at scale (Azure Blog).

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

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

    Diagram of claude on amazon trainium for enterprise automation pipelines

    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.

  • Power Platform Governance That Does Not Kill Adoption

    Power Platform Governance That Does Not Kill Adoption

    Power Platform governance that does not kill adoption in an enterprise environment

    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.

  • Claude vs ChatGPT Is the Wrong Question When You Are Building Automations

    Claude vs ChatGPT Is the Wrong Question When You Are Building Automations

    Comparing Claude vs ChatGPT for automation workflows inside Power Platform

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

  • Scheduled Codex Runs Are the Missing Piece Between Chatbots and Real Automation

    Scheduled Codex Runs Are the Missing Piece Between Chatbots and Real Automation

    Codex automations scheduled ai runs replacing recurring jobs

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