What is the relationship between intelligent apps and human leadership in the workplace?

Intelligent apps only deliver real value when human leadership changes how decisions are made, not just how fast tasks are completed. Without redesigning decision rights and workflows, AI tools tend to accelerate broken processes rather than fix them.

Why does automating an existing process sometimes make things worse?

Automation increases the speed and volume of outputs, but if the approval or review process stays the same, the bottleneck simply gets worse. Teams end up rubber-stamping decisions to keep pace, which lowers quality while creating the illusion of better throughput.

How do I know if my organisation is ready for an AI automation rollout?

A good starting point is asking whether decision rights have been clearly assigned and whether leaders are willing to redesign how approvals and reviews work. If those structures are unchanged, adding AI tools is likely to surface existing problems faster rather than solve them.

When should I redesign workflows before deploying intelligent apps?

Workflow redesign should happen before deployment, not after. If the human steps in a process have not been updated to match the speed and volume AI generates, the technology will outpace the people it is meant to support.

When should I use a single agent vs multi-agent system?

Stick with a single agent until you run into one of three problems: too many tools causing the model to pick the wrong one, conflicting instructions that cannot coexist in one system prompt, or parallel workstreams that need to run at the same time. If none of those apply, a single agent is the right choice.

How do I know if my agent has too many tools?

A good rule of thumb is to keep your tool count under eight to ten connectors. Beyond that, tool descriptions start competing with each other and the model's ability to select the right one drops noticeably, even if prompt tweaks do not seem to help.

Why does a single agent struggle with conflicting instructions?

When a system prompt asks the model to take on two opposing behaviours, such as acting as a strict policy checker and a friendly explainer, those personas create tension within a single instruction set. The model tends to compromise in ways that produce unreliable outputs rather than handling each mode correctly.

What are the main reasons to build a multi-agent system?

Multi-agent systems are worth the added complexity when you need genuinely parallel workstreams, have irreconcilable prompt conflicts, or are dealing with tool overload that cannot be resolved through better descriptions. Outside of those scenarios, the extra coordination overhead rarely pays off.

Category: Artificial Intelligence in Business

OpenAI and Dell Are Bringing Codex On-Prem and That Is a Bigger Signal Than the Headline

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

OpenAI and Dell announced a partnership to bring Codex into hybrid and on-premise enterprise environments. The headline reads like another infrastructure deal. It is not. The OpenAI Dell Codex on-premise story is an admission that the real ceiling on AI coding agents in regulated enterprises was never the model. It was data gravity and where the agent is allowed to execute.

I have been waiting for one of the frontier labs to say this out loud.

What it actually does

The partnership packages Codex to run on Dell infrastructure inside an enterprise boundary. That means the coding agent can sit next to the source code repositories, the build systems, and the production data it needs to reason about, without that material crossing into a public cloud endpoint.

Practically, you get Codex behavior with private deployment posture. The agent can read your repo, propose changes, run tests, and interact with internal systems while the model inference, the context window, and the working memory stay on infrastructure your security team already owns and audits.

This is not a stripped-down Codex. It is the same agent capability, moved to a place where regulated industries can actually use it. Healthcare, defense, banking, public sector. The places where a senior engineer cannot paste a function into a public chat window without filing an incident report.

Why the OpenAI Dell Codex on-premise move matters

Every regulated enterprise I hear from has the same problem. They are not blocked on whether Claude or GPT or Gemini is the best coder this week. They are blocked on a simpler question. Can the agent see the code at all.

If the answer is no, model quality is irrelevant. You end up with developers using public AI tools on personal laptops for snippets, manually retyping the output into the secured environment, and pretending this is a workflow. That is the actual state of AI coding adoption in a lot of large orgs right now. I am not exaggerating.

Moving Codex on-prem changes the question from can we use this to how do we govern this. Those are different problems with different owners. The first one stalls for two years in legal review. The second one gets a project plan.

There is a second signal here that matters more than the deal itself. OpenAI is conceding that the pure SaaS-only posture does not work for the highest-value enterprise segments. Anthropic has been hinting at the same thing with their enterprise services arm, and Microsoft has been quietly threading this through Azure for a while. The frontier labs are realizing that data gravity beats model gravity in the enterprise. The agent has to come to the data, not the other way around.

The trade-off is real. On-prem deployments mean slower model updates, more operational burden on your platform team, and capacity you have to plan for instead of renting elastically. You give up the magic of always on latest. You get back the ability to actually use the thing.

What I would do with it this week

Even if you cannot deploy this tomorrow, you can get ready. The teams that move first will be the ones who did the boring preparation work before the procurement conversation started.

Map where your code and pipeline data actually live. Not the architecture diagram version. The real version. Which repos are in GitHub Enterprise Cloud versus self-hosted. Which CI runners can reach which networks. Which production data the agent would need to read to be useful for debugging versus generation. If you cannot answer this in a meeting, the on-prem agent conversation is going to stall on day one.

Write down the three coding tasks you would actually want an agent to do inside the secured environment. Not refactor our monolith. Specific things. Generate Power Platform solution components from a spec. Write the boring integration tests nobody wants to write. Triage failing pipelines. Pick three and put numbers on them. Hours saved, error rates, anything concrete. If you are thinking about where agents sit in a broader orchestration design, the distinction between single-agent and multi-agent architectures is worth settling before you scope the deployment.

