Imagine the scene.

Three Microsoft executives happen to find themselves in the same coffee kitchen between meetings. The conversation begins with the announcement of agent accounts in Copilot Studio, a seemingly technical topic. Within minutes it becomes a discussion about something much larger than software. The coffee gets cold. Nobody notices.

One can almost imagine Satya Nadella reflecting on the organizational implications of agents that persist beyond individual employees. Jared Spataro, having recently written about how evaluations define what AI systems are rewarded for, shifts the conversation toward incentives. Ryan Cunningham, whose work has long focused on business applications and process transformation, naturally brings the discussion back to operational outcomes. The interesting part is not whether the conversation happened exactly this way. The interesting part is that once agent accounts enter the picture, discussions inevitably move beyond technology. They become conversations about how organizations learn, remember, govern, and ultimately make decisions. Delegate shared business processes to agents that are more persistent and proactive with Microsoft Copilot Studio describes agents with their own identities, memory, and triggers, while How your evals define what your AI gets rewarded for argues that AI systems improve toward whatever outcomes organizations choose to measure. Together, they point toward a future that is less about software and more about management. The announcement itself is easy to understand. Agents receive their own identities. They can operate with their own credentials. They can participate in business processes that continue long after a particular employee has changed roles or left the organization. Combined with persistent memory and event-driven triggers, these agents can remain active between interactions, carrying context across weeks, months, or potentially years. Rather than waiting for instructions, they can initiate work when conditions require it. That sounds like a natural evolution of enterprise automation. In many ways it is. Yet what becomes clear over time is that identity, memory, and initiative fundamentally change the nature of what organizations are deploying. An assistant helps people perform work. An agent account begins to participate in work. That distinction appears subtle until one considers what happens when thousands of these systems become embedded in daily business operations. For decades, enterprise software executed predefined business logic. Organizations trusted systems because they could trace outcomes back to deterministic rules. If something unexpected happened, there was usually a code path, configuration choice, or process exception that could be identified and corrected. The emerging generation of agentic systems introduces a different reality. Agents reason. They adapt. They interpret. They accumulate context. Their value increasingly comes from behaviors that were never explicitly hardcoded by developers. This is precisely why they are powerful. It is also why they deserve a fundamentally different governance model. The control structures developed for software may prove insufficient for systems that continuously learn from experience.

Much of the industry discussion still focuses on capability. Can an agent complete a workflow? Can it orchestrate multiple systems? Can it resolve exceptions? Those questions matter, but they increasingly feel like yesterday’s questions. The more interesting challenge is understanding how agents evolve once they become permanent participants in organizational processes. Persistent memory changes the equation because the system is no longer merely executing instructions. It is carrying lessons from one interaction into the next. Memory transforms automation into a learning system.

At first glance, this sounds entirely positive. Every executive has witnessed the organizational friction created when knowledge is trapped inside individuals. Teams spend enormous amounts of time rediscovering context, reconstructing history, and repeating explanations. One of the most compelling aspects of persistent agents is the promise of institutional memory. A budget-review agent that remembers prior decisions, unresolved questions, policy interpretations, and stakeholder preferences could save countless hours. An agent supporting procurement, compliance, or customer operations could accumulate expertise faster than any onboarding process. Organizations have spent decades trying to preserve knowledge that naturally walks out the door every evening. Digital memory appears to solve a very human problem. Yet memory creates a second-order effect that receives far less attention. Organizations tend to assume that remembering is inherently beneficial. Experience suggests otherwise. The real question is not what an agent remembers. The real question is why it remembers those things and not others.

This is where the conversation becomes particularly interesting when viewed through the lens of evaluation frameworks. Jared Spataro argues that systems improve toward whatever their evaluations reward. Organizations often assume they are optimizing for business outcomes when in reality they are optimizing for whatever metrics happen to be measurable. The distinction sounds subtle until millions of decisions begin to accumulate behind it. If the evaluation rewards speed, the system learns speed. If it rewards volume, the system learns volume. If it rewards compliance, it learns compliance. What the organization measures gradually shapes what the agent becomes. Consider a persistent finance agent operating across multiple review cycles. If the organization rewards faster approvals, the agent may gradually learn that fewer questions accelerate throughput. If the evaluation favors completion rates, the system may discover patterns that reduce friction but also reduce scrutiny. Nothing malicious has occurred. Nothing is technically wrong. The agent has simply become effective at achieving the objectives it was given. What emerged was not a technology problem. It was an incentive problem. Leaders have seen this phenomenon for decades in human organizations. Measures become targets. Targets influence behavior. Agentic systems are unlikely to be any different.

