That sketch is not a metaphor from the past; it is a mirror of the present. AI transformation today feels like learning to walk: you try, you sense, you adjust, and you try again. This real-time learning loop is changing how enterprises must think about budgeting and driving adoption, especially when navigating the boundary between OpEx and CapEx.

Learning to Walk: AI Transformation Lives in Opex

In the sketch of the baby learning to walk, the child isn’t succeeding because someone bought better shoes. The progress comes from the continuous loop: Try → Sense → Adjust → Try again.

This is exactly how organizations are implementing AI right now:

• A workflow goes live.
• Humans interact with AI.
• Prompts, guardrails, and logic are tuned.
• The system stabilizes.
• The next iteration begins.

This is not a one‑time investment. This is ongoing operational work, the definition of Opex. AI learns in Opex. AI creates value in Opex. AI transformation is learning to walk at enterprise scale.

Human + AI Walking Together: Machine Labor Enters the Operating Model

When driving adoption, however, it is important not to simply roll out an AI tool and ask people to incorporate it into their daily work without first ensuring that they can create value with it. The five essentials discussed later resemble the skills behind the first sketch. This time, the goal is to become an “agent boss”, a transition that is easier when you build with AI rather than merely use an existing tool.

I often begin workshops and keynotes by sharing how I unexpectedly became an agent boss myself. It started with a simple question: Which activities consume the most time in my working day? The answer included tedious work, repetitive processes, and administrative tasks governed by the same rules.

Above second sketch – a person and an AI companion walking side by side – captures what is happening inside organizations today. AI is no longer a tool sitting quietly in the background; it is becoming a parallel worker that performs cognitive tasks alongside people. In practice, I translated some of the skills I use in my own work into reusable capabilities that agents can apply to specific tasks.

Crucially, I did not build a monolithic architecture. I created a framework in which agents can collaborate with one another. Large language models perform particularly well when they have clearly defined roles, boundaries, and guardrails. The idea resembles robots on a production line: one may be specialized in welding pallets, while another assembles parts with adhesive. From an operating-model perspective, consider what happens after these agents are deployed:

Once deployed, machine labor is:

• Consumed – through tokens, inference cycles, and agent runs
• Metered – per request, workflow, or decision
• Variable – scaling with the workload
• Continuous – never truly “done”

This resembles the behavior of human labor hours. In other words, AI is entering the labor model, and labor sits within OpEx. That is why CFOs are increasingly being asked to shift AI budgets from traditional IT cost centers toward workforce-productivity cost centers.

Like human labor, machine labor is becoming:

• Measurable
• Forecastable
• Plannable
• Optimizable

Just like human labor, machine labor can be measured, forecast, planned, and optimized. Examples include the agent that monitors my inbox, the agent that watches for Teams mentions, and the agent that maintains my work diary.

The Five Essentials Sketch: Capex Builds Readiness, Opex Builds Value

IIn the “Five Essentials of AI Transformation” sketch, each element surrounds the human‑AI partnership:

• Strategic alignment
• Data readiness
• Human‑in‑the‑loop design
• Operational integration
• Value measurement & iteration

These essentials are not theoretical; they describe what organizations are doing today. Together, they reveal a new budgeting boundary:

Capex builds readiness. Opex builds capability. Iteration builds value.

CapEx remains necessary for:

• foundational AI platforms
• enterprise data pipelines
• private fine‑tuning infrastructure
• workflow redesign programs

Yet none of these investments creates value on its own. Value emerges when people and machine labor interact continuously within real workflows.

That ongoing interaction belongs in OpEx.

The Budget Shift Happening Now: Human‑Only Labor → Human + Machine Labor

After translating my own capabilities into machine-readable skills and assigning many daily tasks to agents, I faced a new challenge: convincing management to adjust our departmental budgeting model. The required shift mirrors a model that many organizations are beginning to adopt:

Traditional model

• Human labor (Opex)
• IT systems (Capex + Opex)

Emerging model

• Human labor (Opex)
• Machine labor (Opex)
• AI platform capability (Capex)
• Workflow iteration (Opex)

Machine labor includes:

• inference cost
• token consumption
• agent execution cycles
• orchestration bandwidth
• retraining loops
• human‑in‑the‑loop validation

These are recurring operational costs rather than one-time capital investments. This helps explain why finance leaders are discussing shifts toward workforce-productivity spending, dedicated AI labor cost centers, and machine labor as a distinct labor category.

• AI spending is shifting toward workforce productivity
• AI labor cost centers are emerging
• Machine labor may become a distinct labor category

This shift is happening now, not merely in theory or in some distant future. If my agent framework is not to be constrained by funding, management must understand that it is not a one-time implementation; it requires continuous operational investment.

Tomorrow, I may discover that a skill needs improvement. Guardrails may need to change as internal policies or external regulations evolve. New agents will join the framework as new tasks emerge. Like a child learning to walk, the system improves through repeated practice, feedback, and adjustment.

Why the Sketches Matter Today

The sketches are more than illustrations; they are practical models of what organizations are experiencing:

• The child learning to walk → AI transformation is exploratory, iterative, and operational.
• The person and AI walking together → AI is becoming a parallel source of labor capacity.
• The five essentials → CapEx builds readiness; OpEx develops capability and creates value.

The visuals make the economics intuitive. They help leaders see that AI is not a one-time project; it is a capability that must be practiced, guided, and continually improved.

What Leaders Must Do Now

• Budget AI as labor capacity, not merely as IT spending – plan machine labor in the same disciplined way as human labor hours.
• Create AI labor cost centers – separate machine-labor OpEx from traditional IT OpEx.
• Forecast AI labor demand – use workload modeling rather than license counts.
• Measure productivity per machine-labor hour – use it as an input to ROI analysis.
• Shift iterative transformation work from CapEx to OpEx – treat workflow tuning, evaluation, and feedback loops as operational disciplines

Conclusion: AI Transformation is Learning to walk, right now

AI is not a single tool or product. It is a new form of labor. Once machine labor enters the operating model, the OpEx–CapEx boundary shifts:

• Capex builds capability.
• Opex generates value.
• Machine labor becomes a measurable, scalable, operational input.

Like learning to walk, AI transformation succeeds through continuous practice and adjustment, not through a one-time investment. Organizations that progress fastest will treat AI as a capability to develop: start with a valuable task, define clear guardrails, keep people in the loop, measure outcomes, and improve with every step. CapEx creates the foundation; OpEx sustains the learning that turns AI into value.

Finally, there is one recurring question I still hear during Q&A sessions: “Did AI take my job?” In a sense, it took over many of the responsibilities and tasks that once defined my role. Where appropriate, those activities shifted to a human-in-the-loop model, because I designed them that way. My work moved from completing tasks myself to developing frameworks that enable AI to perform them. My responsibility did not disappear; it evolved from personally executing every task to overseeing the decisions AI helps make on my behalf.

Beginning September 1, 2026, the grace period for existing agents and workflows built using the GitHub Copilot harness in Copilot Studio will end. These agents and workflows will begin consuming Copilot Credits under the usage-based billing model.
This applies to GitHub Copilot harness agents and workflows created before August 3, 2026, including those created in Dev or Trial environments. Both maker AI authoring activities and runtime execution will consume Copilot Credits. Standard harness and Copilot Chat harness agents are not affected.

I have since spoken with many FinOps teams about the additional operational challenges this usage-based billing model introduces, and the opportunities it creates for better cost governance.

Executive Summary

Copilot Studio is evolving rapidly. Yet FinOps teams face an unexpected challenge: the two official cost estimators, the Copilot Studio Estimator and the Copilot Studio GitHub Copilot Harness Estimator, are not directly comparable using their current outputs.

This is not because customers misunderstand the tools or because CX teams explain them poorly. The estimators model different layers of Copilot execution and do not expose a common set of metrics.

This article explains the background and business impact, then outlines a practical approach FinOps teams can use until Microsoft provides a unified estimator across harness types.

The Background: Two estimators, two purposes

Understanding the gap starts with recognizing that the estimators were built for different purposes.

Copilot Studio Estimator

The earlier estimator is designed to model agent-orchestration costs. It focuses on:

• grounding
• tools/actions
• flows
• modifiers
• retry inflation

It does not expose token usage.

Copilot Studio GitHub Copilot Harness Estimator

The later estimator is designed to model LLM-execution costs. It focuses on:

• light/medium/heavy complexity
• cache ratio
• model pricing

It also does not expose token usage. The result reflects different teams, timelines, and objectives. Both tools are useful, but they were not designed to align

The Problem: FinOps cannot compare the outputs directly

This is the core issue. The two estimators do not share:

• inputs
• outputs
• cost units
• token visibility
• execution model
• complexity model

As a result, their current outputs do not support a reliable direct comparison. The Copilot Studio Estimator models agent orchestration, while the Harness Estimator models LLM execution. FinOps teams need visibility into both layers, but the current tools do not provide a bridge between them.

The Impact: Friction for Architects, Makers, CX, and FinOps

ThThis mismatch creates real-world friction:

• CX teams cannot explain cost differences
• Architects cannot validate harness savings
• FinOps cannot produce unified cost models
• Customers receive contradictory numbers
• Trust suffers
• Decision-making slows down

This is not a user problem; it is a tooling gap.

The good news: A practical comparison is possible

Although the estimator outputs are not directly comparable, FinOps teams can still build a meaningful financial comparison by focusing on their shared layer:

LLM execution cost