Talk to your security and compliance partners now, before the vendor demo. The fastest path to a stalled pilot is showing up with a tool and no answer to the data residency, audit logging, and model output review questions. I have seen this pattern repeat across orgs and the result is always the same. Six months of slideware, no deployment.

Finally, watch what this does to the Copilot conversation. If Codex can run on-prem next to your code, the bar for what Microsoft has to offer inside the same boundary goes up. That is good for everyone building inside enterprise walls. The Anthropic acquisition of Stainless is worth watching in this context too, because the SDK layer that governs how these agents are called and integrated is quietly becoming as strategic as where the model runs.

The era of AI coding agents being a public-cloud-only story is ending, and the orgs that prepared their data and governance posture early are going to look very smart in twelve months.

Source: OpenAI and Dell partner to bring Codex to hybrid and on-premise enterprise environments (OpenAI).

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

May 18, 2026
Anthropic Acquired Stainless and the SDK Layer Just Became a Strategic Battleground

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

Anthropic just announced it has acquired Stainless, the company that auto-generates SDKs for OpenAI, Anthropic, and a long list of other API providers. The news that Anthropic acquires Stainless dropped this week and most of the commentary I have seen so far is treating it like a routine talent grab. I think that misses what is actually happening here.

This is Anthropic buying the layer that decides whether you actually ship on their platform or not.

What it actually does

Stainless is the tool a lot of AI labs use to turn an OpenAPI spec into idiomatic SDKs across Python, TypeScript, Go, Java, Kotlin, and Ruby. You write the spec once, Stainless generates clients that feel native in each language, handles auth, retries, streaming, pagination, and types. It is the thing that turns a raw HTTP API into something a developer can pip install and use in fifteen minutes.

Both the official Anthropic SDKs and the OpenAI SDKs have been generated by Stainless. So have SDKs for Cloudflare, Together, and others. The team built a real product around the boring but critical work of keeping client libraries in sync with API changes, generating typed responses, and producing docs that do not lie.

Anthropic is keeping Stainless running as a product and the existing customer relationships intact, at least for now. The team joins Anthropic. The IP comes with them.

Why it matters

The part I find most interesting is the strategic read. For years, the developer surface around an API was treated as overhead. You shipped a Python SDK, maybe a JS one, and called it done. Whoever wrote the cleanest curl examples won the docs game and that was the bar.

That bar is gone. When you are building agents, tool calling becomes the API. The shape of the SDK, how easy it is to define a tool, stream a response, handle a partial JSON object mid-stream, retry on a 429, all of that is what determines whether a developer ships or rage-quits. The SDK is no longer a wrapper. It is the product surface.

Anthropic seeing this clearly enough to acquire the team that builds it is, to me, a smarter move than most people will give it credit for. The model gets all the headlines but the SDK is what decides if your agent loop is 40 lines or 400. I have written before about how prototyping on the direct Anthropic API and lifting to Bedrock later burns a sprint. A big chunk of that pain is SDK-shaped. Region naming, model version strings, quota structures, retry behavior. Owning the SDK generator means Anthropic can make that migration story coherent instead of leaving it to whoever happens to be on call.

There is a real tension though. Stainless generates SDKs for OpenAI too. And for several other competitors. Anthropic says the existing customer relationships continue. I believe that for now. I do not believe it forever. At some point a feature lands in the Anthropic SDK two weeks before it lands in the OpenAI one, and people will notice. Neutrality in this part of the stack is going to be tested.

The other thing worth saying out loud: this is part of a pattern. Anthropic has been moving down the stack steadily. Trainium for compute. Finance agents and creative agents for vertical surface. Now SDK generation for the developer entry point. They are not just shipping a better model. They are building the full vertical from silicon to import statement.

What I would do with it this week

Concrete and short.

First, I would pin my current Anthropic SDK versions in any production code and write down the version numbers somewhere I will actually look. SDK velocity is about to go up. That is good news but it means breaking changes will move faster too. Pin and review on a schedule rather than letting Dependabot push silently.

Second, if you are still calling the Claude API with raw HTTP requests inside a Power Automate HTTP action or a custom connector, this is a good week to check whether the official SDK now covers your case. Custom connectors built around the SDK shape tend to age better than ones built around whatever curl example was on the docs page that day.

Third, if you have been on the fence about building tool calling into an agent, the ergonomics around tool definition in the Claude SDK are about to be the most invested-in part of the platform. Now is the time to start. I have been writing about this space long enough to know when a piece of infrastructure is about to get serious attention. This is one of those moments.

The SDK layer is where the next year of the AI developer experience will be won or lost. I am glad someone is finally treating it that way.

Source: Anthropic acquires Stainless \ Anthropic (Anthropic).

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

May 18, 2026
Power Platform May 2026 Update Shipped and UDTs Going GA Is the Headline for Me

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

The May 2026 Power Platform feature update dropped on May 14 and the list is long. Copilot updates, Dataverse changes, governance bits. But the one item I keep coming back to is Power Fx user defined types going generally available. If you write any non-trivial Power Apps, this is the change that matters. UDTs are GA as of version 3.26044, enabled for new apps by default, and switchable on existing apps through settings.

What Power Fx user defined types GA actually does

UDTs let you define a named, structured type once and use it everywhere in your app. You declare them with the Type function in the App’s OnStart or named formulas. Something like Type({ Id: Text, Name: Text, Status: Text, DueDate: DateTime }) bound to a name, and now every function signature, every variable, every collection can reference that type by name.