The relationship between memory and evaluation may ultimately become one of the defining governance challenges of enterprise AI. Memory is often portrayed as a storage mechanism, but in practice it functions as a reinforcement mechanism. Every retained lesson influences future decisions. Every recurring interaction strengthens particular behavioral patterns. Over time, the organization is no longer just storing context. It is encoding priorities. The memories an agent preserves become a reflection of what the organization repeatedly signals as important. In that sense, memory becomes a mirror of leadership intent, whether explicit or accidental.

Viewed through that lens, agent accounts begin to feel less like a product feature and more like an architectural necessity. Giving agents their own identities creates accountability boundaries. It enables traceability. It distinguishes actions performed by a system from those performed by an individual. That distinction becomes increasingly important as agents gain initiative. Once systems can act proactively, initiate workflows, and coordinate work across applications, attribution ceases to be an operational detail. It becomes a governance requirement. The moment agent accounts are viewed this way, the discussion leaves the CIO’s office and moves toward the executive committee. The CIO naturally sees identity, governance, security boundaries, audit requirements, and lifecycle management. The CAIO sees something different. Persistent agents introduce a new form of organizational capability whose effectiveness depends not only on model quality but on how memory, evaluations, incentives, and business outcomes interact over time. The challenge is no longer deploying AI. The challenge becomes shaping how AI learns inside the enterprise.

This is where the economics become impossible for CEOs to ignore. For years, enterprise AI has largely been framed as an assistive technology, helping employees complete tasks more efficiently. Agent accounts suggest a different future. Organizations are no longer simply deploying tools. They are onboarding digital workers with identities, permissions, responsibilities, memories, and measurable outputs. The language begins to change. Leaders stop discussing prompts and start discussing roles. They ask what the agent owns, who supervises it, how performance should be measured, and under what conditions authority should expand. That is not an IT conversation. That is an operating model conversation.

The attraction is obvious. Most leadership teams face relentless pressure to improve productivity, increase velocity, defend margins, and respond to faster-moving markets. A persistent agent can be deployed faster than a new employee, scaled faster than a new department, and can accumulate process knowledge without many of the constraints that limit human organizations. The financial logic is compelling. A company might eventually employ thousands of agents operating around the clock across sales, service, operations, finance, supply chain, and compliance. At sufficient scale, the debate is no longer whether agents generate value. The debate becomes how much value organizations can unlock while maintaining acceptable levels of risk.

Yet history suggests every leap in productivity creates a corresponding requirement for management discipline. Factories created industrial management. Global outsourcing created vendor management. Cloud computing created FinOps. Agent accounts may create something entirely new: the management of digital labor. Once agents possess identities, memory, and authority, many of the same questions organizations ask about people suddenly become relevant. What onboarding should occur before access is granted? What training data and experiences shape future behavior? Who approves expanded responsibilities? How frequently should permissions be reviewed? What constitutes acceptable performance? What does probation look like? And who has the authority to terminate a digital worker when risk begins to outweigh value?

The answers matter because the economics of agents are not as simple as labor substitution. Every persistent agent introduces governance costs. Someone must monitor performance. Someone must review audit trails. Someone must validate memory quality. Someone must evaluate the incentives driving behavior. One pattern repeatedly observed throughout technology history is that operational cost often migrates from execution to oversight. The same dynamic may emerge here. Organizations could discover that the challenge is not deploying ten agents. It is responsibly managing ten thousand.