This is the layer in which harness efficiencies may reduce costs. The comparison can be calculated outside either estimator interface, but it requires teams to collect relevant usage data, document assumptions, analyze the results, and translate them into a total-cost-of-ownership view. Any savings estimate should be validated against the organization’s actual workload and usage data.

The working solution: A practical FinOps comparison method

FinOps teams can create a comparison using four shared, measurable dimensions. For each scenario, document the source data, assumptions, time period, and expected execution volume before calculating the TCO view.

1) Model pricing

Use the applicable published model prices for the selected models and period. Record the pricing source and effective date because prices can change.

2) Expected token footprint and context

Estimate the input, output, cached, and contextual token footprint based on:

• prompt design
• grounding strategy
• context window size
• agent complexity
• harness optimization patterns

3) Tools and actions

Identify the workflows, connectors, APIs, MCP tools, and other actions invoked in each execution model. A skill can influence which tools and actions are selected, so this is not a fixed one-to-many relationship.

4) Runtime and orchestration Account for multi-step and long-running work, agentic loops, retries, and other orchestration behavior that can affect total execution costtc.

The Ask to Microsoft: Deliver a Unified Estimator

Customers need clarity. CX teams need simplicity. FinOps teams need accuracy.

The path forward is straightforward.

Microsoft should deliver a unified estimator that:

• includes the standard harness
• exposes token usage
• merges orchestration + LLM layers
• uses one cost model
• deprecates the legacy CPS estimator
• provides a single source of truth for FinOps

This is not criticism; it is a constructive, customer-driven request.

Manual cost modeling remains possible, but it is time-consuming and difficult to scale. A unified tool should connect orchestration and LLM execution costs so teams can compare scenarios quickly and consistently.

The need will only grow as:

• Multiple new LLMs are expected to become available.
• Model pricing will likely continue to decrease over time.
• Budgets are limited and require informed spending decisions.
• treats token economics and measurable value as core requirements as organizations move beyond proofs of concept

A unified estimator would give customers a clearer basis for evaluating options, governing budgets, and making informed investment decisions.

Closing: Transparency builds trust

Copilot Studio is powerful, and harness-based execution can be efficient. But sound financial decisions require transparent, comparable cost information. Budgets are finite, workloads vary, and no single model fits every scenario. As AI capabilities improve, tasks that once required 10 to 15 prompts may increasingly be completed in a single step at lower cost. Cost models must evolve just as quickly.

This article offers a practical step toward the clarity FinOps teams need today. The longer-term goal should be simple: make Copilot cost modeling transparent, consistent, and intuitive enough to support confident decisions.

Power Platform is evolving from a low-code app and automation platform into Microsoft’s governed operating layer for AI-native business transformation. That was the direction signaled at PPCC 2025. The developments we´ve seen since are strong indicators for delivering on this.

Is this another post declaring a technology “dead”? I hope not, but the final judgement is of course yours. I spent my summer vacation making memories rather than content, leaving my agents to monitor developments and handle the repetitive work. When I returned, the most revealing part of their backlog was not what they had postponed, but why: where they lacked context, encountered uncertainty, or needed a human-in-the-loop decision. That backlog became a useful signal of where the technology – and its surrounding narrative – is changing fastest.

Sharing a secret (not well kept) one of the topics an orchestrator agent supported was keep collecting information of is the Power Platform. From roadmap information, features being shipped or becoming accessible through preview as well as strategic information being shared. Need an example? You might know me from my LinkedIn posts sharing screenshots from M365 Message Center around important information. Well, it´s agents work you´re watching here. But obviously there´s more information and sources to collect from. Here you find another example of information shared recently by Charles Lamanna, EVP Copilot, Agents and Platform.

The June–August 2026 signals point to a platform that brings together apps, agents, workflows, reusable business skills, Dataverse, Work IQ and App IQ, Copilot Studio, Agent 365, and enterprise governance as one transformation system. At EPPC 2026 in Copenhagen, Ryan Cunningham described the combined organization as bringing “agents, automation, and apps in a single team” to deliver “a complete platform” for transforming line-of-business systems and processes with AI.

So, where is Power Platform heading? It is becoming the enterprise-grade construction, context, orchestration, and governance fabric for agentified business processes. Low code is not being abandoned; it is being elevated into the foundation for AI-era systems of work.

Will Power Platform continue to improve and evolve, or do recent deprecations and changes to familiar components such as Power Automate, Power Apps, and Dataverse justify the recurring claim that the platform is disappearing? Ryan Cunningham’s EPPC keynote offered a different interpretation. He moved the discussion from Copilot and Cowork productivity toward the deeper question of how organizations evolve their operating systems. Power Apps and Power Automate historically helped bridge fragmented CRM, ERP, and SCM systems, often through point solutions. The strategic shift is that Copilot, Cowork, Work IQ, Power Apps, Power Automate, and existing platform investments are enhanced rather than replaced: “we don’t have to abandon anything we’ve built” because those assets come “directly into the platform.” Other sessions extended this idea by presenting app MCP as a way to expose app tables, views, forms, grids, custom controls, and user experiences to Copilot, enabling people to act on apps from Outlook, Copilot Chat, or custom agent experiences. That is a fundamentally different narrative from business users building forms faster through drag and drop.

The new narrative is that existing apps become tool surfaces, skills, and user experiences that agents can reason over and act through. As Leon Welicki explained at EPPC, Power Platform describes this direction as Intelligent Applications: existing apps are reinvented with AI, while entirely new applications become possible. The resulting experience combines personalization, in-context AI assistance, and autonomous workflows that can dynamically plan and execute complex tasks on a user’s behalf.

Power Platform Core is therefore evolving along three axes at the same time: intelligent application experiences, automation and agents embedded in apps, and managed governance for scaled adoption. My agents also surfaced a crucial implication: the center of gravity is moving beyond citizen development toward governed, agentic business-process transformation.

Business Applications in Work IQ adds semantic understanding of business processes through auto-generated semantic models and configurable business skills. These capabilities can improve through memory and tuning and can work across Microsoft and third-party systems, reducing the need for users to switch between disconnected applications. The important departure from classic low code is that the primary artifact is no longer only an app or flow; it can also be a reusable business capability that agents discover, execute, and improve.

Copilot Studio is becoming a multi-harness platform, meaning that an agent can run through different execution environments depending on the experience and workload. The options described include Copilot Chat, Standard, and GitHub Copilot harnesses. The GitHub Copilot harness is positioned for complex business processes, long-running tasks, sophisticated reasoning, coding-intensive scenarios, and agentic workflows, with usage-based consumption. Together, these options make Power Platform components part of an enterprise semantic-action layer rather than isolated app-building services.

In his EPPC introduction to the Agent 365 foundation, Nirav Shah said the question is no longer whether organizations will have agents, but “how many and how secure” they are. He described a unified approach to observing, governing, and securing agents across Microsoft AI platforms, partner integrations, SDK-enabled agents, connected platforms, and shadow agents. Microsoft Defender guidance also describes Agent 365 observability logs and the registry as a unified source for agent inventory, posture, and runtime protection. Because licensing and transition requirements can change, the precise July 1 implications for Copilot Studio and Foundry security capabilities should be verified against the current product terms and documentation.

Power Platform’s governance story therefore expands beyond the traditional combination of the admin center and data loss prevention policies. The emerging model covers identity, agent registry and inventory, risk and posture management, tool and MCP controls, cost management, lifecycle controls, audit, and runtime threat protection.

My interpretation of these deprecations and product changes is not that familiar Power Platform capabilities are disappearing. Instead, products once discussed individually for their standalone value are increasingly acting as shared foundation services for application modernization, agentified business processes, and agents that perform work. The practical shift is to treat Power Platform as a business-process transformation platform, not only as a low-code productivity platform. The starting question becomes: Which processes require apps, deterministic workflows, adaptive agents, reusable skills, and governance to operate as one coherent system?

The maker role is expanding. Makers may still build apps and automations, but they increasingly also create skills, test solutions with evaluations, monitor production runs, optimize cost and performance, and design human-in-the-loop workflows. At the same time, Power Platform is becoming more accessible to professional developers through code apps, MCP, GitHub Copilot integration, app and code generation, and agent-ready Dataverse and business APIs.

It will be interesting to see what Power Platform Community Conference leaders reveal about the future of the platform, the direction of travel, and the trade-offs organizations will face in the next release waves. Until then, my executive answer is:

Power Platform is heading toward becoming Microsoft’s governed platform for agentifying business processes where makers, developers, IT, and business leaders can modernize apps, compose deterministic workflows with adaptive agents, ground them in enterprise context through Work IQ and Dataverse, and scale them safely through Agent 365 and Power Platform governance. The new story is no longer “citizen developers building apps”; it is “every organization redesigning work with apps, agents, workflows, business skills, intelligence, and trust.”

That is my current judgment. What is yours and which signal do you find most convincing? Leave a comment and let’s compare perspectives. Until next time…

This article began with a spark.

A colleague recently shared a thoughtful LinkedIn post exploring how to allocate the costs of AI agent activity across departments. The post raised a deceptively simple question:

“If multiple teams use the same AI agent, how do we fairly distribute the cost?”

On the surface, it looks easy. In reality, it’s one of the most common–and most misunderstood–challenges organizations face as they ramp up AI adoption.

AI agents built with Microsoft 365 Copilot, SharePoint Agents, and Copilot Studio increasingly serve multiple departments. Finance wants transparency. IT needs governance. Business units want frictionless access. And no one wants a surprise Azure invoice at month‑end.

As multi‑agent orchestration grows and agents become embedded in every business process, the need for cost management becomes as important as model quality, security, and adoption.