Before UDTs, type information in Power Fx was inferred from whatever record you happened to pass first. Pass a record with one less field and Power Fx would silently widen or narrow the schema. Build a component that took a record parameter and good luck enforcing what was inside it. The result was a lot of defensive coding, a lot of IfError, and a lot of runtime surprises.

With UDTs you get a contract. A function expects a specific shape. A component prop declares what it accepts. Collections carry a known schema instead of guessing from the first row. The Type function reference covers the syntax if you want the official version.

Why it matters for app maintainability

Power Apps has had a maintainability problem for years. Not because the platform is bad. Because untyped records meant every medium-sized app slowly turned into a pile of implicit assumptions. You open someone else’s screen six months later and you cannot tell what shape locSelectedItem is supposed to be without running the app and inspecting it live.

UDTs make those assumptions explicit. The variable has a type. The component prop has a type. The function returns a type. When the schema changes, you change it in one place and Power Fx tells you everywhere it breaks. That is the difference between a 2000-line app you are afraid to touch and one you can actually refactor.

There is a real trade-off though. You give up some of the speed of just throwing a record into a variable and moving on. For tiny apps that is overkill. For anything that more than one person touches, or anything that lives longer than a quarter, the upfront type definition pays for itself the first time you onboard a new developer.

The other thing UDTs do, and this is the part I find more interesting, is that they make Power Fx feel like a language you can actually build component libraries in. Reusable components have been technically possible for a while. They have not been pleasant because the prop interface was loose. With named types, a component library starts looking like an SDK instead of a copy-paste exercise. If you are thinking about how governance fits around that kind of library work, Power Platform governance that does not kill adoption is worth a read before you start standardising component patterns across teams.

What I would do with Power Fx user defined types this week

Pick one existing canvas app. Not a critical one. Something internal that you wrote and you are tired of debugging. Enable UDTs through settings, updates, new, user-defined types.

Then find the single record shape that gets passed around the most. The selected item from your main gallery, the form values for your main edit screen, the API response from your most-used connector. Define it as a UDT in App.OnStart with the Type function. Give it a clear name. Refactor the three or four places that record gets read or written to use the named type.

You will hit one or two spots where Power Fx now flags a mismatch that was silently working before. That is the point. Those mismatches were latent bugs. Fix them. Then look at any component you wrote that takes a record input and convert the prop to your new named type.

That is enough for week one. Do not try to type the whole app at once. The way I have seen this go sideways elsewhere is people treating UDTs like a migration project instead of a habit. Start with one type, one screen, one component. Build the muscle.

I have written before about moving business logic out of system prompts and into managed artifacts, and UDTs are the same idea at the Power Fx layer. Put the contract in one place, let everything else reference it, and stop hiding the schema in tribal knowledge. If you are wiring typed records into flows alongside your canvas apps, the Power Automate error handling patterns post covers how to keep that layer equally explicit about what it expects and what it does when things break. More notes on what I am building with this are on my LinkedIn.

This is the kind of change that does not look exciting in a release post and ends up changing how I write Power Fx every day.

Source: What’s new in Power Platform: May 2026 feature update (Microsoft Power Platform Blog).

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

May 17, 2026
Anthropic Just Launched Claude for Small Business and the SMB Play Is Getting Serious

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

Anthropic shipped Claude for Small Business this week. A dedicated tier with admin controls, team billing, and collaboration features aimed squarely at companies that are too big for the personal plan and too small for the Enterprise sales motion. If you have been watching how frontier AI vendors reach the long tail of orgs, claude for small business is a signal worth paying attention to.

For years, SMBs lived on Microsoft 365 plus a pile of spreadsheets and maybe a Power Automate flow somebody built once and never touched again. Anthropic just walked into that space with a real product, not a discount on the Pro plan.

What it actually does

The new tier gives small businesses a Claude workspace with team management, centralized billing, and admin controls. You get the same Claude models the rest of the market uses, but wrapped in the boring infrastructure that actually matters when more than one person needs access: user provisioning, usage visibility, and a single invoice instead of five personal subscriptions billed to different cards.

It is positioned between the individual Pro plan and the full Enterprise contract. No procurement cycle, no security questionnaire, no minimum seat commitment that scares off a ten-person company. You sign up, add your team, and you are running.

The feature list is not exotic. That is the point. Anthropic is not trying to wow SMBs with new model capabilities. They are removing the friction that kept Claude out of small business workflows entirely.

Why it matters

The interesting part is not the product. It is the strategic move.

Frontier AI vendors have spent the last two years chasing Fortune 500 logos. Custom contracts, dedicated capacity, named account teams. Anthropic’s enterprise services arm made that play explicit. But the F500 is a few thousand companies. The SMB segment is millions. And those companies make tooling decisions in days, not quarters.

Microsoft has owned this segment by default. Copilot for Microsoft 365 lives where SMBs already work. Email, documents, Teams. Anthropic showing up with a focused product means the workspace conversation is no longer a Microsoft monologue. A ten-person agency can now pick Claude as their primary AI tool without feeling like they are going off-script.

The bigger second-order effect is what mid-market buyers will start asking for. SMBs adopt fast and complain loud. The patterns that emerge here, the integrations they wire up, the workflows they build, will shape what a 500-person company asks for eighteen months from now. I have written before that vendor stratification was coming for AI tooling the way it came for SaaS a decade ago. This is what it looks like in practice. Anthropic has already shown it will compete on vertical specialization too — the Claude Finance Agents launch is a good example of how the segmentation strategy is playing out across different buyer types.