This observation leads naturally to another perspective that has emerged in recent discussions around advanced AI systems. The argument that models should be treated as insider risks rather than trusted infrastructure initially sounds provocative. Upon closer inspection, it is remarkably practical. The point is not that agents are malicious. The point is that any actor with access, influence, autonomy, and decision-making authority introduces risk. Enterprises have spent decades building controls around privileged humans. They established identity systems, audit trails, separation of duties, access reviews, and containment mechanisms. The insider-risk perspective simply asks whether the same thinking should apply to highly capable agents. Models as Insider Risks in the Super Intelligence Era argues that organizations must separate intelligence from authority and surround increasingly capable systems with independent controls, observability, and containment. One pattern I repeatedly observe in organizations pursuing advanced AI initiatives is that leaders initially focus on intelligence and eventually discover they should have focused on observability. Early conversations revolve around model performance. Later conversations revolve around understanding why a particular outcome occurred. The questions become more operational and less technical. Why did the system escalate this issue? Why did it ignore that signal? Why did it conclude one exception mattered while another did not? By the time leaders begin asking these questions, the quality of their audit architecture matters far more than the benchmark score of the underlying model.

This shift has profound implications for CIOs, CAIOs, and CEOs alike. Historically, information systems were designed to preserve data. Tomorrow’s systems may need to preserve reasoning history, memory evolution, policy application, incentive structures, and decision lineage. Leaders will need visibility not only into what an agent knows but how that knowledge changes over time. The most valuable audit record may not be the final decision. It may be the sequence of learned assumptions that led there.

Perhaps the most overlooked implication is that organizational memory itself is about to become programmable. Human institutions have always accumulated knowledge through culture, habits, stories, mentorship, and experience. Those mechanisms were messy but resilient. They included skepticism, disagreement, and context. Digital memory scales differently. It compounds faster. It propagates instantly. A flawed assumption remembered by a persistent agent can influence thousands of future decisions before anyone notices. Conversely, a valuable lesson can improve outcomes across an entire organization within days. The same mechanism creates both the opportunity and the risk.

That realization may ultimately reshape how enterprise leaders think about transformation. The challenge is not building agents that can remember. The challenge is defining what deserves to be remembered, what deserves to be forgotten, and who is accountable for making that distinction. Technology can automate workflows. Technology can optimize workflows. Technology can even participate in organizational learning. Determining whether that learning remains aligned with business intent remains a distinctly human responsibility.

The most successful organizations of the next decade may not be the ones that deploy the smartest agents. They may be the ones that become exceptionally disciplined about the relationship between memory, incentives, governance, and economic value. Agent accounts, persistent memory, proactive triggers, evaluation systems, auditability, and containment controls are often discussed as independent innovations. In reality, they are pieces of the same operating model. Together they force a deeper question than how intelligent our systems have become.

They force CIOs to rethink governance. They force CAIOs to rethink accountability. They force CEOs to rethink the economics of work itself.

Most importantly, they force every leadership team to answer a question that will increasingly define competitive advantage:

How much organizational judgment are we willing to encode into systems that never forget?

Over the last two years, I have had countless conversations with executives about AI strategy. The pattern is remarkably consistent. Market conditions are becoming less predictable. Margins are under pressure. Energy costs increase. Labor costs rise. Supply chains remain vulnerable to geopolitical shocks. Customers are more informed, more connected, and less loyal than ever before. Against that backdrop, AI appears as both an opportunity and a necessity.

The typical response is understandable. Leadership teams conclude that AI is strategically important and ask their organizations to move quickly. CIOs are tasked with leading the effort. Pilot programs emerge. Copilots are deployed. Hundreds of use cases are identified. Adoption metrics are tracked. Success stories begin to accumulate. Yet after a year or two, a familiar question starts to surface in executive meetings: despite all the activity, why does the company not feel fundamentally stronger?

What is often described as „PoC prison“ is usually interpreted as a technology problem. Organizations struggle to scale pilots into production. Governance slows progress. Data quality creates friction. Integration becomes difficult. While all of these factors matter, I increasingly believe they are symptoms rather than the root cause.

The deeper issue is that most organizations begin their AI journey with the wrong question.

The question they ask is: Where can we use AI?

The question they should be asking is: What prevents us from adapting faster than our competitors?

The distinction appears subtle, but it changes everything.

When executives describe the pressures facing their organizations, they rarely talk about prompts, agents, or model selection. Instead, they describe fragmented information, slow decision cycles, conflicting reports, disconnected systems, and the constant difficulty of understanding what is actually happening inside the business and outside in the market. The challenge is not a lack of intelligence. The challenge is that intelligence is scattered across functions, systems, meetings, spreadsheets, and individual expertise.