This article provides a practical, enterprise‑ready framework for building a transparent, defensible charged‑back model using the latest capabilities across Microsoft 365 Admin Center, Power Platform Admin Center, and the emerging Agent 365 control plane.

The scenario: A shared, Enterprise agent

Imagine you’ve built a powerful Copilot Studio agent used daily across Finance, HR, Operations, and Customer Service:

• It’s deployed in production.
• Hundreds of employees rely on it.
• It’s quickly becoming mission‑critical.

Then Finance asks the inevitable:

“How do we allocate Copilot costs back to the departments that use it?”

This is where complexity begins. Because:

• Microsoft 365 Copilot Chat uses Department‑level Billing Policies
• SharePoint and M365-surface agents use the same billing foundation
• Copilot Studio uses credit‑based billing through prepaid capacity packs or PAYG
• Power Platform PAYG is tied to environments, not departments
• Shared agents don’t align cleanly to a single cost center
• Usage varies by user population, feature usage, and agent design

And until recently, both cost visibility and cost control were limited.

Without a strategy, all costs flow into a single opaque pool – leaving Finance with no insight and business units with no accountability.

The core problem: Shared agents, shared costs, no native split

Copilot Studio (PPAC) does not natively support:

• Department-level billing
• User-level caps
• Automatic cost-center attribution

Microsoft 365 Copilot supports departmental billing,

but only for:

• Copilot Chat
• SharePoint Agents
• Agents running within M365 surfaces

Agents deployed outside M365 surfaces rely on PPAC.

This creates three enterprise risks:

1. No transparency – Finance cannot determine which department is driving consumption.
2. No accountability – Business units cannot forecast or self-govern their AI usage.
3. No cost protection – A single agent–or a single department– can accidentally consume all available capacity.

To solve this, we need a layered model approach using the tools available today.

The cost controls landscape: Track, Manage, Forecast

Microsoft’s cost‑control model spans three pillars of the broader Copilot Control System:

1. Track Costs

Consumption analytics, agent usage reporting, and message-level insights.

2. Manage Costs

Departmental billing, prepaid capacity allocation, overage enforcement, and agent-level limits.

3. Forecast Costs

Copilot Studio Agent Consumption Estimator. Let’s break them down.

1. Track costs: Visibility and Analytics

Microsoft 365 Admin Center (M365 Copilot & M365 Agents)

Copilot Credit Consumption Reports

• Track message usage in near real-time
• Alert on high-consumption users (e.g., >2,000 credits in 30 days)
• Drilldowns by user, agent, and user–agent pair
• Identify which agents drive the most usage
• Support decisions to assign full Copilot licenses to heavy users

Agent Usage Report

• Unified view across all M365 Copilot users (licensed + unlicensed)
• Active agents, active users per agent, publisher type segmentation
• User and agent-level response counts
• Low-latency insights

Power Platform Admin Center (Copilot Studio Agents)

Within the Licensing Hub, admins can now see:

• All billing plans
• Total prepaid capacity purchased vs. consumed
• Month-to-date usage vs. historical usage
• Top consuming environments
• Per-agent consumption within each environment
• Whether consumption flowed through prepaid or PAYG

This is the foundation for internal cost attribution.

2. Manage costs: Billing, Isolation, and Enforcement

A. Departmental & Agent-level Billing Policies (M365 Admin Center)

Department-level billing policies allow organizations to:

• Assign PAYG access to specific departments or Entra security groups
• Map consumption to Azure subscriptions & resource groups
• Set budget limits with email alerts and enforcement
• Control which departments can use AI agents
• Track usage per group and per agent

Agent-level billing policies

Admins are able to:

• Associate specific agents with billing policies
• Enforce governance per agent
• Separate costs for high-impact or high-cost agents

This is a major change and belongs in your chargeback model.

B. Prepaid Credit capacity packs (Copilot Studio)

Packs deliver:

• $200 / 25,000 credits per month
• Purchasable in M365 Admin Center
• Assignable per environment
• Hard boundaries (Marketing cannot consume HR’s pack)
• Rebalance capability (shift unused capacity between environments)
• Isolation that supports departmental chargeback

This is the most predictable cost model for Copilot Studio.

C. Power Platform PAYG Billing Plans

Linking an environment to Azure provides:

• Metered consumption at $0.01 per message
• No upfront commitment
• Billing visibility via Azure Cost Management
• Ability to configure budgets and alerts

PAYG Setup Requirements

• Azure subscription
• Owner / Contributor permissions
• Registered resource providers
• Production or sandbox environment (no trials, no Dataverse for Teams, no default)

This is essential as a fallback mechanism.

D. Overage Enforcement Mechanisms

When a prepaid environment exceeds allocation:

• New agent publications are blocked
• Agent executions may fail
• Admins must either:
  • Pull from tenant-level unassigned capacity
  • Or burst into PAYG

Proactive monitoring and enabling PAYG as a safety net is critical.

E. Agent-Level Message Limits (PPAC)

One of the most important new governance tools:

Admins can now set monthly consumption caps per agent:

• Soft guardrail: email warnings before hitting limit
• Hard guardrail: auto-disable agent upon reaching limit
• Per-agent status (within limit / near limit / over limit)
• Ability to manually turn an agent off

This directly solves runaway consumption.

3. Forecast costs: The agent consumption estimator

Forecasting is finally first-class.

The Copilot Studio Agent Consumption Estimator enables teams to:

• Estimate monthly credit volume
• Model usage trends based on:
  • User population & interaction frequency
  • Orchestration mode (Generative vs Classic)
  • % of knowledge-based vs task flows
  • External triggers and automation
  • Use of Prompt Tools
• Compare licensing models (PAYG, prepaid packs, M365 Copilot licenses)

Accessible via:

• PPAC Licensing Hub
• Copilot Studio homepage
• Marketing site
• here

This tool should become part of every agent governance process.

Solution path: Microsoft´s current cost-control mechanisms

Now that we do understand the pillars, let´s taka a closer look into building a practical, enterprise‑ready view of the actual mechanisms available across Copilot Studio, Microsoft 365 Copilot, Power Platform, and the emerging Agent 365 ecosystem. Each solves a different part of the problem.

1. Microsoft 365 Copilot Billing Policies (PAYG, Department- OR agent-level)

Best for: Native chargeback & departmental governance

Billing Policies let admins:

• Map security groups → Azure subscription/resource group
• Set department budget limits
• Assign PAYG access only to selected user groups
• Track message consumption per department
• Enforce alerts and spending guardrails

This is the cleanest chargeback model Microsoft offers today, but applies only to M365 Copilot Chat, SharePoint Agents, and other M365 Copilot agent surfaces – not Copilot Studio standalone agents.

However, recent updates also introduced:

• Agent‑level billing policy assignment (governance per agent)
• Agent usage analytics (licensed vs. unlicensed usage)
• High‑usage alerts for heavy consumers
• Improved agent control via Agent 365 capabilities

2. Copilot prepaid credit capacity packs

Best for: Predictable, isolated departmental budgets

Copilot Credit capacity packs are offered through the Copilot Studio subscription license. Copilot
Credit capacity packs should be purchased for the anticipated number of Copilot Credits your
tenant is expected to consume each month. Unused credits do not roll over to the next month.

Packs can be allocated to specific environments.

This gives:

• Strong budget isolation
• No inter‑department “spillover”
• Easy reallocation across environments
• Zero risk of unwanted cross‑charging

If Marketing gets 50,000 credits capacity, HR cannot consume them – even if HR runs out.

This is essential for predictable budgets and chargeback.

3. Power Platform PAYG (Environment-level)

Best for: Scalable consumption with clear billing boundaries

With environment‑level billing plans:

• Each environment connects to a specific Azure subscription + resource group.
• All usage in that environment is billed to that subscription.
• Admins can track consumption via Azure Cost Management.
• Alerts, budgets, tags, and RBAC can be applied at the subscription/RG level.

What it doesn’t do:

• No per‑user or per‑department separation
• No per‑agent billing split (yet)

But it’s the foundational billing boundary for Copilot Studio..

4. Agent-level credit capacity limits

Best for: Preventing runaway consumption and enforcing governance

The new agent‑level limit feature gives admins:

• Monthly consumption caps for individual agents
• Soft guardrail (notifications)
• Hard guardrail (agent auto‑disable)
• Visibility into usage per agent per environment
• Alerts when approaching limits

This directly solves the classic “single agent consumes the entire pool” problem.

5. Azure Cost Management & Budgets

Best for: Protecting enterprise‑wide budgets

Azure Cost Management allows:

• Spend alerts
• Budget limits
• Automated actions
• Meter‑level tracking
• Cross‑subscription views

This does not split costs by department – but is critical for financial governance and protection.

6. Dataverse usage logging (via a custom table)

Best for: DIY granular departmental chargeback

Create a custom table (e.g., cs_AgentUsage) storing:

• User
• Cost center
• Agent
• Message estimate
• Timestamp
• Scenario metadata

This becomes your internal ledger for cost attribution.

It is the only way to achieve true, granular departmental chargeback for Copilot Studio today.

7. Entra ID (Azure AD) attributes: Department & cost center

Best for: Automating attribution logic

Entra ID attributes enable automatic mapping:

• User → Department
• User → Cost Center
• User → Business Unit

Combined with usage logs or agent telemetry, this gives you frictionless, zero‑touch attribution.

8. Tenant‑Wide agent inventory (Power Platform Admin Center)

Best for: Governance & shadow agent detection