There is a risk worth naming. SMBs that adopt Claude as their primary AI surface and then grow into mid-market will be running a workspace that does not natively live inside their Microsoft tenant. That integration gap is real. It is also exactly the kind of gap that makes a third-party connector market explode.

What I would do with it this week

If I were running a small operation right now, I would do three things.

First, I would actually try the tier with a real team, not a solo account. The admin and billing experience is where these products live or die for small businesses, and you cannot evaluate it alone.

Second, I would map which workflows currently live in spreadsheets and shared inboxes. Those are the workflows that move to Claude first in an SMB. Not the polished automation candidates, the messy ones nobody owns. The places where a capable assistant with team context replaces a process that was never documented.

Third, I would think hard about the integration surface. Claude on its own is a chat product. The value compounds when it touches your actual data and tools. For a small business that already runs on Microsoft 365, that means either calling Claude from a Power Automate flow through the API, or accepting that the Claude workspace and the Microsoft workspace will live in parallel for a while. Both are fine. Pretending you do not need to pick is not. If you are evaluating how the two model ecosystems compare for automation use cases specifically, Claude vs ChatGPT for automation is worth reading before you commit to a direction.

The addressable market for capable agents just got wider. Watch what the long tail builds with it.

Source: Introducing Claude for Small Business \ Anthropic (Anthropic).

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

May 14, 2026
Microsoft’s Intelligent Apps Post Is About Leadership and I Think They Buried the Lede

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

I opened Microsoft’s April post on intelligent apps and human leadership expecting another speed pitch. Faster tasks. Faster decisions. Faster output. The usual rhythm. What I actually read was a piece where the words intelligent apps and human leadership are deliberately bolted together, and I think most people skimmed past the second half.

The leadership piece is doing all the work in that post. The intelligent app is the easy half. I keep seeing automation teams treat AI features as a productivity multiplier when the actual constraint is whether anyone in the org is willing to redesign how decisions get made. Skip that, and you ship faster versions of the same broken workflows.

I read the post expecting another speed pitch and got something else

Microsoft could have written a clean speed story. They have the numbers for it. Instead the framing is that intelligent apps need a new shape of work, and that shape is built by humans who lead differently, not by humans who type faster.

That is not a marketing flourish. That is the part of the message that decides whether your AI rollout pays off or quietly burns budget. I have been writing about decision ownership for a while now, and this post is the closest I have seen Microsoft come to saying it out loud.

Speed is a trap when the underlying decision rights have not moved

Here is what I keep running into. A team takes a slow approval process. They drop an agent in the middle of it. The agent now drafts the recommendation in two seconds. Approval still takes four days because three managers still need to sign off, and none of them changed how they review.

You did not speed up the process. You sped up the part nobody was waiting on.

Worse, the agent now produces ten times the volume of recommendations the approval chain was sized for. The queue grows. People rubber-stamp to keep up. The quality of the decision drops while the appearance of throughput goes up. I have written before that automating a bad process just makes it fail faster. Intelligent apps make this failure mode worse, not better, because the speed gap between the AI step and the human step gets wider. This dynamic is one reason RPA vs AI automation comparisons often miss the point — neither technology fixes a process where decision rights have not moved.

If decision rights do not move, speed is a trap.

What human leadership actually has to do for an intelligent app to work

The Microsoft post uses the phrase human leadership as if everyone knows what it means. I do not think we do. So here is what I think it has to mean operationally for an intelligent app to actually pay off.

First, someone with authority has to redraw the decision boundary. Which calls does the agent make on its own. Which calls go to a human. Which calls require two humans. That is not a developer task. That is a leadership task, and most orgs avoid it because it is uncomfortable.

Second, the constraints the agent operates under have to be owned by a person, not buried in a system prompt. This is exactly why Microsoft’s business skills in Dataverse matter. They give policy a home with an owner and a version history. Without that, your intelligent app is running on tribal knowledge that nobody can update.

Third, leaders have to stop measuring the team on volume of approvals or tickets closed. If the agent is doing the routine work, the human metric has to shift to quality of exception handling and quality of policy. Otherwise you are paying senior people to do work an agent already did.

None of this is a feature you ship. All of it is org design. The Power Platform tooling will not do it for you.

The teams I see getting this right are doing one specific thing first

The teams I talk to who are actually getting value out of intelligent apps and human leadership do one thing before they build anything. They write down, on one page, who currently owns each decision in the process and who will own it after the agent ships. Same column, different rows. The delta is the work.

That page is uncomfortable to produce. It surfaces the fact that some managers are about to lose a piece of their job, that some policies have no clear owner, and that some approval steps exist only because nobody ever questioned them. This is the part most teams skip, because it is political, not technical. It is also why most Power Platform Center of Excellence setups stall in month three — the governance conversation requires the same political work that most teams defer until it is too late.

The teams that skip it ship a working app and wonder six months later why nothing changed. The teams that do it ship a smaller app and quietly reshape how a department works.

So my read on the Microsoft post is this. They did not bury the lede by accident. The lede is human leadership. The intelligent app is the part of the story everyone is comfortable talking about. The other half is the part that decides whether any of this matters.

If you want to see how I think about this kind of org-shaped problem, more of my writing is on LinkedIn. The technology is rarely the bottleneck. The willingness to move decisions is.