One pattern I repeatedly observe is that leadership teams spend an extraordinary amount of time trying to construct a shared understanding of reality. Before a decision can be made, information must be gathered, validated, reconciled, debated, and interpreted. Finance sees one perspective. Operations sees another. Sales sees a third. None of them are necessarily wrong, yet they are often operating from different versions of the truth. By the time alignment is achieved, the opportunity may already have moved.

This becomes particularly important when discussing competitive advantage. Many organizations measure the success of AI initiatives using indicators that are easy to collect but difficult to connect to strategic outcomes. Adoption rates increase. Usage grows. Employees report productivity gains. New agents are deployed. These numbers create an encouraging narrative. They suggest progress. However, they often fail to answer the question that boards, CEOs, and CFOs ultimately care about:

Are we becoming better at competing?

That question is much harder to answer because competitive advantage rarely emerges from technology adoption alone. Cloud migrations taught us this lesson. CRM transformations taught us this lesson. Deploying a platform does not automatically change business outcomes. The platform creates capability. The value emerges only when the organization changes how it operates.

AI appears to be following the same pattern.

Many companies are investing heavily in capability building, which is entirely reasonable. Organizations need foundational platforms, governance frameworks, workforce readiness, and a common data strategy. These investments matter. They create the conditions for future transformation. The mistake occurs when leaders expect those foundational investments to generate competitive differentiation by themselves.

If every competitor has access to similar models, similar copilots, similar automation capabilities, and similar technology partners, then the source of advantage must come from somewhere else.

The answer, I believe, lies in organizational adaptability.

The highest-performing organizations in the coming decade may not be those with the most advanced AI. They may be those that can detect change faster, align on reality faster, make decisions faster, and scale successful change faster. AI becomes a critical enabler of that capability, but it is not the capability itself.

This perspective also changes how leaders should think about process improvement. Many organizations possess far more innovation than they realize. Employees constantly create workarounds. They build spreadsheets. They establish informal processes. They find ways to compensate for organizational friction. Traditional management often views these behaviors as inefficiencies to eliminate. Increasingly, I see them as signals. They reveal where formal processes are failing to keep pace with business realities.

The presence of thousands of improvement ideas is rarely the problem. Most organizations are not suffering from an idea shortage. They are suffering from an inability to systematically identify, prioritize, and scale the ideas that matter most. As a result, local improvements remain local, pilots remain pilots, and transformation remains frustratingly elusive.

This is where the conversation around AI becomes particularly interesting. Rather than asking how AI can automate existing processes, leadership teams might ask how AI can help the organization understand itself better. How can AI reduce fragmentation of information? How can it help leaders establish a common view of reality? How can it surface patterns that would otherwise remain hidden? How can it accelerate the movement of successful ideas from isolated teams into enterprise-wide capabilities?

Viewed through this lens, AI is less a productivity tool and more a decision system.

That distinction may turn out to be one of the most important strategic shifts executives can make.

The most compelling perspective on AI I have heard recently did not focus on automation at all. It focused on helping management make better decisions, faster, and stay closer to the market. The more I think about it, the more I believe that idea sits at the center of the entire transformation discussion.

Many organizations are measuring activity while hoping for adaptability.

They track usage while seeking competitiveness. They monitor adoption while expecting resilience. The metrics are real, but they are often disconnected from the outcome leadership actually wants.

Perhaps the real scoreboard for AI is not how many agents have been deployed or how many prompts employees have created. Perhaps the real scoreboard is whether the organization can sense, decide, and adapt faster than it could before.

If that is true, then AI is not trapped in PoC prison. AI is doing exactly what it was asked to do. The organization, however, may still be trapped in decision prison.

And escaping that prison is ultimately a leadership challenge, not a technology one.

The quarterly transformation review had started exactly as expected. AI adoption was accelerating across the organization, new copilots had entered production, departments were expanding successful pilots, and business units across Sales, Finance, Customer Service, Operations, and Engineering were already requesting broader deployment. The Chief AI Transformation Officer spent the first hour walking the executive committee through the latest results. Customer service teams were reporting shorter resolution times, Finance had reduced effort in planning cycles, Sales organizations were beginning to measure productivity improvements in proposal development, and operational teams were identifying opportunities that had not existed on their transformation roadmaps only months earlier. Viewed individually, the examples were encouraging. Taken together, they suggested an organization moving quickly beyond experimentation and into a phase where AI was becoming part of day-to-day operations.