The new tenant‑wide agent inventory provides:

• A complete list of all agents
• Ownership metadata
• Environment & region
• Status and usage patterns

While not a billing tool, it’s critical for:

• Determining who should pay for an agent
• Detecting “hidden” agents
• Centralizing governance

Use it as your metadata catalog for joining cost and usage data.

9. Microsoft Agent 365

Best for: Long‑term unified agent governance (not billing)

Agent 365 introduces:

• Entra Agent ID (first‑class identity for every agent)
• Unified registry across M365, Copilot Studio, and custom agents
• Observability hooks
• Security & compliance integration
• Lifecycle management

While not a chargeback engine – yet – Agent 365 provides:

• A consistent identity to join cost data
• A unified catalog
• A cross‑platform governance layer

It is the strategic control plane for enterprise AI agents. Agent 365 is not the chargeback solution – but it is the strategic backbone for building one.

10. Planning & Forecasting

Microsoft recently introduced the Copilot Studio Agent Consumption Estimator.

It helps estimate:

• Monthly credit volume
• Effects of features (flows, triggers, knowledge, prompt tools)
• Internal vs external users
• Licensed vs unlicensed users
• Generative vs classic orchestration

It’s not a pricing calculator – but it gives Finance and IT a reliable forecasting baseline.

Comparison Tables

Let´s take a look on above shared insights consolidated in a comparison table:

M365 Copilot vs Copilot Studio vs Agent 365

A practical Enterprise chargeback framework

Additional thoughts: One production environment hosting many agents

Most enterprises don’t want one environment per agent. They want:

• A dedicated Production environment
• Hosting dozens of Copilot Studio agents
• Serving multiple departments
• With shared connectors, shared governance, and shared data policies

This is the real world – and it introduces new layers of complexity. Tenant‑Wide agent inventory and Agent 365 become essential here.

Guidance for multi‑agent production environments

Based on today´s capabilities, a robust enterprise-ready model looks like this:

1. Distinguish deployment surfaces
   • M365 surfaces → use Billing Policies
   • External deployments → use PPAC environments
     
2. Allocate prepaid packs to departments
   • Predictable budgets with strict isolation.
     
3. Enable PAYG as a fallback for each environment
   • Avoid outages when hitting prepaid limits.
     
4. Enforce agent-level consumption limits
   • Protect shared capacity pools.
     
5. Log actual usage to Dataverse for internal chargeback
   • Join with Entra attributes for cost-center attribution.
     
6. Provide Finance with monthly reporting
   • Use M365 Consumption Reports + PPAC consumption analytics.
     
7. Forecast proactively using the Agent Estimator
   • Supports budgeting, governance boards, and internal approvals.

Conclusion: The enterprise chargeback framework

AI agents are rapidly becoming core to business processes. Without a strategy, shared agents become a financial black box.

The good news:
Microsoft now provides end-to-end cost management capabilities across both admin centers–and a roadmap that makes cost attribution increasingly precise.

For Microsoft 365 Copilot PAYG
Use Billing Policies for native cost‑center attribution.

For Copilot Studio (single or multi‑agent environments)
Use Azure Budgets to protect total spend, Dataverse logging for attribution, Entra ID for cost center mapping, Managed Environments for governance, and Agent Limits as safety valves.

For multi‑agent production environments
Use Tenant‑Wide agent inventory to understand ownership and scope, and Agent 365 as the strategic control plane for identity, governance, and future cost alignment.

This is the model that aligns Finance, IT, and the business – and ensures your AI strategy scales sustainably.

With the layered approach above, organizations can deliver:

• Transparent consumption
• Predictable budgeting
• Fair chargeback
• Strong governance

Agent 365 will unify this further with consistent agent identity, observability, and governance across the ecosystem–but today, the tools to build a cost-transparent agent strategy already exist they just need to become orchestrated to fit your strategy. Until then,…

The enterprise is crossing a threshold unlike any it has faced before.
For decades, technology entered the organization as a set of tools – systems to automate tasks, store data, and streamline workflows. But the arrival of AI as a learning system has changed the nature of work itself. It has introduced something fundamentally new into the enterprise:
a workforce of agents that learn, adapt, and act alongside us.

This shift is not theoretical. It is already unfolding across every industry. Right now.

Satya Nadella described it as the moment when AI stops being a tool and becomes a team – researchers, analysts, creators, developers, and decision‑making councils of models working in parallel during his recent AI Tour keynote. Satish Thomas showed how business applications are transforming from passive systems of record into agentic systems of action, where intelligence flows across finance, supply chain, sales, service, and operations during his keynote at recent Convergence. Judson Althoff calls this the hallmark of the frontier firm – organizations that put AI in the flow of human ambition, empower every employee to innovate, and reshape processes from the ground up during his keynote at Ignite. Ryan Cunningham reminds us that the magic‑wand moment is not transformation. The real barrier is the operating system of the company – the humans, the software, the processes, the decades of decisions that created today’s fragmented landscape. And Charles Lamanna brings the final piece into focus: with billions of agents emerging across the enterprise, we need a new control plane to govern, secure, and orchestrate them at scale.

Together, these perspectives reveal a profound truth:

• AI transformation is no longer about deploying technology.
• It is about redesigning the enterprise for a world where intelligence is everywhere.

Agents will not sit at the edges of the business. They will live inside every workflow, every decision, every customer interaction, every operational process. They will be created by developers, analysts, domain experts, and frontline and backoffice employees. They will reason over the organization’s data, collaborate with each other, and act with increasing autonomy.

Charles describes agents as the connective tissue between intelligence and execution.

They link AI to tools, APIs, data, and organizational knowledge — and they operate autonomously inside critical processes. They run continuously, escalate to people when needed, and deliver outcomes at a pace no human‑only workflow can match. In many organizations, agents are already becoming a dependable layer of the enterprise, shaping how work gets done and how leaders lead.

And with this new capability comes a new responsibility. So customers asking how an action framework could look like for them. The answer?

A closer look into nature could bring us some insights on how to approach these new challenges.

• Caterpillars transform into butterflies through a process called metamorphosis, which allows them togrow, reproduce, and adapt to their environment.
• Monkeys learned to use a tool. Other monkeys learn from it by copying successful patterns.
• Ants collaborate as a team to cross the impossible.
• Bees tend to their hives, ensuring growth and success in a protected and controlled environment.

The enterprise must now answer questions it has never faced before:

• How do we govern a workforce of digital agents
• How do we ensure they act safely, ethically, and in alignment with business goals
• How do we observe, secure, and optimize intelligence that is distributed across every system
• How do we design processes for learning systems rather than static ones
• How do we turn ubiquitous intelligence into competitive advantage

What follows should become the operating model for the AI‑first enterprise – a blueprint for how organizations can structure their data, orchestrate intelligence, govern agents, and build the conditions under which human ambition and machine capability reinforce each other. Need a little guidance? Here´s a more detailed strategy paper that helps you get started.

Because the organizations that lead in this new era will not be the ones that simply adopt AI.
They will be the ones that embrace the agentic enterprise, where intelligence is democratized, innovation is ubiquitous, and governance becomes the foundation for scale.

Upgrading the Operating System of the Enterprise

True transformation requires flipping the model: start with bold ambitions, assemble the right mix of humans and agents, and iterate rapidly on a platform that democratizes creation and collapses the distance between the person who feels the pain and the person who can fix it.

But even ambition and capability are not enough.

As Charles Lamanna made it clear during his speech at Ignite, the next era will be defined by scale.
By 2028, the world will run on more than a billion agents – built by developers, analysts, domain experts, and frontline employees.

This is why the enterprise now needs an agent control plane – a way to see every agent, understand what it touches, manage how it behaves, secure how it accesses data, and ensure it acts in alignment with business goals. Because intelligence without governance is chaos. And governance without intelligence is stagnation.

An operating system where:

• Intelligence is everywhere
• Agents are teammates
• Data becomes organizational IQ
• Every employee becomes a maker
• Every process becomes adaptive
• Every application becomes a system of action
• Every agent is governed, observable, and secure by design

How to turn AI Theory into practice in 2026

Every enterprise leader today feels the same tension: AI is advancing faster than any technology in history – yet meaningful transformation inside organizations remains painfully slow.

• We’ve all seen the magic‑wand moments.
• We’ve all watched demos that feel like science fiction.
• We’ve all run hackathons, brainstormed use cases, and experimented with copilots.

And yet, the real question remains:

How do we turn AI from impressive prototypes into a new operating system for the enterprise?

Watching recent talks from five leaders – Satya Nadella, Judson Althoff, Satish Thomas, Ryan Cunningham, and Charles Lamanna – offered a remarkably aligned answer. Each approached the problem from a different altitude, but together they revealed a clear, actionable blueprint for how organizations can move from theory to practice to reshape their business in 2026.

Start with the hard truth: Your current Operating System can’t get you there

Most AI projects fail not because the technology is weak – but because the enterprise is fragmented.

• Decades of SaaS sprawl
• Siloed data
• Human‑heavy processes
• Legacy workflows
• Governance models built for static systems

As Ryan Cunningham put it:

“The operating system of the company – the humans, the software, the processes – is what holds us back.”

Judson Althoff reinforced this with data:

“There’s never been a technology adopted faster than AI, but success rates remain low.”

Why?
Because organizations treat AI as a technology project, not a business transformation.

Practical takeaway:
Before you deploy another pilot, ask: What business constraint or ambition are we trying to change?
If you can’t answer that, you’re not ready to build.