Frequently Asked Questions

What is the relationship between intelligent apps and human leadership in the workplace?

Intelligent apps only deliver real value when human leadership changes how decisions are made, not just how fast tasks are completed. Without redesigning decision rights and workflows, AI tools tend to accelerate broken processes rather than fix them.

Why does automating an existing process sometimes make things worse?

Automation increases the speed and volume of outputs, but if the approval or review process stays the same, the bottleneck simply gets worse. Teams end up rubber-stamping decisions to keep pace, which lowers quality while creating the illusion of better throughput.

How do I know if my organisation is ready for an AI automation rollout?

A good starting point is asking whether decision rights have been clearly assigned and whether leaders are willing to redesign how approvals and reviews work. If those structures are unchanged, adding AI tools is likely to surface existing problems faster rather than solve them.

When should I redesign workflows before deploying intelligent apps?

Workflow redesign should happen before deployment, not after. If the human steps in a process have not been updated to match the speed and volume AI generates, the technology will outpace the people it is meant to support.

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

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

May 7, 2026
Microsoft Just Reframed Dataverse as the Agent Data Platform and the Update List Is Worth Reading

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

Microsoft published a post on May 5 called Dataverse Is Your Agent Data Platform: Here’s What’s New. The framing is the part worth reading. Dataverse is no longer being sold as the database under your model-driven apps. It is being repositioned as the dataverse agent data platform, the layer that gives agents real business understanding instead of just rows and columns.

That is a meaningful shift in how Microsoft wants you to think about the stack. I have been waiting for this framing to land properly.

What it actually does

The update bundles several things that were previously scattered across announcements into one coherent story.

Knowledge sources let an agent ground itself in Dataverse tables, SharePoint sites, files, and external systems through a managed reference instead of a hand-rolled retrieval pipeline. The agent sees the data with its semantics: table relationships, choice columns, business rules. Not just a vector dump.

Business skills are now first-class records in Dataverse. I wrote about this in Microsoft Just Shipped Business Skills in Dataverse. Skills move policy and process logic out of system prompts and into a managed, owned, versioned artifact. The May 5 post confirms this is the intended pattern, not an experiment.

Deeper Fabric wiring means agents can reach analytical data through Dataverse without you stitching mirroring and shortcuts manually for every project. The semantic model carries through.

Copilot Studio integration is tighter on the agent side. Connected agents in Copilot Studio can pick up Dataverse knowledge sources and skills as native primitives instead of you wiring them through custom connectors and Power Automate flows.

None of these are individually new ideas. The point of the post is that they now line up as one platform story.

Why it matters

The hardest part of building an internal agent is not the model. It is getting the agent to behave like someone who actually works at your company. Org-specific policies, naming conventions, what counts as an active customer, which approval thresholds apply when. That tribal knowledge is where every agent project I have seen gets stuck.

If that knowledge lives in a 4000-token system prompt, the agent degrades. If it lives in hardcoded Power Automate flows, nobody can find it six months later. If it lives in a Word document on someone’s OneDrive, it might as well not exist.

The dataverse agent data platform framing says: put it in Dataverse as a typed, owned, versioned record, and let any agent on the stack consume it. That is an architectural decision, not a feature toggle. It changes who owns what. The policy owner updates the skill directly. The data steward owns the knowledge source. The agent builder stops guessing.

The risk I keep flagging is skill sprawl. The moment multiple teams start writing skills with overlapping scopes, the agent starts misrouting silently. Governance has to come before deployment, not as a cleanup project in month six. Microsoft is shipping the platform. The org design is still on you. That same principle applies to Power Platform governance that does not kill adoption — the structural decisions made early determine whether the whole thing scales or stalls.

I also want to see how this plays with multi-agent orchestration. I covered the patterns in multi-agent orchestration in Copilot Studio. If knowledge sources and skills become the shared substrate that connected agents draw from, the per-agent prompt size drops and routing gets more reliable. That is the part I find genuinely exciting.

What I would do with it this week

Three concrete things, in order.

First, pick one existing agent that has a bloated system prompt. Anything past 2000 tokens. Pull out the policy chunks and rewrite them as business skills in Dataverse. Measure the prompt size before and after, and run your behavioral tests on both. You will see the consistency change in the edge cases.

Second, take one knowledge source that today is glued together with a custom connector or a Power Automate flow doing retrieval. Replace it with a Dataverse knowledge source pointing at the same data. Compare the answers on questions that depend on relationships between tables. The native version handles joins the hand-rolled one fakes.

Third, draft a one-page skill ownership matrix for your tenant before anyone writes a third skill. Who owns customer policy, who owns finance approvals, who owns HR routing. Boring document. Saves you from the sprawl that kills these projects.

Read the Power Platform docs alongside the announcement. The framing finally matches what practitioners have been building toward. I am curious where it lands by the end of the quarter.

Source: Dataverse Is Your Agent Data Platform: Here’s What’s New (Microsoft Power Platform Blog).

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

May 6, 2026
Anthropic Raised Claude Rate Limits for SpaceX and That Tells You Where Enterprise AI Is Heading

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

Anthropic announced a deal with SpaceX that includes higher Claude rate limits as part of the engagement. The headline most people will read is the SpaceX logo. The actual signal is different. The anthropic spacex higher rate limits story tells you that capacity is now a negotiated enterprise lever, not a number on a pricing page.