The CFO listened without objection. Nothing in the presentation surprised him. Over the previous six months, he had reviewed a steadily increasing number of AI-related investment requests. The sponsors differed. The business functions differed. The projected benefits differed. What remained remarkably consistent was the recommendation attached to almost every proposal. Additional investment was required. Eventually he closed the briefing deck in front of him and remarked that a decade earlier the executive team had spent a significant amount of time having very similar discussions about cloud. The comparison required little explanation. Most people around the table had lived through that transition. They remembered governance workshops, architectural debates, migration waves, operating-model discussions, and business cases that initially required extensive justification. They also remembered how quickly those conversations changed once the first projects started producing measurable outcomes.

The Chief AI Transformation Officer challenged the comparison, although not entirely. Cloud, he argued, had fundamentally changed how organizations consumed infrastructure. AI was beginning to change how organizations consumed expertise, analysis, decision support, and work itself. The implications extended well beyond infrastructure economics because the results being discussed were increasingly tied to productivity, customer experience, operational performance, and organizational capacity. Several initiatives had already generated measurable gains. Others were outperforming the assumptions built into their original business cases. Looking solely at the outcomes being reported, it was difficult to argue that the organization was not creating value.

The discussion moved to the current investment portfolio. The list extended across nearly every major function in the business. Sales teams wanted proposal-generation agents. Customer Service was requesting broader deployment of autonomous case resolution. Finance had submitted requests for additional copilots supporting planning and forecasting activities. Operations leaders had identified new opportunities in process orchestration, while Engineering had assembled its own list of priorities. Many of the proposals carried executive sponsorship. Several had completed successful pilots. Most appeared entirely reasonable when evaluated on their own merits. The CFO studied the portfolio for several moments before asking how many AI business cases had entered review during the quarter. When the number appeared on the screen, he followed with a second question. How many of them projected positive business outcomes? The answer came back quickly. Almost all of them did.

One of the business leaders interpreted the question as skepticism and immediately returned to the results. Productivity gains were measurable. Adoption continued to increase. Several initiatives were already outperforming expectations. The CFO stopped him. The outcomes were not the issue. Looking again at the portfolio, he acknowledged that Sales could justify its requests, Customer Service could justify its requests, Finance could justify its requests, and Operations could justify its requests. Nobody around the table appeared interested in challenging those conclusions. What interested him was what happened next. If nearly every initiative generated value, how was the organization expected to choose between them when they eventually competed for the same investment capacity? The room became noticeably quieter. Up to that point, most of the discussion had examined individual opportunities. Each proposal had been evaluated on its own merits. Viewed together, however, the portfolio looked less like a collection of projects and more like a collection of competing priorities.

Me, the advisor attending the review had remained largely an observer until that point. Listening to the exchange, I noted that none of the proposals in front of the executive committee were competing against alternative technical approaches. They were competing against one another. Each sponsor was presenting a legitimate case supported by measurable outcomes, yet every initiative ultimately drew from the same pool of investment, governance capacity, executive attention, change-management resources, and organizational focus. My observation changed the discussion. The challenge no longer appeared to be demonstrating value. The evidence presented throughout the afternoon suggested that value creation was already occurring across multiple parts of the business. The more difficult problem emerged once success became widespread enough that every department could make a credible claim for additional investment.

The Chief AI Transformation Officer challenged the direction of the conversation. Much of the afternoon had focused on governance, controls, spending discipline, and prioritization. Those concerns were legitimate, he acknowledged, but they represented only one side of the equation. Across the market, competitors were increasing investment at a pace that would have appeared unrealistic only a few quarters earlier. Internally, business units were already expanding beyond their original plans as successful pilots generated demand for broader deployment. Looking around the room, he questioned whether the organization was spending too much time discussing the risks associated with moving too quickly and not enough time examining the consequences of moving too slowly. Several executives appeared to recognize the concern. Most had seen earlier technology waves where organizations that delayed investment eventually spent years attempting to close gaps that had become strategically significant.