Redefine the Enterprise: You’re becoming an agentic organization

Satya Nadella describes the shift bluntly:

“AI is no longer a tool. It is a team.”

Agents – digital workers that can perceive, reason, and act – are becoming embedded in every workflow. They take on roles:

• Researcher
• Analyst
• Creator
• Developer
• Decision‑making council

Satish Thomas extends this into the business application layer:

“Systems of record are becoming systems of action.”

CRM, ERP, HR, supply chain – all become agentic surfaces where intelligence initiates work, not just records it.

And Charles Lamanna brings the operational reality into focus:

„…agents are already moving into the workflows that matter most.“

Across finance, operations, supply chain, and customer support, agents are:

• Improving accuracy
• Reducing manual effort
• Accelerating cycle times
• Enhancing customer experience

They connect AI to tools, APIs, data, and organizational knowledge – and they operate autonomously inside critical processes. They escalate to people when needed, run continuously, and deliver outcomes at a speed and scale we’ve never seen before.

Practical takeaway:
Stop thinking about “adding AI” to your processes. Start thinking about which roles agents will play in your processes.

Build your Enterprise IQ: Intelligence is now your competitive advantage

Satya introduced the concept of the IQ layer:

• Work IQ – relationships between people, projects, files, communications
• Fabric IQ – operational + analytical data
• Foundry IQ – unstructured + structured search

Judson added the missing piece:

“We need to put the ‘I’ back in AI.”

Developers today “sip data through a thousand tiny straws.” Agents need context, relationships, and signals – not isolated datasets.

Charles reinforces this with operational clarity:

„agents must interoperate safely with your data, your apps, your communications, across Microsoft and partner ecosystems.“

Practical takeaway:
Your data governance is your agent governance. If your data is fragmented, your agents will be too.

Empower every process expert: Democratize creation

This is where theory becomes practice. Ryan explains that the old “citizen developer” model was built around limitations. AI collapses those limitations.

• Process experts become process builders
• Developers become accelerators and enablers
• Copilot, App Builder, Vibe, and Copilot Studio become the new productivity suite

Judson calls this ubiquitous innovation:

“There is a maker in every room of the house.”

Charles adds the scale dimension:

„agents will be built by everyone in your organization, not just developers.“

Practical takeaway:
If you want to upgrade every process, you must empower every process expert. This is no longer optional.

Govern the new workforce: Agents need a Control Plane

By 2028, IDC predicts 1.3 billion agents will be deployed. Charles Lamanna introduced the missing piece:
Agent 365 – the agent control plane.

It provides:

• A single agent registry
• Access control
• Usage and risk visibility
• Secure interop across apps, data, and clouds
• Threat detection and data loss prevention

This is the governance model for the agentic enterprise.

Practical takeaway:
You cannot scale what you cannot govern. Before you build agents, build the control plane.

Put it all together: How to turn theory into practice

Here’s the practical blueprint distilled from all five leaders:

Step 1 – Start with ambition, not ideas

Define the business outcome you want to change.
Then design the process around that ambition.

Step 2 – Identify the agent roles

Ask:

• What would a researcher do here
• What would an analyst do
• What would a coordinator do
• What would a creator do

Design the agentic workflow.

Step 3 – Build your enterprise IQ

Unify your data.
Connect your signals.
Establish Work IQ + Fabric IQ + Foundry IQ.

Step 4 – Empower the makers

Give process experts:

• Copilot
• App Builder
• Vibe.PowerApps
• Copilot Studio
• Dataverse

Let them build the first version.
Let developers harden and scale it.

Step 5 – Deploy the control plane

Use Agent 365 to:

• Register agents
• Govern access
• Monitor behavior
• Secure interactions
• Observe outcomes

Step 6 – Iterate like a frontier firm

Small loops.
Fast cycles.
Bold goals.
Continuous learning.

The bottom line: You’re not adopting AI – You’re upgrading your Operating System

The organizations that win in 2026 won’t be the ones that deploy the most AI pilots.
They’ll be the ones that:

• Redesign processes for learning systems
• Empower every employee to build
• Govern agents like a new workforce
• Treat intelligence as a core capability
• Operate with ambition, not caution

This is the moment to move from theory to practice. Not by adding AI to the enterprise – but by rebuilding the enterprise around AI. I look forward to assessing the responsibilities and outcomes that will be addressed in the upcoming discussions and events scheduled for early 2026. Until then, …

Wishing you joyful holidays with loved ones and a wonderful 2026.

The Scene:
The CIO and CISO of a large enterprise company returned from Microsoft Ignite, energized and a little unsettled. The keynote’s vision of an AI-first, agentic Power Platform is no longer a distant future – it’s here. They gather the Power Platform Governance team for a workshop, posing a single, provocative question:
“Are we agent-ready to become frontier with our Power Platform governance strategy?”

The Challenge: From Apps & workflows to Copilots and Autonomous Agents

The company’s Power Platform footprint is massive: hundreds of Power Apps, thousands of monthly active flows, and a culture of business-led innovation. But Ignite’s announcements – multi-agent orchestration, Copilot Studio, advanced pipelines – signal a new era. The CIO frames the challenge:

“We’ve mastered low-code at scale. But are we ready for agents that reason, plan, act, and learn? Can our governance keep up with the speed and autonomy of AI-driven automation?”

We thought we were fine. Ignite proved otherwise. The governance and security team walked into the room confident.

• They had a solid zone model.
• They had ALM with pipelines.
• They had connector policies, DLP, and Dataverse carefully fenced.

Then the CIO and CISO came back from Microsoft Ignite. They had spent two days in sessions about AI agents, multi‑agent orchestration, CUA, MCP, and the idea of “human‑led, agent‑operated” enterprises. On the flight home, one question kept coming up between them:

“Our Power Platform is governed for apps and flows. But is it governed for agents?”

By Monday morning, that question had become a mandate:
Run a workshop. Review our governance and environment strategy. Show us how we will handle agentic AI.

The Debate: Governance in the Agentic AI Era

The room buzzes with debate. The CISO raises concerns about risk boundaries and compliance, especially with the EU AI Act’s new requirements for agentic systems. The governance lead points to the four foundational pillars

Managed Security, Managed Governance, Managed Operations, and Managed Availability

as the backbone, but acknowledges that agentic AI stretches every boundary

The CIO & CISO’s challenge: are we agent‑ready?

The brief for the workshop was simple and brutal:

• Don’t just show us our current state.
• Show us what has to change to safely adopt multi‑agents, CUA, MCP, and agent‑to‑agent (A2A) patterns.
• Align it with the Managed Platform capabilities we just saw at Ignite.
• And don’t come back with an academic vision; come back with something we can actually enforce in the Power Platform Admin Center.

The governance, security, and platform team did what most mature organizations do first: they pulled out their existing Power Platform governance deck.

On paper, it looked good:

• Environment zones from personal to mission‑critical
• ALM enforcement via Power Platform Pipelines
• Advanced connector policies and DLP
• Dataverse as system of record in enterprise environments
• Monitoring, analytics, and audit logs

The CIO looked at it, nodded, and asked a single question:

“Where, in this entire model, do we govern agents?”

Silence.

Inside the workshop: Discovering the blind spot

We started the workshop by mapping out what had changed since this governance model was first written.

Key topics ignite intense discussion:

Multi-Agent Orchestration:
The architects are excited about multi-agent systems (MAS) for complex workflows, but the CISO warns: “Without clear escalation boundaries and telemetry, MAS could become a black box.” The group agrees on the need for transparent agent-to-agent (A2A) protocols, auditable logs, and strict depth limits on delegation.

Zone-Based Governance:
How do we segment environments so that high-risk agents never run in low-governance zones? The team maps workloads to the new zone model – personal, innovation, team, departmental, and enterprise/mission-critical – debating where agents should live and how to enforce connector policies at scale.

Agent Evaluation and Lifecycle:
With Copilot Studio, anyone can build an agent. But how do we ensure every agent is evaluated for safety, compliance, and business alignment before deployment? The team explores embedding agent evaluation gates into Power Platform Pipelines, leveraging new Ignite features for multi-stage approvals and automated quality checks.

Memory and Knowledge Governance:
Agent memory is powerful – enabling agents to learn and personalize – but risky if not governed. The team debates retention policies, auditability, and the importance of grounding agents in validated, up-to-date knowledge sources.

Compliance and the EU AI Act:
The compliance officer outlines how Microsoft Purview and Compliance Manager can be used to assess agentic systems, classify risk, and document controls. The group commits to integrating continuous compliance monitoring into their pipelines.

From Ignite and the latest product updates, we listed the new realities:

• Agents can be multi‑agent systems, not just single copilots.
• Agents can call other agents using A2A.
• Agents can use CUA as a tool to drive UI automation across apps.
• Agents can invoke MCP tools to talk to external systems.
• Agents can hold memory over time.
• Agents can make decisions, not just respond.

Then we overlaid this on our current governance model and asked:

• Where do we define which agents are allowed to call which other agents?
• Where do we govern CUA usage as a tool with risk comparable to RPA or privileged automation?
• Where do we treat MCP endpoints as governed, versioned connectors instead of ad‑hoc integrations?
• Where do we set policies for what agents are allowed to remember – and for how long?
• Where in ALM do we evaluate agents, not just deploy them?

The answer was uncomfortable:
We didn’t. Not explicitly.

We had governed platform primitives (environments, connectors, solutions) but not agentic behavior. Ignite had just made that gap impossible to ignore.

Agents are not just apps with better prompts

The turning point in the workshop came when someone from security said:

“We’re still talking about agents like fancy apps. But the Ignite message is clear: Agents are digital workers.”

That one line shifted the conversation.

If agents are digital workers, then:

• Environment = where they’re allowed to work
• Connectors & tools (including CUA & MCP) = what they’re allowed to use
• A2A = who they’re allowed to delegate to
• Memory = what they’re allowed to remember
• Pipelines & ALM = how they’re hired, promoted, or retired
• Telemetry & KPIs = how we know if they’re performing or causing harm

Suddenly, our existing model looked incomplete, not wrong.

We didn’t need to throw it away. We needed to extend it to treat agents as first‑class citizens.

Five uncomfortable questions we had to answer in the room

To move from theory to action, we forced ourselves through five uncomfortable questions:

1. Zone strategy:
   In which zones are agents even allowed – and under what conditions?
   Is Zone 0 (personal dev) allowed to host agents, or is that restricted to sandbox and above?
   
2. Multi‑agent & A2A:
   What guardrails do we set for agents calling other agents?
   Do we allow high‑risk agents to call low‑risk agents?
   Do we define depth limits for delegation chains?
   
3. CUA as a tool:
   Do we treat CUA like just another capability, or like a privileged automation tool with stricter oversight?
   How do we monitor and restrict CUA‑driven UI actions?
   
4. MCP governance:
   Who owns MCP endpoints?
   How are they versioned, tested, and deployed?
   Are they treated like managed connectors, or like custom plugins we must deeply review?
   
5. Agent memory & lifecycle:
   What is the retention policy for agent memory?
   Who approves it?
   How do we evaluate agents before they reach production – and how do we roll them back if they drift?

By the time we’d argued through those five, it was clear: we needed an agent‑ready governance model.

How we rebuilt the governance model in one workshop day

We didn’t start from scratch. We started from strength.

The company already had:

• A zone‑based environment strategy
• Admin Center–only governance
• Pipelines and solutions for ALM
• Connector policies and DLP
• Clear RACI between IT, security, and makers

Our task was to upgrade this model to speak the language of agents.

The Breakthrough: New Features, New Mindset

As the workshop progresses, the mood shifts from anxiety to action. The team identifies quick wins:

• Embed Telemetry and KPI Alignment to measure agent impact and detect drift in real time.
• Adopt Environment Groups and Rules to standardize governance across all environments.
• Implement Advanced Connector Policies for action-level control, especially for agents and flows.
• Leverage Ignite’s Enhanced Pipelines for automated ALM, agent evaluation, and deployment gates.
• Establish an Enterprise Agent Catalog to track, approve, and reuse agents and skills.

We made five deliberate moves.

1. We refreshed the zone model through an “agent lens”

We kept the familiar zones, but explicitly defined what agents are allowed to do in each:

Zone 0 – Personal / Playground

• No sensitive production data
• No persistent memory
• No multi‑agent chains
• CUA disabled

Zone I – Innovation / Hackathon

• Sandboxed agents only
• Synthetic or masked data
• Multi‑agent allowed, but with strict depth limits
• Clear time‑boxing and auto‑cleanup

Zone 1 – Team / Sandbox

• Early departmental agents
• Limited A2A (within same owner/team)
• Memory allowed, but non‑sensitive and short‑lived

Zone 2 – Departmental / LOB

• Scoped agents tied to documented workflows
• Multi‑agent and A2A allowed with governance
• MCP and CUA allowed under policy
• Mandatory ALM via pipelines

Zone 3 – Enterprise / Mission‑Critical

• Fully governed, high‑impact agents
• Strict A2A and tool whitelisting
• Full telemetry, SIEM integration, and safety evaluation
• Clear rollback and retirement paths

We wrote these rules down as environment group rules and policies the Admin Center can enforce.

2. We brought multi‑agent orchestration and A2A under governance

Ignite made it clear that multi‑agent systems and A2A are not edge cases – they’re the future.

We defined:

• Which roles of agents may call which other roles (e.g., “research” agents can call “summarizer” agents, but not “approval” agents).
• A2A trust boundaries, so an agent can never use another agent to side‑step connector policies or data boundaries.
• Lifecycle alignment, ensuring any agent in an A2A chain is versioned and deployed via the same pipeline set.
• Observability, including logging agent‑to‑agent calls to detect loops, abuse, or unexpected patterns.

Suddenly, multi‑agents stopped being scary “black box swarms” and became just another governed pattern in the platform.

3. We treated CUA as a privileged tool, not a toy

CUA was one of the biggest wake‑up calls. Used well, CUA is an incredible accelerator. Used badly, it’s a compliance incident waiting to happen.

We positioned CUA as:

• A high‑risk tool whose usage is allowed only in specific zones and environments.
• Subject to the same scrutiny as high‑privilege automation (think RPA against critical systems).
• Observable: CUA‑driven actions must be logged and attributable.

In practice, that meant:

• CUA is disabled by default in lower‑risk zones, enabled selectively in higher‑governed ones.
• Any agent using CUA must pass stricter pre‑production evaluation.
• CUA usage is part of the security and AI Red Team review.

4. We put MCP on the same footing as connectors

The team realized something important: If MCP is how agents talk to external systems, then MCP is effectively a connector framework.

So we treated MCP as such:

• MCP servers must be registered, owned, and documented.
• MCP tools are versioned and deployed via solutions and pipelines.
• MCP endpoints are subject to the same review and approval as custom connectors.
• MCP is logged and monitored, so we can see what agents are doing with external tools.

This gives the company a way to adopt MCP with confidence instead of fear.

5. We extended ALM to include agent evaluation, memory, and retirement

Finally, we acknowledged the obvious: Our ALM model was great at shipping solutions. It was silent on evaluating agent behavior.

We fixed that.

The updated ALM model now requires:

• Pre‑prod evaluation for any agent touching business‑critical workflows:
  • Safety testing, prompt injection tests, tool misuse checks.
• A clear owner signing off on acceptable risk.
• Memory governance:
  • What agents are allowed to remember.
• How long they retain it.
• How to reset or wipe memory when policies or context change.
• Retirement and rollback:
  • Agents must be designed with a lifecycle.
• There must be a clear, pipeline‑driven rollback path.
• Deprecated agents must be removed from catalogs and A2A chains.

This turned agents from “just another artifact” into living systems with a managed lifecycle.

The CIO closes with a rallying call:

“Agent-readiness isn’t just about technology – it’s about mindset. We need to operate faster, more agile, and with relentless focus on governance. Let’s lead, not follow.”

The frontier firm test: Where we landed on the Agent readiness spectrum

At the end of the workshop, we overlaid our new model on the Agent Readiness Framework across its five pillars:

• Business & AI Strategy:
  Clearer linkage between zones, agents, and business‑critical workflows.
• Business Process Mapping:
  Agents tied to documented workflows, KPIs, and success metrics, not just “let’s see what it does.”
• Technology & Data:
  MCP, CUA, A2A, and multi‑agent orchestration all brought under the same platform governance umbrella.
• Organizational Readiness & Culture:
  Updated RACI, clear ownership, and a shared language between IT, security, and business around “digital workers.”
• Security & Governance:
  Agent evaluation, memory governance, A2A controls, and telemetry now considered non‑negotiable.

The CIO’s verdict at the end was simple:

“We’re not a frontier firm yet. But for the first time, I can see the path there – and it’s built on the platform we already have.”

Conclusion: The Spirit of the Workshop

This workshop wasn’t just a technical deep-dive – it was a cultural inflection point. The debates were intense, the stakes high, but the outcome clear: Agentic AI is here, and governance must evolve.
With the right strategy – zone-based governance, advanced pipelines, continuous compliance, and a culture of transparency – this enterprise is not just agent-ready. It’s frontier.

What your governance and security team should do next

If you recognize yourself in this story – solid Power Platform governance, but no explicit answer for agents – you don’t need to start from zero.

You can:

1. Run your own workshop with the same central question:
   “Where, in our current model, do we explicitly govern agents?”
2. Overlay the Agent Readiness Framework on your existing governance to find gaps across strategy, processes, tech, culture, and governance.
3. Extend your existing model, don’t replace it:
   • Add an “agent lens” to your zone strategy.
   • Bring multi‑agent, A2A, CUA, MCP, and memory into scope.
   • Evolve ALM from “deploy solutions” to “evaluate, monitor, and retire agents.”
   • Improve experience by implementing latest capabilities.
4. Anchor everything in Admin Center capabilities so policies are enforceable, not just aspirational.

Because in an AI‑first world, the question isn’t whether you’re using agents. It’s whether you’re ready to govern them like the digital workforce they’re becoming.

Hope, you like´d my short little story about a workshop with an enterprise customer – aiming to become frontier and review their strategy for it. Until then,…

But the story is changing. Not because low‑code failed, but because it has been absorbed into something bigger. The canvas hasn’t disappeared — it has simply faded into the background, becoming the invisible infrastructure that now powers an AI‑first era.

Competitive Landscape: Agentforce, and Niche Innovators

As Microsoft Power Platform pivots toward an AI-first future with its 2025 Wave 2 Plan, the competitive landscape is heating up. Rivals—both established and emerging—are rapidly evolving their strategies to capitalize on the shift toward agentic automation, conversational app creation, and “vibe coding.

Salesforce has rebranded and reimagined its AI strategy with Agentforce, a full-fledged agentic platform designed to bring autonomous digital labor to every business process. Agentforce is not just a CRM enhancement—it’s a strategic bid to redefine enterprise automation. By integrating deeply with Slack, Data Cloud, and vertical-specific workflows, Salesforce is positioning Agentforce as the go-to platform for intelligent agents that can plan, execute, and optimize tasks across departments.