If you are building agents seriously, this is the part to pay attention to.

What it actually does

The deal gives SpaceX elevated rate limits on Claude, alongside the usual enterprise engagement wrapping. Anthropic frames it as supporting frontier engineering work where teams need sustained throughput for code generation, document analysis, and agent loops at scale.

The published tiers on the Anthropic site still exist. Usage tier 1, tier 2, tier 3, tier 4 with their requests-per-minute and input-tokens-per-minute caps. What this announcement quietly confirms is that above those tiers, the conversation is bespoke. You sign a contract, you get a number that fits your workload.

That has been true behind the scenes for a while. Saying it out loud, with a customer name attached, is the new part.

Why it matters

Most teams I talk to still treat rate limits like an afterthought. They build a prototype on a developer key, the latency feels fine, the cost looks reasonable, and they move toward production. Then a real workload hits and the 429s start.

I wrote about this in a different shape when I covered Claude running on Amazon Trainium. The benchmark conversation distracts from the real production failure mode, which is capacity drift at peak hours. Rate limits are the same story from a different angle. Throughput is now part of the architecture, not a footnote.

Three things follow from this.

First, the gap between what a hobbyist API key can do and what a serious enterprise workload needs is widening fast. A single agent loop with tool calls, retries, and a few sub-agents can burn through a tier 2 limit in seconds. Multi-agent orchestration makes it worse. If you are running ten parallel agent invocations from a Power Automate flow, each with their own context window, you will hit the ceiling before you hit the budget. If you are thinking through whether your workload even needs that kind of parallelism, the honest answer on single-agent vs multi-agent design is worth reading before you scale out.

Second, procurement now needs to ask different questions. Not just price per million tokens. Sustained tokens per minute. Concurrency. Burst tolerance. Region. What happens when your traffic doubles next quarter. Most enterprise AI contracts I hear about from people at other organisations still get signed without these numbers nailed down. Anthropic is moving further in this direction across the board, and their enterprise AI services arm is exactly the context in which these bespoke capacity conversations are going to happen.

Third, the platform vendors are going to feel pressure here. If you are running Claude through Bedrock or through Copilot Studio, your effective rate limit is shaped by both Anthropic and the platform layer. The platform abstracts capacity, which is convenient until it is not. Knowing where the ceiling actually sits in your stack is going to matter more, not less.

What I would do with it this week

If you are running anything beyond a demo, instrument the throughput. Not just success and failure counts. Tokens per minute, requests per minute, p95 latency, and 429 rate, broken down by flow or agent. You cannot negotiate a number you have not measured.

Then look at your system prompts. Token bloat is the cheapest capacity win available. A prompt that drifted from 800 to 4000 tokens over a few sprints is not just costing you money, it is eating your throughput ceiling on every single call. I have seen this kill production agents at peak hours when nobody changed the model or the workload.

Then map your workload to a tier. If your steady state is comfortably inside a published tier, fine. If you are within forty percent of the ceiling on any axis, you are already in negotiation territory. Start the conversation before the incident, not after.

For teams building on Power Platform with Claude in the loop, the same logic applies through whatever connector or custom action you are using. Concurrency settings on a Power Automate flow can mask the real call pattern until it does not. Know what your worst minute looks like.

The SpaceX deal is a marker. Capacity has joined price and capability as a first-class procurement axis for enterprise AI, and the teams treating it that way now will have one less surprise next year. (My ongoing notes on this stuff live on my LinkedIn if you want to follow along.)

Source: Higher usage limits for Claude and a compute deal with SpaceX \ Anthropic (Anthropic).

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

May 6, 2026
Anthropic Just Launched Claude Finance Agents and the Specialization Trend Is Real

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

Anthropic shipped Claude Finance Agents this week. A set of Claude-powered agents built specifically for financial analysts, with native connectors to LSEG, Moody’s, S&P Global, and Morningstar. This is not a generic chat assistant pointed at a finance prompt. The Claude finance agents are a packaged product with the data plumbing already done.

I have been watching this trend build for months. This release makes it impossible to ignore.

What Anthropic actually shipped

Three agents wrapped around specific analyst workflows. One handles modeling. One handles due diligence. One handles comparable company analysis. Each one is a Claude agent with a defined scope, a system prompt tuned to that workflow, and direct connectors into the data providers analysts already pay for.

The connector list is the part that matters. LSEG for market data. Moody’s for credit. S&P Global for company financials. Morningstar for funds. These are not scraped sources. They are licensed enterprise feeds. Anthropic did the integration work that every internal team building a finance copilot would otherwise have to do themselves.

You can read the full announcement on Anthropic’s site. The pricing structure is enterprise. The target user is clear. This is not a consumer move.

Why this release matters beyond finance

For two years the pitch from foundation model vendors was: here is the model, build whatever you want. That is over.

Now the pitch is: here is the model, here is the agent, here are the connectors, here is the workflow. The vendor is moving up the stack into the application layer. Anthropic is doing it for finance. Microsoft is doing it for general enterprise productivity. OpenAI is doing it for coding and research. The pattern is consistent. Anthropic launching an enterprise AI services arm was an early signal of exactly this direction.

This changes the build-vs-buy math in a real way. If you are an enterprise team that was about to spend six months building a Claude-based comparable company analysis agent on top of a generic platform, you now have to ask whether your custom version will actually beat what Anthropic ships out of the box. Most of the time, in the specific domains where these vertical agents land, the answer will be no.