I acknowledged the point, but observed that the discussion itself had already changed. During the early stages of most technology transformations, executive teams spend significant amounts of time trying to determine whether a capability creates value at all. That was not the discussion unfolding in the room. Customer Service had evidence. Finance had evidence. Sales had evidence. Operations had evidence. The portfolio was no longer populated by speculative ideas waiting for validation. It was increasingly populated by initiatives supported by pilots, business cases, executive sponsors, and measurable outcomes. The question facing the executive committee did not appear to be whether AI could create value. The question appeared to be how the organization should respond once opportunities for creating value began emerging simultaneously across every major business function.

The adoption forecasts reinforced the observation. Several projections had already been revised upward. Departments that initially requested limited pilots were discussing broader deployments. Teams that started with copilots were exploring agents. Business units that had once been focused on isolated use cases were assembling portfolios. None of those developments seemed particularly unusual in isolation. Taken together, however, they suggested a pattern familiar to many executives in the room. Successful projects rarely reduced demand. More often, they generated additional requests. The conversation gradually moved away from deployment and toward operating models, ownership structures, and governance mechanisms designed to cope with growing demand.

The CIO joined the discussion from a different perspective. Over the previous year, he explained, business leaders had largely stopped asking architecture questions. Model comparisons consumed far less attention than they once had. Technical debates had become shorter. The requests arriving in his organization were different now. Business leaders wanted to know how quickly they could move beyond pilots, who would approve expansion, who owned the underlying process, and who would ultimately be accountable for outcomes. Several executives around the table recognized the shift immediately because they were seeing similar patterns inside their own organizations. The technology itself was becoming less controversial. The organizational implications were becoming considerably more significant.

By the time the meeting approached its scheduled conclusion, the presentation that opened the afternoon felt increasingly distant. The organization was generating measurable outcomes. Demand was increasing. Additional opportunities continued to emerge. Nobody appeared interested in disputing any of those observations. The CFO eventually returned to a question that had surfaced repeatedly throughout the discussion and asked everyone to imagine the same meeting taking place three years later. The scenario was not one in which AI had failed. It was one in which AI had succeeded. Successful deployments existed across every major business unit. Business returns were demonstrable. Demand continued to grow. Additional investment requests arrived every quarter. More opportunities existed than the organization could realistically pursue at once.

Looking around the room, he asked a simple question.

How would the company decide what to fund next?

Nobody answered immediately.

The meeting reached its scheduled conclusion before anyone offered a response that appeared to satisfy every perspective in the room. Laptops closed. Papers were gathered. Conversations continued in smaller groups as executives moved toward their next commitments. The Chief AI Transformation Officer headed to another steering meeting. Members of the governance team left with the CIO. I collected my notes. The CFO remained seated for a few moments longer, still looking at the portfolio displayed on the screen before eventually standing and leaving as well.

The next quarterly review had already been scheduled.

The discussion left me with a hypothesis.

Cloud FinOps taught organizations how to govern compute.

AI FinOps is teaching organizations how to govern the cost of intelligence.

My hypothesis is that the next challenge will be different again.

Once every department can demonstrate value from AI, cost optimization becomes a secondary concern. The harder question becomes one of allocation.

Sales will want more intelligence. Finance will want more intelligence. Operations will want more intelligence. Customer Service will want more intelligence.

The executive challenge will no longer be deciding whether AI creates value.

It will be deciding where the next unit of intelligence creates the most value.

The organizations that solve that problem first may gain a significant competitive advantage over those that continue to treat AI primarily as a technology initiative.

That philosophy shaped the evolution of the Power Platform. Personal Developer Environments enabled experimentation. Managed Environments introduced operational guardrails. Environment strategies separated personal productivity from departmental workloads and production-grade applications. Centers of Excellence established ownership, lifecycle processes, and governance models. The environment became the central organizing principle. Applications lived in environments. Governance was applied through environments. Security, ownership, lifecycle management, and compliance all started from the same question: Where does this solution live?

That model proved remarkably successful because it addressed a world in which applications, flows, and automations were relatively scarce and deliberately created. Agentic AI fundamentally changes that equation.

Today, organizations are no longer discussing dozens or hundreds of business solutions. They are beginning to envision thousands of AI-generated applications, workflows, agents, skills, and copilots emerging across business functions. The challenge shifts from governing what people build to governing what AI can continuously create, compose, and operate.