Startups like Lovable and open-source platforms like n8n are redefining what it means to build software. Lovable’s chat-based app builder lets users create full-stack applications by simply describing their needs, while n8n offers flexible, self-hostable workflow automation. These tools embody the “vibe coding” ethos—software creation driven by intuition, conversation, and AI assistance.

The Canvas Fades, the Fabric Emerges

The entry point is no longer a blank screen or a data grid. It’s a conversation.

With Copilot embedded across Power Apps, Power Automate, Power Pages, and Power BI, you don’t start by dragging controls. You start by describing intent: “Build me an app to track customer onboarding” or “Automate invoice approvals with escalation rules.”

Copilot scaffolds the solution. Low‑code remains — but it’s the refinement layer, the governance substrate, the runtime fabric. The toolkit hasn’t died; it’s been abstracted.

Agents as the New Workforce

The next leap is agentic AI.

Instead of humans manually wiring flows, AI agents orchestrate across systems, monitor events, and take action. They draft contracts, triage service cases, enrich leads, and coordinate across ERP and CRM.

And they don’t just assist — they act. With guardian patterns like pre‑flight checks, rollback, and audit logs, enterprises can safely grant autonomy where ROI is proven.

MCP: The Universal Connector

One of the biggest questions is legacy: “What about our systems of record?”

This is where the Model Context Protocol (MCP) comes in. Think of it as the USB‑C of AI connectivity. A universal standard that lets agents plug into any system — modern SaaS or decades‑old mainframe — through a consistent interface.

With MCP, Power Platform becomes not just a toolkit, but the operating fabric of enterprise AI.

Multi-Model: The Next Big Leap in AI for Work

The future of AI in the workplace isn’t about a single model—it’s about choice and flexibility. Multi-model capabilities are emerging as the next big thing, empowering organizations to select the right model for the right task. This approach recognizes that no single model can excel at everything. Some models are optimized for reasoning, others for creativity, and others for speed and cost efficiency.

By enabling multiple models within Microsoft 365 Copilot & Copilot Studio, businesses gain:

• Flexibility: Choose models tailored to specific workflows—whether drafting content, analyzing data, or generating code.
• Resilience: Reduce dependency on a single provider and ensure continuity even as technology evolves.
• Innovation: Leverage specialized models for unique industry needs, unlocking new possibilities for productivity and creativity.

This multi-model strategy isn’t just a technical upgrade—it’s a paradigm shift. It puts control in the hands of organizations, allowing them to align AI capabilities with their goals, compliance requirements, and budget. In short, multi-model is the foundation for a more adaptable, intelligent, and future-ready workplace.

Governance and Sovereignty: The Differentiator

Speed without trust is a dead end. Especially for EU‑based enterprises, the Data Act and sovereignty concerns are real.

Microsoft’s approach addresses this head‑on:

• EU data residency in Dataverse.
• Customer‑managed keys and Lockbox‑style access approvals.
• Sovereign cloud options for restricted workloads.

The message: you don’t have to choose between moving fast and staying compliant.

Platform Evolution Timeline

• 2023: Low-code platforms dominate (Power Apps, AppSheet, Honeycode, Salesforce Flow).
• 2024: Agentic AI emerges (Agentforce, Copilot agents, Duet AI, SnapLogic Agent Creator).
• 2025: Vibe coding and open automation surge (Lovable, n8n, Bolt, Replit).
• 2026: Unified AI-first platforms (Power Platform Wave 1, Agentforce 3.0) become the new standard.

The New Reality

So here’s the truth: Power Platform is no longer just a low‑code toolkit. It has evolved into an AI‑first fabric where:

• Copilot is the new entry point.
• Agents are the new workforce.
• MCP is the universal connector.
• Governance is the trust layer.

This isn’t the end of low‑code. It’s the next chapter — one where low‑code becomes the invisible foundation for an AI‑first enterprise.

Closing Thought

The companies that cling to the old narrative of “low‑code democratization” will miss the bigger story. The ones that embrace Power Platform as an AI‑first operating fabric will become the Frontier Firms of the agentic era.

The canvas may fade, but the fabric is stronger than ever.

The airport evolution metaphor

As business demands evolved, passenger volumes and flight patterns outgrew the old gates. New planes caused your old runways to their maximum. You were forced to make a decision. Close the airport for an unpredictable time or start modernizing on the ground next door. Avoid major disruptions while working on the foundation is not an easy task – though signs have been clear: Modern AI workloads, agentic automation, and complex orchestration stretched capacity beyond its limits. The blueprint grid reveals runway queues and bustling tarmac—signs that a new aviation hub is needed.

Rather than halting operations, Power Platform expand in mid-flight. A second terminal rises alongside the legacy structure, seamlessly connected by the Hub: Power Platform. Transforming tools into invisible foundation of AI-first thought services. This new MCP-ready terminal accommodates AI tools and systems of record, ensuring smooth transitions for Copilot Studio, Agentic AI, and Agent Flows.

Until then,…

…you don’t get quiet agreement. You get sparks. And that’s exactly what happened recently in a workshop. I walked into the room knowing exactly what to expect: a group of seasoned RPA developers, a few API specialists, and the quiet skepticism that always surfaces when the conversation turns to AI-driven automation.

The Skeptics Speak Up

The RPA veterans were the first to challenge:

• “AI is too error-prone. Why would we replace stable bots with something that needs constant human babysitting?”
• “We’ve spent years hardening our automations. Why gamble on something that might hallucinate?”

Their concerns weren’t dismissive — they were grounded in experience. RPA has earned its place by thriving in stable, rule-based, legacy environments. Once trained, bots can run for years with minimal change. That reliability is hard to argue against.

We started taking a look at the following visual to see where things could get us started.

When presenting I said:

“Notice today is not about replacing RPA. We came together to protect your RPA investment, double down on the APIs transition to MCPs trend we discussed last time and discover possible piloting of CUA where gaps are identified.”

The API Counterpoint

Then the API developers weighed in after a while of talking about the initiatives currently taken care of in terms of „translating“ internal APIs into MCP Server and therefore simplify automation and integration in a future scope:

• “Instead of teaching an AI to click buttons, why not invest in turning our APIs into MCPs? That’s a cleaner, more scalable strategy.”
• “If APIs are the backbone, extending them into Copilot tools gives us long-term ROI without the unpredictability of AI-driven UI automation.”

They had a point. APIs are the cleanest integration path — fast, reliable, and low-maintenance. And MCPs (being used as Agentic AI Tools) represent a way to expose those APIs directly into Copilot agent experiences, effectively future-proofing the investment.

The room warmed up quickly, so I shifted the discussion to assess how familiar this audience was with RPA and API shifting. My goal was to encourage them to adopt a growth mindset and take a closer look at CUA.

The CUA Vision: Filling the Gaps

„This is where Microsoft’s CUA vision comes into focus. CUAs aren’t meant to replace RPA or APIs. They’re designed to fill the messy middle

• Dynamic, UI-heavy workflows where APIs don’t exist.
• Exception-rich processes where RPA breaks too easily.
• Customer-facing journeys where variability is the norm.

The insight is this: CUAs extend automation into territories that were previously “too messy” to touch. They don’t compete with APIs or RPA — they complement them.“

Above timeline presents analysts‘ predictions for the technology mix in automation by the end of 2030. The comparison below aims to provide a clearer understanding of these projections.

Lessons Learned

From the heated discussion, a few lessons crystallized:

1. RPA is still the workhorse. Protect it where it delivers ROI, especially in legacy systems.
2. APIs are the backbone. And yes, turning them into MCPs is a smart long-term play — it extends your value into the Copilot ecosystem.
3. CUAs are the frontier. They unlock automation in places neither RPA nor APIs can reach.
4. The future is orchestration. The winners won’t be those who pick one tool, but those who master the hybrid stack: RPA + APIs + CUAs.

Closing Reflection

By the end of the workshop, the skeptics weren’t fully convinced — but they weren’t dismissive either. The RPA developers began to see CUAs not as a threat, but as a way to tackle the “ugly processes” they’ve always avoided. The API specialists recognized that MCPs and CUAs aren’t competing strategies, but parallel ones: MCPs strengthen the backbone, CUAs expand the frontier.

The overall lesson? Automation isn’t a zero-sum game. It’s a portfolio. And Microsoft’s CUA vision isn’t about replacing what works — it’s about expanding what’s possible. Until then,…

A game‑changing moment in the boardroom

“Don’t fund another isolated AI project. Rebuild your business as an intelligent‑apps platform.”

At a recent C‑level leadership summit, one Microsoft executive reframed the AI conversation with a deceptively simple challenge:

It was a sharp pivot from the endless cycle of “yet another Copilot” to a bold vision for deploying a digital workforce at scale. The idea wasn’t to sprinkle chatbots into workflows, but to modernize the entire software estate so every application becomes smarter, more adaptive, and more valuable over time.

From 10% optimisation to 10x transformation

What stood out was the insistence on scale economics: when intelligent capabilities are designed once, reused everywhere, and governed centrally, their value compounds. That is the difference between a 10% incremental improvement and a 10x leap in enterprise performance.

• From pilots to portfolios — Shift from experimenting in silos to operating a platform of reusable capabilities.
• From automation to orchestration — Move beyond individual task automation into AI‑led processes that coordinate people, systems, and decisions in real time.
• From speed to scale — Balance the rapid build capabilities of the Power Platform with the governance and lifecycle rigour of Azure AI Foundry.