That does not mean custom builds are dead. It means the line moves. Custom builds make sense where the vendor product does not exist or does not match your specific data and policies. Generic finance modeling? Probably not worth building. Your firm’s specific deal screening logic with your proprietary scoring model? Still custom.

The other thing this release confirms is that tool design is product design. I have written before that agentic workflows live or die on the quality of their tool layer. Anthropic clearly figured this out. Wrapping LSEG and S&P data with proper structured outputs that Claude can reason about is the actual hard work. Anyone who has tried to build this on top of raw connectors knows.

This specialization pattern also raises a real architectural question: when the vendor ships a domain-specific agent, does your orchestration layer treat it as a peer, a sub-agent, or a replacement? That is the same question I work through in when to build a multi-agent system instead of a single agent.

What I would do with it this week

I do not work in finance, so I am not deploying this in production. But here is what I would do if I were on a finance team, and what I am doing in adjacent domains.

First, audit any internal agent project that overlaps with what Anthropic just shipped. If a team has been building a comparable company analysis tool for four months and Anthropic just released one, that conversation has to happen now, not in Q3.

Second, look at the connector list and ask which of those data sources your team already licenses. The value of Claude Finance Agents drops fast if you do not have LSEG or S&P feeds. Vendor lock through data integration is the real moat here.

Third, think about what the equivalent looks like in your domain. If Anthropic shipped finance agents in May 2026, what does an HR agent product look like? A legal one? A procurement one? Someone is building each of these. Probably more than one someone. In my experience, the teams that win the build-vs-buy decision are the ones that ask the question early, not the ones that finish their custom build and then discover the vendor product. The same specialization logic is visible in Microsoft Discovery as the first real glimpse of domain-specific agent platforms.

For Power Platform builders, this is also a useful signal. Copilot Studio is Microsoft’s answer to the same trend, and the business skills work in Dataverse is the integration layer equivalent. The shape of the market is clear.

The era of generic agent platforms competing on model quality alone is closing. The next round is about who owns the workflow.

Source: Agents for financial services \ Anthropic (Anthropic).

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

May 5, 2026
Microsoft Just Shipped Business Skills in Dataverse and This Is How You Teach Agents Your Org

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

Microsoft announced business skills in Dataverse on May 1, and this is the announcement I have been waiting for. Dataverse business skills for agents let you encode org processes, policies, and the tribal knowledge that lives in people’s heads as natural-language instructions. Agents discover them and follow them at runtime. No more cramming everything into a 4000-token system prompt and hoping the model remembers how your finance team handles approvals.

I have been reading the docs since Friday. Here is my honest take.

What business skills actually do

A business skill is a Dataverse record. It contains a natural-language description of when the skill applies, what the agent should do, and what data or actions it can use. Agents query Dataverse at runtime, find the skills that match the user’s intent, and follow the instructions inside.

The shape matters. You are not writing code. You are writing the kind of paragraph you would send to a new hire on day one. Things like: When someone asks about expense approvals over 5000 EUR, route to the regional finance lead, never to the team manager. The lookup table is in the Finance Approvers table. Always confirm the amount and the cost center before submitting.

That description is stored, versioned, and indexed. Multiple agents can use the same skill. You update the skill once and every agent that discovers it picks up the new behavior. There is also a permission layer, so a skill can be scoped to a security role, a team, or an environment.

Underneath, this is grounding. The agent does not memorize your org. It retrieves the relevant skill at runtime and follows it.

Why this changes how you build internal agents

The hardest part of deploying internal agents has never been the model. It has been getting the agent to behave like someone who actually works at your company. The model can reason. It cannot know that your procurement policy changed in March, or that the Madrid office handles APAC tickets on Wednesdays because of a coverage gap.

Until now, that context lived in three bad places. System prompts that grew until they hit the context window and started degrading. Power Automate flows with hardcoded business logic that nobody could find six months later. Or worse, it lived nowhere and the agent guessed.

I have written before that a focused 400-token instruction set produces more reliable behavior than a 4000-token one. Business skills make that practical. You stop stuffing the prompt and start composing skills. The agent picks the right ones for the job.

The other thing this fixes is ownership. A business skill in Dataverse has an owner, an audit trail, and a lifecycle. When the policy changes, the policy owner updates the skill. They do not need to find the agent maker, file a ticket, or wait for a release. That is a real architectural shift, not a feature flag. If your org is still working out who owns what when policies change, Power Platform governance that does not kill adoption covers how to structure that before it becomes a cleanup problem.

The risk I am watching: skill sprawl. If every team writes their own skills with overlapping scopes, the agent will face the same routing problem multi-agent setups face. Skill descriptions will start competing with each other and you will get silent misrouting. Governance has to come early, not as a cleanup project in month six.

What I would do with it this week

Pick one painful, well-bounded process. The kind where the answer is always it depends on who you ask. Approval routing is a good candidate. Onboarding checklists work too.

Write three to five business skills that capture the rules. Keep each one short and specific. Connect them to a Copilot Studio agent that already has the right Dataverse and Power Automate connectors. Test with the messy questions, not the clean ones. Watch which skills get picked and which do not.

The thing to measure is not whether the agent answers correctly. It is whether the right skill was selected for the right phrasing. If selection is unreliable, your skill descriptions are too similar or too vague. Rewrite them and try again. If you are also wiring up custom connectors to extend what the agent can reach, How to Build a Custom Connector for Copilot Studio Step by Step is worth keeping open in a tab.