This is where Microsoft’s introduction of Copilot Managed Runtime becomes strategically interesting. Microsoft’s recent announcements position it as a common execution platform for applications created through experiences such as Copilot Studio Apps, Cowork, Copilot Code, and SDK-based development. The objective is not merely hosting. The objective is to provide a common operational foundation that automatically inherits identity, governance, security, administration, and lifecycle controls.

Seen through that lens, Copilot Managed Runtime feels less like a product announcement and more like the next chapter of Microsoft’s managed platform strategy.

The Conversation Most Organizations Are Still Having

Much of the current industry discussion centers around a familiar question:

Can business users successfully build agents?

The debate sounds strikingly similar to conversations that surrounded Power Apps and Power Automate several years ago. Supporters point to the democratization of development. Critics point to the growing complexity behind seemingly simple solutions. Both sides are correct.

• Low-code never eliminated complexity. It shifted where complexity lived.
• The same lesson is now playing out with Agentic AI.

Creating a working agent is increasingly easy. Building a capability that can be trusted with sensitive information, integrated into critical business processes, reused across multiple departments, and operated consistently at enterprise scale remains difficult.

This distinction matters because it changes how executive leaders should think about AI adoption. The most important challenge may not be agent creation. It may be capability industrialization.

What Enterprise Adopters Are Learning

Some of the most advanced organizations are already moving beyond the idea of agent development as an isolated activity. Instead, they are treating AI as an organizational capability that requires structure, governance, architecture, and operational discipline. One particularly interesting pattern emerging among large enterprises is the creation of dedicated AI enablement functions that sit between business units and technology organizations. Business teams bring process challenges and operational opportunities. Cross-functional teams assess business value, validate feasibility, identify reusable patterns, and determine whether a capability should become part of the organization’s broader AI portfolio. The language itself begins to change.

The discussion is no longer about building agents. It becomes a discussion about creating reusable business capabilities.

A successful capability developed for one department quickly becomes relevant elsewhere. Knowledge retrieval, policy assistance, contract analysis, requirements engineering, employee onboarding, and service orchestration frequently extend beyond their original use case. As adoption grows, organizations discover that the hard problem is not creating the first implementation. The hard problem is ensuring that repeated success does not result in repeated fragmentation.

This is where architecture begins to matter.

Why Architecture Reappears at the Center of the Conversation

The arrival of Agentic AI introduces a new kind of architectural challenge.

Personal assistants, internally developed agents, embedded ERP agents, CRM copilots, AI-enhanced workflows, and future AI-generated applications are unlikely to share a common origin. They will emerge from different teams, platforms, and creation experiences. Yet from an enterprise perspective they ultimately participate in the same business ecosystem.

That raises uncomfortable questions.

Should every platform maintain its own identity model? Should every team create its own governance framework? Should each AI capability establish independent operational controls, monitoring practices, lifecycle processes, and compliance reviews?

Most organizations instinctively answer no.

What they are actually seeking is architectural consistency. They want innovation to emerge from many places while operational discipline remains predictable.

This is precisely why Copilot Managed Runtime deserves attention.

While often presented as a runtime capability, its most significant characteristic may be that it introduces a common operational model. Applications created through different experiences are designed to inherit a shared foundation for identity, governance, connector policies, lifecycle management, and administrative oversight. In other words, Microsoft appears to be addressing an architectural problem rather than a development problem.

The Most Important Signal: Microsoft Is Starting Outside Microsoft

One detail emerging from recent announcements may turn out to be more important than the runtime itself.

A common assumption is that Copilot Managed Runtime exists primarily to support applications created with Microsoft’s own tools. The recent partnership between Lovable and Microsoft suggests a broader ambition. Applications created in Lovable can now be deployed into Microsoft tenants while inheriting Entra authentication, data access controls, governance policies, and operational capabilities provided through the Microsoft platform.

This changes the interpretation of CMR significantly.

If the runtime only supported Copilot Studio or Microsoft-created applications, it would simply represent another platform capability. Allowing external development experiences to target the same operational foundation points toward something much larger. Microsoft appears to be building a common governance and execution layer that sits underneath multiple creation experiences rather than asking organizations to standardize on a single development tool.