The intelligent‑apps stack

Microsoft’s approach unites key pillars:

Why this resonates at the C‑suite level

The business cases cut across sectors:

• Customer operations: Containment rates rise, handle times drop, customer satisfaction surges.
• Finance & compliance: Days‑to‑close shrink while audit exceptions decline.
• Supply chain: Exceptions are resolved faster with fewer expedite costs.
• Field service: First‑time fix rates improve, cutting downtime and costs.

For each, Microsoft advocates measuring outcomes with KPIs that matter to boards and investors — not vanity metrics.

The operating model shift — Frontier Firm vs. Intelligent-apps fabric

Technology is only half the story. This approach demands:

• Fusion teams that blend domain expertise with platform mastery.
• Shared guardrails — prompt libraries, data connectors, safety policies.
• Safe iteration in production with telemetry and rollback paths.
• Relentless measurement via the Business Value Toolkit to prove ROI.

If you hold the Intelligent‑Apps Fabric vision we’ve been shaping up against Microsoft’s Frontier Firm perspective, the through‑line is striking — they’re essentially two lenses on the same strategic shift, but aimed at different altitudes of the conversation.

From the Frontier Firm guide, the core idea is that the next generation of market leaders will:

• Put AI at the operational core — not as a bolt‑on, but as the engine that runs decision‑making, execution, and adaptation.
• Scale digital labor — moving beyond isolated automation to a workforce model where AI agents and human talent are orchestrated together.
• Continuously reimagine work — treating processes, roles, and even business models as fluid, evolving assets.

When you map that to the intelligent‑apps narrative:

My takeaway: the Frontier Firm vision is the why — a macro‑level call to action for CEOs to re‑architect their companies around AI‑driven operating models. The intelligent‑apps framework is the how — a concrete, technology‑anchored playbook for making that shift real, with specific tools, governance patterns, and business cases.

Why the timing is critical

With budget planning underway, CFOs and CEOs face a choice:
Fund “safe” point solutions that will be obsolete in two years, or invest in a platform that compounds value across the enterprise.

The message from this summit was clear: Incrementalism is the risk. Platforms are the opportunity.

Key questions for leaders before approving the next transformation budget

1. Are we funding another project, or are we investing in a platform?
2. Can our apps and workflows adapt in production — or are they frozen the day they go live?
3. Do we have the governance model to scale AI safely across our business?
4. What’s our 10x scenario — and how soon can we prove it?

Final word: The organisations that will lead in the 2030s are already building their intelligent‑apps fabric today. They’re not chasing the latest AI tool; they’re industrialising intelligence as a core business capability. The only question is whether you’ll be one of them. Until then,…

The room was full. A handful of Power Platform CoE leads, a couple of makers who had built scrappy Copilot Studio prototypes, and the CIO—arms folded, curious but cautious. “We’ve got demos,” he said, “but I don’t have something I’m ready to bet the business on.” That was the moment to introduce the missing piece: a Red Team for AI agents—not as bureaucracy, but as the engine that converts promise into production.

Inside the workshop

We started with what they’d already done: a few Copilot Studio agents answering internal FAQs and sketching data lookups. Demos that looked great in a controlled setting, but brittle in the wild. The CoE was strong on governance and enablement; the gap was assurance. The question we explored together: how do we prevent being another PoC that never scales, and instead build the muscle to launch agents users trust?

I drew three columns on the board—Risk, Readiness, ROI—and we mapped their agents against each. That’s where the Red Team clicked. It wasn’t “security theater.” It was the method to break things on purpose so they don’t break in production—and to prove business value with evidence, not optimism.

The Red Team, explained simply

A Red Team for Copilot Studio agents is a specialized assurance function that stress-tests agents before your customers do. It treats prompts, actions, and data like software—with CI/CD, tests, and release gates—and it brings adversarial thinking into your delivery flow.

• Core mission: Turn unknown risks into managed risks by hacking your own agents—prompt injection, tool misuse, data exfiltration, hallucinations under pressure—and then hardening them.
• Scope of work: Threat modeling: System prompts, grounding sources, actions/plugins, memory, and connectors.
• Adversarial testing: Jailbreaks, role confusion, refusal bypasses, and privacy attacks—automated in a repeatable harness.
• Safety controls: Content filters, PII redaction, DLP guardrails, purpose limitation.
• Reliability checks: Grounded answer rates, refusal accuracy, degradation behavior under load or outages.
• Action hardening: Least-privilege identities, parameter allowlists, approvals for destructive operations.
• Monitoring & response: Canaries, feature flags, kill-switches, and incident runbooks.
• What “good” looks like: Release gates wired to evals. If grounded accuracy drops or toxicity rises, the build fails. Canary releases catch regressions. Every fix becomes a reusable template or wrapper.

The CIO’s posture shifted. “So this is our safety net—and our speed booster.” Exactly.

Why it lives inside your Power Platform CoE

Putting the Red Team inside the CoE gives it reach and leverage: one intake, one standards library, one dashboard for risk and value. It stays independent on release decisions but deeply integrated with how makers build.

• Benefits of integration: Shared guardrails: DLP, environment strategy, and identity policies applied consistently to agents.
• Reusable assets: Hardened prompt patterns, action wrappers, test datasets, and pipelines available to every maker.
• Faster approvals: Evidence packs (threat model, eval results, rollback plans) streamline Legal/Compliance sign-off.
• Shift-left enablement: Office hours and templates reduce “mystery work” and prevent shadow IT patterns.
• Decision rights:
  • High‑risk agents: Red Team holds the release gate; business owners accept any residual risk explicitly.
  • Low/medium risk: Advisory sign-off with automated gates in CI/CD; no bottlenecking.
• Feedback loop: Findings feed directly into CoE standards so the whole platform gets safer.

This is how you scale governance without killing agility—and why projects stop dying after PoC.

Industry wins you can steal

Financial services (internal servicing copilot):

• Problem: Early agent could read/write sensitive customer data; trust and compliance concerns blocked rollout.

• Red Team findings: Prompt injection via case notes; overly broad action scopes.
• Fixes: Server-side sanitation, retrieval filters, least-privilege service accounts, and confirmation flows for high-impact actions.
• Outcome: Cleared compliance quickly; launched to a pilot group with zero data leakage incidents and rapid adoption by service reps who saved hours weekly on lookup and case prep.

Pharma R&D (SOP and trial assistant):

• Problem: Hallucinations when grounding faltered; auditors needed traceability.

• Red Team findings: Low-confidence answers without citations; fragile under multi-turn clarifications.
• Fixes: Mandatory citations with refusal on low-confidence, offline cache for critical SOPs, and multi-turn evals in CI.
• Outcome: Researchers trusted the agent; time-to-answer dropped; auditability improved, enabling broader rollout.

Manufacturing (maintenance work-order copilot):

• Problem: Risk of mass ticket creation from ambiguous prompts; fear of operational disruption.

• Red Team findings: Tool-abuse vectors; missing rate limits and guardrails.
• Fixes: Parameter allowlists, rate limiting, supervisor approvals for bulk actions, and context-echo confirmations.
• Outcome: No spurious work orders; meantime-to-repair improved as technicians adopted the agent confidently.

Each story shares a pattern: the Red Team uncovered a blocker that would have killed trust post-launch, converted it into a control, and documented evidence that unlocked executive approval and user adoption.

A 60‑day play you can run next Monday

You don’t need a big-bang program to get value. Start thin, automate fast, and prove the loop from “we broke it” to “we fixed it” to “we shipped it.”

Week 1–2

• Stand up the basics:
  • Charter: Define scope, risk tiers, and release gates for Copilot Studio agents.
• Harness: Create a small eval set—50–100 “gold” prompts plus refusal cases and a dozen adversarial attacks.
• Guardrails: Enable content filtering, PII redaction, and DLP; set least‑privilege identities for actions.

Week 3–4

• Wire into CI/CD:
  • Automation: Every prompt or action change triggers evals; block deploys on regression.
• Quick wins: Harden one high-impact agent (e.g., service knowledge, maintenance assistant) with action wrappers and confirmation flows.
• Evidence pack: Threat model, test results, telemetry and rollback plans—ready for compliance.

Week 5–8

• Prove scale and value:
  • Canary and monitor: 5–10% user rollout with live safety metrics and a kill-switch.
• Chaos drills: Simulate grounding outages and rate limiting; validate graceful degradation.
• Publish impact: Show grounded answer rate, refusal accuracy, incident rate, and hours saved by the pilot team; decommission a legacy workaround the agent replaces.
• What to measure:
  • Quality: Grounded answer rate, refusal accuracy, tool misuse rate.
• Risk: Policy violations prevented, critical incidents, time-to-rollback.
• Flow: Approval lead time, change failure rate, cycle time from idea to stable release.
• Value: Verified hours saved, error reduction, increased throughput or satisfaction.

Tip: Treat prompts and action configs like code. Version them, test them, and promote them through environments just like your best software projects.

The moment that sold the room

At the end, the CIO asked, “If we had this Red Team three months ago, would we be live?” The CoE lead answered before I could: “We’d have caught the exact issues that scared everyone—and we’d have the evidence to prove we were ready.” That’s the shift. From flashy demos to durable products. From fragile optimism to measured, repeatable wins.

If this resonates, start with one agent, one Red Team sprint, and one measurable outcome. I’m happy to help you tailor the harness, gates, and playbook—and to stand with your CoE when you make the case to leadership. Until then,…