I will be writing more about this once I have run a real internal pilot. Early signals are good. In my experience, the patterns that survive contact with production are the ones where context is stored where it belongs, not where it was convenient at build time.

This one belongs in Dataverse. Finally.

Source: Introducing business skills: Teach agents how your organization works (Microsoft Power Platform Blog).

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

May 5, 2026
When should I build a multi-agent system instead of a single agent?

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

Short answer: stay single-agent until you hit one of three specific failure modes. Tool overload past roughly 8 to 10 connectors. Conflicting system prompts that cannot be reconciled in one instruction set. Or genuinely parallel workstreams that need to run at the same time. If none of those apply, the single agent vs multi-agent question is already answered. Build one agent.

Most posts on this topic make multi-agent sound like the natural next step. It is not. It is a tax you pay when a single agent can no longer do the job, not an upgrade you take because it sounds more sophisticated.

The longer answer

I read a good piece on Towards Data Science walking through ReAct workflows and when scaling to multi-agent makes sense. The framing matched what I keep running into when I talk to people building on Copilot Studio and similar platforms.

A single agent is a loop. It reads, picks a tool, calls the tool, reads the result, picks again, until it decides it is done. That loop works well when the tool list is small enough for the model to reason over cleanly and the instructions do not pull the model in two directions.

It starts breaking in predictable places.

The first is tool overload. I have written before about how a model that hits 95 percent accuracy on tool selection with two connectors can drop to 70 percent with five, because tool descriptions start competing with each other. By the time you have ten or twelve tools, the agent picks the wrong one regularly and you cannot fix it with prompt tweaks.

The second is prompt conflict. If your agent needs to behave like a strict policy checker for one task and a friendly explainer for another, those two personas fight inside one system prompt. You can feel it in the outputs. The model compromises in the wrong direction.

The third is parallelism. A single agent loop is sequential by design. If you have three independent workstreams that must run at the same time, no amount of prompt engineering will make a single ReAct loop parallel. This is also where thinking through whether AI automation is even the right fit versus a simpler RPA approach becomes worth the time.

Everything else, latency, observability, prompt size, can usually be solved without splitting agents.

How to decide in practice

I use a short checklist when someone asks about single agent vs multi-agent for a Copilot Studio build.

Count the tools. If you are under eight connectors and the descriptions do not overlap, one agent is fine. Past ten with overlap, start thinking about splitting.

Read the system prompt out loud. If it contains contradictory instructions for different scenarios, that is a real signal. Splitting reduces prompt size per agent, and a focused 400-token instruction set produces more reliable behavior than a 4000-token one. I covered this in more detail in my post on multi-agent orchestration patterns in Copilot Studio.

Map the workstreams. Are they actually independent, or are they sequential steps you are calling parallel because it sounds nicer? Most automation work is sequential. Real parallelism is rarer than people think.

Budget the latency. Every hop between agents adds round-trip overhead. If you split a single agent into three, you have just added two more model calls and two more HTTP boundaries to every request. I have written about how accumulated round-trip overhead kills perceived performance long before any single call gets slow.

If the checklist points to multi-agent, default to a supervisor pattern. One parent agent routes to focused child agents. Skip the peer network where agents call each other freely. It looks elegant in diagrams and is painful to debug in production.

Microsoft has shipped real multi-agent orchestration in Copilot Studio, so the platform support is there. The question is whether your problem actually needs it.

Related gotchas

Routing in Copilot Studio multi-agent setups depends on the description you write for each connected agent, not on trigger phrases. A vague description causes silent misrouting that is harder to debug than a broken trigger. Write descriptions like API contracts, not marketing copy.

When a parent agent picks the wrong child confidently, you get the same failure mode as a single overloaded agent, just one layer deeper. Splitting agents does not eliminate misrouting. It moves it.

Token costs multiply faster than you expect. Each agent in the chain re-processes context. Three agents in a sequence is not three times the cost. It is often closer to five or six times once you count the context each one needs to reason properly.

If you are still on the fence, build single first. You can always split later. Going from multi-agent back to single, on the other hand, almost never happens once the architecture is in place. That is the trade-off worth keeping in mind. More on how I think about these trade-offs here.

Frequently Asked Questions

When should I use a single agent vs multi-agent system?

Stick with a single agent until you run into one of three problems: too many tools causing the model to pick the wrong one, conflicting instructions that cannot coexist in one system prompt, or parallel workstreams that need to run at the same time. If none of those apply, a single agent is the right choice.

How do I know if my agent has too many tools?

A good rule of thumb is to keep your tool count under eight to ten connectors. Beyond that, tool descriptions start competing with each other and the model’s ability to select the right one drops noticeably, even if prompt tweaks do not seem to help.

Why does a single agent struggle with conflicting instructions?

When a system prompt asks the model to take on two opposing behaviours, such as acting as a strict policy checker and a friendly explainer, those personas create tension within a single instruction set. The model tends to compromise in ways that produce unreliable outputs rather than handling each mode correctly.

What are the main reasons to build a multi-agent system?

Multi-agent systems are worth the added complexity when you need genuinely parallel workstreams, have irreconcilable prompt conflicts, or are dealing with tool overload that cannot be resolved through better descriptions. Outside of those scenarios, the extra coordination overhead rarely pays off.

Source: Attention Required! (Towards Data Science).

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

May 4, 2026