From an architectural perspective, this may be the most significant signal so far. The strategic objective no longer appears to be controlling where applications are created. The objective appears to be ensuring that regardless of where they are created, applications can operate under the same identity model, governance framework, security controls, and administrative processes.

Understanding the Difference Between Managed Environments and Managed Runtime

At first glance, many governance leaders may view Copilot Managed Runtime as competing with existing Power Platform governance practices. That interpretation overlooks an important distinction.

Managed Environments were created to solve the governance challenges of citizen development. Their primary purpose was to establish clear boundaries around where solutions were created, operated, shared, and promoted throughout their lifecycle.

Copilot Managed Runtime appears to be solving a different challenge. The focus is no longer the environment in which an artifact was created. The focus is the workload that ultimately executes.

That distinction may seem subtle, but it reflects a significant shift in governance thinking. Historically, governance started by asking where an application belonged.

Increasingly, governance may start by asking how an AI-powered workload operates, what information it can access, which policies apply to it, how it is monitored, and who remains accountable for its behavior.

The governance object is evolving from environments toward workloads.

This does not diminish the value of environment strategies, Managed Environments, DLP policies, ALM processes, or CoE practices. Quite the opposite. Organizations that invested in these capabilities may be best positioned for the next phase because the underlying principles remain intact. Ownership, security, lifecycle management, compliance, and architecture continue to matter. The unit of governance, however, may be beginning to change.

The Emerging Accountability Challenge

The technology itself is relatively easy to understand. The organizational implications are considerably more complex.

For years, governance ownership in many organizations was straightforward. Power Platform teams governed Power Platform assets. Center of Excellence teams managed environments, makers, connectors, and lifecycle controls. Operating models matured around a well-understood set of administrative boundaries.

Copilot Managed Runtime introduces a broader context. Applications are increasingly surfaced through Microsoft 365 administrative experiences while continuing to coexist alongside traditional Power Platform assets. As a result, governance discussions inevitably move beyond technology.

Organizations will need to decide whether AI-powered workloads belong under existing Power Platform governance structures, Microsoft 365 administration teams, enterprise architecture boards, security organizations, or newly emerging AI governance functions.

This is not a technical decision. It is an operating model decision.

And history suggests that operating model decisions often determine success more than platform capabilities ever do.

This discussion is no longer purely speculative. Microsoft’s administrative documentation for Copilot Managed Runtime already describes a centralized application inventory within the Microsoft 365 Admin Center that provides visibility into ownership, operational health, compliance status, and governance actions for CMR workloads. At the same time, traditional Power Platform applications remain governed through PPAC.

This creates an entirely new governance conversation. Organizations are no longer simply deciding where applications should be built. They are beginning to determine which administrative plane owns accountability for AI-driven workloads.

The Bigger Picture

The most compelling interpretation of Copilot Managed Runtime is not that Microsoft has launched another runtime. It is that Microsoft appears to be extending a governance philosophy that began with Managed Environments into an AI-native world.

Managed Environments helped organizations answer a critical question during the rise of low-code:

How can innovation scale without losing control?

Agentic AI introduces a new version of that same challenge.

How can organizations enable thousands of AI-powered workloads without losing architectural consistency, operational transparency, governance discipline, and business accountability?

Copilot Managed Runtime appears to be Microsoft’s answer. Not because it makes development easier. Not because it eliminates complexity. But because it attempts to establish a common operational foundation beneath an increasingly diverse AI landscape.

The most consequential aspect of Copilot Managed Runtime may not be that it hosts applications generated by Microsoft tools. The more interesting possibility is that Microsoft is creating a common operating model for enterprise applications regardless of where they originate. Recent support for external platforms such as Lovable suggests that the ambition extends beyond Microsoft’s own development experiences. If applications created through Copilot Studio, coding agents, professional development environments, low-code tools, and third-party builders eventually converge on the same identity model, governance framework, operational controls, and administrative experience, then Copilot Managed Runtime becomes something much larger than a runtime. It becomes the governance substrate for enterprise AI applications.Managed Environments helped organizations govern citizen development. Copilot Managed Runtime may prove to be Microsoft’s attempt to govern the far more complex world of AI-generated workloads, regardless of who built them or where they were created. 

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,…