DEV Community: Alex Pechenizkiy

Can You Trust AI With Dataverse Security? Four Designs, Three Wrong

Alex Pechenizkiy — Wed, 12 Aug 2026 14:50:54 +0000

The AI had everything you would want for security work plugged in. Microsoft Learn MCP for authoritative documentation at request time. Agents and skills wired into the development workflow. Full codebase context including the existing schema, the existing flows, the existing components. Recent training data covering Dataverse in 2026.

It produced four candidate designs for one Dataverse security requirement.

Two violated documented Dataverse mechanics. The MCP would have surfaced the correct mechanics in a single query. The mechanics never came up because the orchestration did not force retrieval before composition. A third design did not violate any documented mechanic. It violated a security-engineering principle. That is a different failure class, one the MCP could not have caught even if queried.

That distinction is the article. The deeper question is not "can you trust AI with security code." It is: which claims are cheap to mechanically verify, and which are not? The architecture you build around AI follows from that line, not from a generic trust statement.

TL;DR

The fancy AI dev stack lowers the cost of verification. It does not eliminate the need. In a real conversation, four AI-generated Dataverse security designs: two violated documented Microsoft mechanics (the Microsoft Learn MCP would have caught both if queried; the orchestration did not force the query), one used a structurally illusory security boundary (a category error no docs page documents), one was correct. Trust boundary for configuration-shaped platform security like Dataverse RBAC: AI for boilerplate, AI plus a verifier on the mechanic claims (ideally a deterministic sandbox check, weaker as a second LLM), human as the always-required adjudicator for category-level judgment. The architectural axis is what your verification step can deterministically check.

The AI Stack You Would Want for Security Work

Imagine the most sophisticated AI development setup you could plug in for a Dataverse security task.

Microsoft Learn MCP for authoritative documentation at request time. The AI can query the canonical page on Field Security Profiles, on cascade behavior, on access teams, and pull verbatim mechanics into its reasoning.
Codebase context loaded. Existing tables. Existing relationships. Existing security roles. Existing flows. Existing PCF components. The AI can see what is already in place before proposing a change.
Specialized agents and skills. A reviewer agent that grades output against quality gates. A publish-check skill that gates commits. Content rules that flag forbidden patterns.
Recent training data. Dataverse 2026. The current security model, the current relationship types, the current Field Security Profile mechanics.

That stack should be enough. In theory the AI can do mechanic-anchored design without missing the mechanics.

In practice, it did not. What follows is a real conversation in which the AI generated four candidate designs for one Dataverse security requirement. Two failed on documented mechanics. One failed on a security-engineering category. Only the fourth was correct, and only after a senior engineer pushed back four times to extract it.

The interesting part is not the failure. The interesting part is that all the tools that should have prevented the mechanic failures were available, and the orchestration did not force their use at the moment that would have mattered. That is a different story than "the LLM was wrong." It is a story about workflow design.

Provenance

The AI in this conversation was Claude, with Microsoft Learn MCP wired in, codebase context loaded, and the reviewer agents and skills described above. The work happened during a real Dataverse engagement in April 2026. I am also using Claude to write this article. That is worth naming up front: this is one AI's synthesis behavior being critiqued through another instance of the same model on a different task. The failure pattern below is one I have seen repeatedly across providers; the transcript here is from one stack.

What This Evidence Does and Does Not Support

Before walking through the designs, an honest scoping. The argument generalizes from one real conversation: one Dataverse security requirement, one AI model (Claude), four candidate designs, four rounds of human pushback. That is N=1.

What the transcript directly supports. In this specific conversation, the AI generated two designs that violated documented Dataverse mechanics the wired-in Microsoft Learn MCP would have surfaced if queried, and one design that used a structurally illusory security boundary that no canonical docs page covers. The mechanic violations are verifiable against the Microsoft Learn pages cited below.
What is prior, not finding. The cross-vendor claim (the same shape of failure on GPT, Gemini, and open-weight models) is something I have watched repeatedly in production work but have not run a controlled experiment on. Treat that as an architect's prior. (mine)
Where the trust-tier framework comes from. The conversation directly supports the design-with-mechanic-verifier recommendation for this category of work. The boilerplate-OK and never-AI-as-sole-author tiers are shaped by repeated similar experience and are an opinion. (mine)
The domain this article scopes to. Configuration-shaped platform security: Dataverse RBAC, Salesforce sharing rules, ServiceNow ACLs, similar high-mechanic schema-side security. Other shapes of security work (translating a spec into IAM policy, writing CSP headers, generating Kubernetes NetworkPolicies) have different failure modes and are not addressed here.
What documentation alone does not solve. Even for mechanic-level errors, MCP queries help only when the mechanic is documented and the documentation covers your case. They do not catch undocumented edge cases, environment-specific behavior, plugin side effects, ALM drift, or tenant configuration variance. The article assumes docs are necessary; it does not assume they are sufficient.
What would strengthen the evidence. The same requirement run against three or more frontier models, with mechanic-checking by a domain-competent reviewer, recording where each model failed and on which mechanic. I have not done that experiment. If a reader has, I would welcome the data.

With those bounds in place, the rest of the article reads as: what the transcript caught, what the failure classes are, what verification mechanisms exist, and what I would build.

The Test Case

A perfectly ordinary Dataverse security requirement.

There is a parent record. There is a collection of child rows attached to it via a one-to-many relationship. A user, call them the participant, has access to the parent. The participant should also see the chain of child rows, including who created each row, when, and what status the row is in.

There is one piece of sensitive content on the child rows: free-text comments. The participant must NOT see those comments. Other roles (the original creators of those child rows, plus administrators) should see them.

The current production state was over-restricted. A previous fix had cut off the participant's access to the entire child collection because there was no way to express "see metadata, not text" cleanly. The product owner asked: undo the over-restriction, but keep the comments hidden.

That requirement has exactly two correct shapes in Dataverse, and three plausible-looking shapes that fail. The next sections walk through each wrong shape, but they are deliberately split into two failure classes because the verification work to catch them is different.

Two Failure Classes, Not Three Wrong Designs

The three failed designs are not the same kind of failure. Conflating them is comfortable rhetorically and dangerous architecturally.

Mechanic errors are claims that contradict documented platform behavior. They are catchable by querying canonical sources. In Dataverse this means the column-security model, the cascade-behavior matrix, the access-team and owner-team semantics, the relationship-type contract. Microsoft Learn covers all of these. If the orchestration forces a retrieval-before-composition step, mechanic errors get caught before they ship. Two of the three failed designs are mechanic errors.
Category errors are claims that follow documented mechanics correctly but violate a higher-level engineering principle. The principle is not on a docs page. Catching them requires either a human with the relevant judgment or an explicit principle-checker that knows the patterns (security-by-obscurity, implicit trust boundaries, time-of-check-vs-time-of-use, etc.). The MCP does not help. One of the three failed designs is a category error.

The walkthrough below labels each design accordingly. Read the mechanic errors as "the workflow was missing a forced verification step." Read the category error as "the workflow was missing a human or a principle-checker, and no amount of better doc retrieval would fix it."

Mechanic Error #1: Field Security Profile Block-By-Role

Design as proposed by the AI

Create a new Field Security Profile that blocks Read on the comment column for the participant role. Restore row-level Read on the child table for the participant role. The participant can read every row but the FSP returns the comment column empty.

Three sentences in, the design is wrong. Field Security Profiles are grant-only. They do not take security roles as members. They take users or teams (owner team or access team). The mechanism for hiding a column is the column's column-security flag (IsSecured = true in the developer API; "Enable column security" in the maker UI), which hides the column from EVERYONE by default. The Field Security Profile is the exception list, granting Read back to the users or teams that should see the column.

So the AI's design has the polarity reversed. To use FSP for this requirement, you mark the comment column as column-secured, which hides it from everyone. Then you create or maintain a team (owner team if membership is stable; access team if signers are assigned per-record by the signing flow) containing every user who SHOULD see the column. Then you create an FSP with that team as a member, granting Read on the secured column. The grant goes to the people who should see; the deny is implicit in the column-security flag.

Microsoft Learn states this directly on the Column-level security in Dataverse page and on the access teams and owner teams page. A single MCP query would have surfaced the polarity. The MCP was wired in. It was not queried.

The failure mode is not that the AI lacked the information. The failure mode is that the orchestration did not require the AI to verify the mechanic before composing a design that depends on it. Composing a design and verifying a mechanic are separate operations, and the workflow allowed them to be done in either order. In this case, only one of them happened. The compositional step pattern-matched on the shape of similar sentences the AI has seen ("create an FSP that blocks Read for a role") without conditioning that step on retrieved canonical behavior.

Verdict on Mechanic Error #1

Class: mechanic error. Would MCP have caught it? Yes, in one query. The cited column-security page documents both the grant-only model and the team-membership requirement. What was missing: a retrieval-before-composition orchestration rule, not better AI. Catchable how? Forced MCP query at design time, or a deterministic check that simulates the design against a sandbox tenant and verifies the column-read outcome.

Mechanic Error #2: Parental Relationship to a Comment Child Table

Design as proposed by the AI

Move comments to a new child table. Link the comment table to the existing child table via a parental relationship. The participant gets access to the existing child rows via cascade from the parent, but the comment rows live one level deeper, behind the parental link.

This is the most consequential of the failed designs because it silently exposes data in production.

Parental relationships in Dataverse propagate inherited access rights from parent to child. If a user has Read on the parent of a parental relationship, that Read inherits down to the child rows. The whole point of the design here is that the participant should read one level (the existing child table) but NOT another level (the new comment table). Setting the relationship to parental means the participant's access to the existing child rows inherits down to the comment rows, defeating the design.

The correct relationship type for this case is referential. Referential relationships do not propagate inherited access. A participant with Read on the existing child rows would not automatically gain Read on a referential-related comment row. Signers (the people who should see comments) need a separate explicit mechanism: their flow that activates a signing step adds them to an access team on the corresponding comment row.

Microsoft Learn documents this directly on the Microsoft Dataverse table relationships page. The cascade behavior matrix is unambiguous: parental relationships cascade Share, Reparent, Assign, Unshare (configurable to Cascade All, Active, or User-Owned). Referential relationships are Cascade None on those same actions. A single MCP query would have surfaced the matrix.

Same three tables. Same participant Read on the parent. Relationship type decides whether comments are exposed.

The MCP was wired in. It was not queried. The AI composed "use a parental relationship and let access inherit" because that string fit the slot in the design. Whether the string corresponded to the actual Dataverse cascade contract was a separate verification step that the workflow did not enforce.

Verdict on Mechanic Error #2

Class: mechanic error. Would MCP have caught it? Yes, in one query. The cascade-behavior matrix is explicit and unambiguous. What was missing: same as #1, a retrieval-before-composition orchestration rule. Cost of getting it wrong: silent production data exposure. The participant reads comments the design intends to hide and nothing in the runtime log says the security model is wrong, because from the platform's perspective the model is doing what it was told.

Category Error: JSON Snapshot as Security Boundary

Design as proposed by the AI

Add one column to the parent record. Store a JSON snapshot of the chain metadata in that column. The serializing flow excludes comment text. The participant reads the parent (including the JSON column) but the JSON has no comments in it. Security by structure, no FSP needed.

This is a different failure class entirely. Nothing in the design violates a documented Dataverse mechanic. The JSON column behaves exactly as the platform contract says. The participant has Read on the parent, the JSON column is on the parent, the participant reads the column. All of that is correct.

The bug is that structure-based security here is illusory. The "no comments in the JSON" promise has three independent failure paths:

Serializer drift. The promise relies on the flow building the JSON to never include comment text. That is policy enforced by code review, not architecture. The next developer who adds "include all custom fields" breaks the boundary without realizing it.
God-mode access. Anyone with read-everywhere privileges reads every column on every row, including the original comment column on the child rows. The JSON column is irrelevant to them.
Web API bypass. Anyone hitting the Dataverse Web API directly (with table-Read on the child table, which the participant already has by design in this requirement) reads the comment column on the child rows. The JSON column never enters the request.

The AI was confident the JSON design was structurally cleaner than the FSP design. It was not. It just looked cleaner because the policy boundary (the serializer) was implicit. In my read, implicit policy boundaries are the canonical security-by-obscurity pattern. (mine)

This is the failure class that retrieval-augmented generation cannot fix. No Microsoft Learn page says "do not use serialization as a security boundary." There is no canonical mechanic to query because the issue is not about Dataverse behavior. It is about the architectural difference between a policy enforced by code and a policy enforced by the platform itself. Catching this requires either a human with security-engineering judgment, or an explicit principle-checker that recognizes the pattern. The MCP is the wrong tool for the job.

Verdict on the Category Error

Class: category error. Would MCP have caught it? No. There is no documented mechanic to query. What was missing: a human security reviewer, or a checker that recognizes implicit-policy-boundary patterns. Why it matters: confusing this with a mechanic error makes the architectural conclusion wrong. More retrieval does not catch more category errors. They live in a different layer.

What Are the Correct Dataverse Security Designs for This Case?

Eventually, after the three wrong designs and four rounds of pushback, the AI produced two correct shapes. Both work. They have different operational trade-offs.

Aspect	Shape A: Field Security on the column	Shape B: Separate child table, referential relationship
Where the comment lives	Same column as today, but with column security enabled	New child table with referential relationship to the existing child
Who sees it	Members of an Owner Team (membership stable across the engagement) granted Read via FSP	Members of an Access Team added per comment row by the flow that activates each signing step
Operational cost	Maintain Owner Team membership when staff change	Per-row Access Team membership management in the signing flow
Audit trail	Purview activity logs on column-level reads	Standard row-level audit on the comment table
When this shape wins	All-or-nothing visibility (everyone in a fixed set sees all comments)	Per-row visibility (different signers see different comments)
Solution & ALM	FSP solution-aware; Owner Team membership is environment-scoped and migrates only via post-deploy scripts	Comment table solution-aware; Access Team templates migrate but per-row memberships are runtime data, not ALM artifacts
Mechanism reference	Grant-only model with column-security deny default. See Microsoft Learn.	Referential cascade behavior. See Microsoft Learn cascade matrix.

The technical content of these two shapes is what the AI eventually generated. The work to find them was the human's, not the AI's, even though the human was working with the AI's full output.

The Real Architectural Axis: What Is Cheap to Mechanically Verify?

The trust-boundary framing ("AI for boilerplate, AI plus critic for design, never AI for security") is a heuristic. It is useful as a default, but the load-bearing axis underneath is different and sharper.

The architectural decision is not "where to put AI." It is "which claims your verification step can deterministically check."

Some classes of claim are cheap to mechanically verify:

Syntactic claims. Does the file parse? Does the schema validate? Does the JSON conform to a schema? Compilers and parsers answer these in milliseconds and never lie.
Type-level claims. Does the function signature match the call site? Does the SQL query reference columns that exist? Type checkers and database-aware linters answer these deterministically.
Build-validity claims. Does the project compile? Does the test suite run? CI answers these.
Policy-evaluation claims. Given this RBAC configuration, can actor A perform action X on resource R? A policy evaluator (or a sandbox tenant with a few representative actor-action pairs) answers this deterministically.
Access-matrix claims. Given this Dataverse security model, who sees what? Provisionable in a sandbox tenant, queryable per-actor.
Unit-test claims. Given this input, does the function return the expected output? Tests answer this.

Some classes of claim are not cheap to mechanically verify:

Architecture quality. Is this the right abstraction for the next ten use cases? No deterministic check.
Threat-modeling completeness. Have we considered every attack path? No mechanical answer.
Semantic appropriateness. Is this the right way to model "approval" in this business?
Organizational assumptions. Is this control framework the one our auditors actually accept?
Pattern-level critique. Is this design relying on an implicit boundary that will silently fail later?

The first list is where AI scales well with verification wrapped around it. The second list is where AI helps less and human judgment carries the load.

The mechanic errors in this conversation belong to the first list. Dataverse's cascade behavior is a policy-evaluation claim. FSP membership is an access-matrix claim. Both are deterministically checkable in a sandbox tenant. The orchestration failure was not building the check.

The category error belongs to the second list. "Is the serializer an acceptable policy boundary?" has no deterministic verifier. Either a human reviewer with security-engineering chops catches it, or an explicit principle-checker that has been taught the pattern catches it, or it ships.

That distinction is the architecture. The trust-boundary tiers below are a heuristic version of it. The real move when you adopt AI on a new task is to ask: which class of claims will this task depend on, and what is my deterministic verifier for the first-list claims? If the answer is "I don't have one yet," that is the gap to close first. If the answer is "this task depends mostly on second-list claims," that is the signal that AI is going to need stronger human oversight than usual.

Why the Tools Didn't Catch It: Orchestration, Not LLM Failure

The available tooling did not prevent the two mechanic errors. The proximate cause is the LLM composed wrong sentences. The load-bearing cause is the workflow let it.

AI generates by composition, not by verification. Given a problem and a set of building blocks, the AI assembles candidates that fit the shape of similar examples it has seen. "Create an FSP that blocks Read for a role" is a sentence shape the model has seen in similar slots; the slot got filled. Whether the contents are mechanically correct is a separate operation. (mine)
Tool invocation is a learned heuristic, not a structural step. MCP, agents, and skills are available, but the AI must trigger them. The decision to query MCP for any given claim depends on context-window weighting and prompt-conditioning, not on any mechanism that recognizes when a load-bearing claim is being made. A confident-sounding compositional step ships without triggering the tool call that would have caught the error.
Reviewer agents that sit AFTER synthesis-and-commit do not help. Publish-check skills do not gate Dataverse semantics. Content-reviewer agents do not understand FSP membership. Visual-QA agents do not parse cascade behavior. They cover content discipline and rendering quality, not domain-mechanics correctness. Most teams shipping AI-assisted code today have similar gates (lint, tests, render quality, content review) and the same absence of a domain-mechanics gate.
Documentation lookup is not the same as deterministic verification. Even when the AI does query MCP, it gets back a documentation page. The AI still has to read it correctly, identify the relevant clause, apply it to the design, and conclude correctly. Each of those steps is itself probabilistic. Documentation queries help, but the strongest gate is not "did the AI read the docs," it is "does the design actually behave as claimed when provisioned in a sandbox." That gate is deterministic. Documentation is only the cheap approximation.

The conclusion: the verifier has to sit outside the synthesis loop, and the stronger the verifier the better the gate. A deterministic sandbox check is the strongest. A human reviewer who knows the mechanics is the next strongest. A second LLM forced to verify against MCP is the cheap intermediate, weaker than either of the above because the verifier is also probabilistic, but meaningfully better than no separation at all.

What did NOT work in this conversation: the AI itself, with all its tools, generating both the design and validating the design. That is the trust boundary the orchestration has to enforce.

Where Is the Trust Boundary for AI in Microsoft Security Code?

Three concrete tiers, in increasing risk. The framework is mine, shaped by the mechanically-verifiable axis above and by repeated experience including the conversation here. (mine)

Tier	What to trust AI for	Verification required	Failure mode if skipped
1. Boilerplate	Standard CRUD operations, copying existing flow patterns, drafting test scaffolding, refactoring within a defined contract.	Read the diff. Run existing tests.	Small, locally visible, easy to roll back. Acceptable risk.
2. Mechanic-checkable design	Architecture proposals, schema decisions, integration patterns, security designs where the claims map to documented platform mechanics.	Deterministic check preferred (sandbox provisioning + access-matrix tests). Human verifier as second-best. LLM mechanics-agent against MCP as cheap intermediate. Workflow halts on disagreement.	Mechanic violations ship silently. Plausible-looking design generates wrong access behavior in production.
3. Never as sole author for category-level security judgment	Pattern-level critique (is this an acceptable boundary?), threat modeling completeness, implicit-trust-boundary detection, organizational policy fit.	Human security reviewer required. Principle-checkers help but do not replace. Documentation queries do not help because no canonical page covers these.	Category errors ship: structure-as-security, implicit policy boundaries, hidden state assumptions. The build succeeds, the tests pass, the design fails on a class of attacks the test suite does not exercise.

The middle tier is where most teams will spend their time and where the deterministic-vs-LLM-vs-human verifier choice has the most leverage. The split-agent workflow described below is one concrete shape for the LLM-verifier intermediate. A sandbox-based check is stronger and is where this should head as teams mature.

For compliance leads who need to drop this into an AI-Use Policy doc, the three-tier framing maps cleanly to control language. The middle and top tiers operationalize NIST AI RMF MAP-3 (context of AI use, including assigning a verifier role) and MEASURE-2 (evaluation of AI-generated artifacts before deployment). SOC 2 readers can treat the mechanics-agent + human-checkpoint as a CC8.1 change-management control: AI-authored security designs require a documented review-and-approve step before commit, with the verifier output as the audit artifact. If the audit asks how the org discovers a wrong design that did ship, the answer is the same as for any other config-shaped security change: Purview activity logs for column reads, Dataverse access audit for row-level access, and the team's periodic Managed Environments security review.

This is not about model size or vendor choice. The conversation I describe ran with Claude. I have watched the same shape of failure on GPT, Gemini, and open-weight models across enough delivery work to call the pattern primitive-level rather than vendor-specific, but the receipts in this article are from one stack. Treat the cross-vendor claim as an architect's prior, not a finding from this transcript. The remedy I argue for is structural: change the workflow, not the model. (mine)

For more on the architecture-rules side of this, see Six Rules for LLM-Agnostic AI Agents on Microsoft Foundry and especially Rule 6 (run a quarterly model-swap drill) which applies the same discipline of "verify mechanics, do not trust spec sheets" to provider-agnostic agent fleets. For the governance-baseline side, see AI Governance Framework for Microsoft Enterprises. Microsoft's Well-Architected Framework codifies the human-accountability principle in Responsible AI in Azure workloads, which makes the same point at the framework level: oversight is not optional in agentic AI systems.

What I Would Build Now

A verification stack, ordered strongest to cheapest. Deploy the strongest gate your team can afford; use cheaper gates as bridges while the stronger ones are being built.

The strongest gate is a deterministic check against actual platform behavior. Provision the proposed schema in a sandbox tenant. Define a set of representative actor-and-action pairs that exercise the security boundary (participant tries to read comment column, signer tries to read comment column, admin tries to read comment column, participant tries the Web API bypass, etc.). Run them. Compare actual access outcome against intended outcome. Disagreement halts the workflow. This is deterministic because the platform itself is the verifier; there is no probabilistic step. It is the long-term direction for any team taking AI-assisted security design seriously.

The next-strongest gate is a human reviewer who knows the mechanics. When the sandbox check is not yet built, a human who understands FSP polarity, cascade behavior, and access-team semantics is the most reliable verifier. They are slow and they do not scale, but they catch both mechanic errors and category errors in one pass. Most engagements should have at least one of them on the AI-assisted security path.

The cheap intermediate is a split-agent verification workflow. Design and mechanics-checking run as separate AI calls with different prompts, different objectives, and a forced halt on disagreement. The design agent gets the problem, the context, and a prompt asking for candidate designs with explicit load-bearing mechanic claims. It produces a design plus a list of mechanics it depends on. The mechanics agent gets ONLY the list of claimed mechanics, queries Microsoft Learn MCP for each, and emits an agree/disagree verdict per claim. Disagreement halts the workflow and returns to the design agent. Agreement passes to a human.

Split-agent verification: design and mechanics-checking run as separate AI calls with different prompts and a forced halt on disagreement. The cheap intermediate while sandbox-as-CI is being built.

The always-required gate is a human adjudicator for category-level questions. Even with a deterministic sandbox check passing and a mechanics agent agreeing on every claim, the design can still be a category error (Wrong Design #2 above would pass both lower gates). A human in the loop on category-level questions is not optional regardless of how strong the mechanic gates are.

Where the split-agent design itself can fail

The mechanics agent is an LLM doing a synthesis-shaped task: read claims, query MCP, compare, return verdict. It inherits a softer version of the same failure mode it is meant to catch. A verifier can rubber-stamp a confidently-framed design, hallucinate an MCP response, or flag spurious disagreements on a correctly-modeled schema. Two LLMs in series reduce the residual error rate. They do not eliminate it. This is why the deterministic sandbox check is the stronger long-term gate and the split-agent workflow is positioned as the bridge, not the destination. It is direction, not a production-deployed pattern in this author's hands at scale, and the cost framing above assumes the mechanics-agent prompt and orchestration harness are themselves well-built. That is non-trivial engineering work. (mine)

For Microsoft delivery teams adopting agentic development, this stack converts AI from "a junior engineer with confident wrong answers on security" to "a fast paired-programmer whose mechanic claims get checked and whose category-level judgment gets reviewed." The substrate is the AI dev stack. The verification layer is what turns the substrate into a workflow you can defend.

What I Would Actually Do Today

If you are using AI for Dataverse security design right now, four concrete actions, ordered by deploy difficulty.

Force a mechanics-first prompt. Before asking for a design, ask the AI to enumerate the mechanics it will depend on. Verify the citations yourself. Then ask for the design. The mechanics-first ordering prevents synthesis from running ahead of verification, and it is the cheapest possible change: no orchestration code, just prompt discipline.

You are about to design a Dataverse security model for the requirement below.
Before you propose any design, do this:

1. List every load-bearing Dataverse mechanic this problem depends on
   (relationship cascade behavior, FSP membership and grant model,
   access-team semantics, owner-team scoping, role privilege depth, etc.).
2. For each mechanic, cite the Microsoft Learn page that documents it
   (use the wired-in Microsoft Learn MCP; quote the canonical sentence
   from each page so I can audit it).
3. Wait for me to verify the citations before you propose a design.

Requirement: <paste requirement here>

Add a mechanics-agent call between design and commit. A second AI call with a different prompt, given only the design and the relevant Microsoft Learn pages, asks the mechanics agent to compare the design to canonical docs.

You are a mechanics verifier. You will receive a Dataverse security design
and a list of Microsoft Learn page URLs.

For each load-bearing claim about Dataverse mechanics in the design:
1. Identify the claim verbatim.
2. Query the relevant Microsoft Learn page via MCP.
3. Quote the canonical sentence that supports or refutes the claim.
4. Mark the claim AGREE, DISAGREE, or UNVERIFIABLE.

Return only the per-claim verdict table. Do not propose changes.
Do not redesign. Disagreement on any claim halts the workflow and the
design returns to the design agent for revision.

Design: <paste design>
Microsoft Learn pages: <paste URL list>

Build a sandbox access-matrix test. Provision the proposed schema in a non-production tenant. Pick three to five representative actor-and-action pairs that exercise the security boundary. Run them as a test harness. This is the deterministic gate; once it exists, the mechanics-agent step is optional. Cost: one engineering sprint to build the harness, ongoing test maintenance per security change.

Keep a human in the loop on category-level questions. No combination of the above gates catches the JSON-as-security-boundary category error. Pattern-level critique is human work. Schedule a security-engineering review for any AI-generated security design before commit, regardless of how many automated gates passed.

The fancy AI dev stack is not the answer to the trust question. It is the substrate on which a workable verification architecture can be built. The trust comes from the architecture you build on top, not from the substrate itself. Microsoft Learn MCP, agents, skills, and codebase context are necessary. They are not sufficient.

The four-wrong-designs conversation is what happens when a team thinks the substrate is the discipline. The verification stack above is what the discipline actually looks like.

Frequently Asked Questions

Is AI safe for writing Dataverse security designs?
AI is safe for proposing Dataverse security designs and unsafe as the sole author. In this conversation two of three failed designs violated documented Dataverse mechanics (catchable with a forced retrieval step or a sandbox check), and one was a category error against security-engineering principles (catchable only by a human reviewer or an explicit principle-checker). The remedy is not "stop using AI for design," it is "build the verification layer that matches the failure class."

Why didn't Microsoft Learn MCP catch the wrong designs if it was wired in?
For the two mechanic errors, because tool invocation is a learned heuristic and the orchestration did not force retrieval before composition. The MCP would have surfaced the correct mechanics for both in a single query. The AI did not query. For the category error (JSON-as-security-boundary), the MCP would not have helped even if queried, because no canonical page documents that pattern as wrong. Different failure class, different verification need.

What is the real architectural axis behind your trust tiers?
What claims are cheap to mechanically verify. Policy-evaluation, access-matrix, syntax, type-level, and unit-test claims are cheap (deterministic checkers exist). Pattern-level critique, threat-modeling completeness, semantic appropriateness, and organizational assumptions are not (human judgment required). AI scales well around the first class when verification is wrapped around it. AI helps less for the second class and humans carry the load.

What does the split-agent verification workflow cost to build, and what's its limit?
One extra short-context LLM call per design candidate (the mechanics agent does not need a frontier model; a mini-tier model is fine because the work is citation lookup, not deep reasoning) plus a human checkpoint. Engineering: a few days plus ongoing prompt-drift maintenance. The limit is that the verifier is itself probabilistic and inherits a softer version of the same failure mode. The deterministic sandbox check is stronger; treat the split-agent as the cheap bridge until sandbox-as-CI is built.

Why insist on a sandbox check instead of trusting documentation queries?
Because documentation lookup is not the same as deterministic verification. Even when the AI reads the docs correctly, applying them to the specific design is itself a probabilistic step. Provisioning the proposed schema in a sandbox tenant and running representative actor-and-action pairs answers the access-outcome question deterministically. Also, docs miss undocumented edge cases, environment-specific behavior, plugin side effects, and tenant configuration variance. The platform is the verifier; docs are the cheap approximation.

Score your AI delivery practices

The Multi-Model Architecture Readiness Assessment covers the architecture side of AI delivery. The trust-boundary side covered in this article is a complementary discipline: where to put the verification step and which gate to deploy first. Both matter; neither is enough alone.

Cluster: AI Governance + AI Architecture. Related reading: Six Rules for LLM-Agnostic AI Agents on Microsoft Foundry for the architecture rules; AI Governance Framework for Microsoft Enterprises for the governance baseline; AI Readiness Assessment for Microsoft Enterprises which scores delivery practices including this trust-boundary question; Agentic Development with Claude Code which describes the AI dev setup and where this article shows the setup needs more discipline. Mechanics references: Field-level security in Dataverse, Dataverse table relationships and cascade behavior, Access teams and owner teams, Responsible AI in Azure workloads.

This article was originally published at az365.ai. I'm Alex Pechenizkiy, an Azure and Power Platform solutions architect writing honest, vendor-neutral analysis of the Microsoft AI stack. More at az365.ai.

AI Orchestration for Legacy Systems: The Operational Front Door Pattern (2026)

Alex Pechenizkiy — Tue, 11 Aug 2026 14:51:29 +0000

The pitch the CIO keeps hearing goes something like this. Replace the five legacy systems with one vendor's modern stack. Layer Copilot on top. Buy the seats. Watch the productivity numbers.

The pitch is not wrong, exactly. It is just expensive and slow, and it assumes the CIO has 24 to 36 months and a board willing to fund a migration before any AI value lands. Many of them do not. They have legacy systems that work, contracts that do not expire, teams that have built their daily craft around those tools, and a board asking why AI is still a slide rather than a system.

There is a third option, and it is the one stuck CIOs tend to underrate. An AI orchestration layer that sits on top of the existing legacy stack, owns intake and routing, and leaves the systems of record where they are. The legacy systems do not change. The work that moves between them does.

TL;DR + the Monday move

The pattern is The Operational Front Door. One AI surface owns intake, classification, and routing across 5-7 legacy systems that remain the systems of record. Two-layer RAG separates slow-moving organizational context (Layer 1, weekly refresh) from fast-moving live case state (Layer 2, sub-minute). AI providers are swappable behind an orchestrator-owned schema contract.

Monday move: if you are sitting on 5-7 legacy systems and your board is asking "where is AI in the operating model," do the schema work first. Pick a canonical work-item schema. Name an owner. The rest of the architecture follows.

The strategic insight: AI is not the hardest part of this architecture. Process standardization across geographies is. Owning the schema is. Identity propagation through every tool call is. The model is the swappable layer, not the foundation.

What Is the Operational Front Door?

I call this pattern The Operational Front Door. It frames AI as the orchestration layer over legacy systems. One AI surface unifies intake from every channel (web form, Teams, email, customer portal, partner portal). One orchestrator owns the canonical work-item schema and the state machine that moves work between teams. One connector layer reaches the legacy systems through standardized contracts. The AI provider plane sits behind the orchestrator and is interchangeable.

A note before the architecture section. The pattern (AI orchestration over legacy systems with the orchestrator owning the schema contract) is vendor-portable. The reference architecture below is its Azure-stack realization: Foundry Agent Service, Copilot Studio, Azure AI Search, Cosmos DB, Logic Apps as MCP servers, Entra ID, Agent 365. AWS and GCP renderings exist and would substitute Bedrock Agents + Step Functions + OpenSearch + EventBridge, or Vertex AI Agent Builder + Workflows + Vector Search + Pub/Sub. The architecture is the discipline; the specific Microsoft components named throughout this article are one valid implementation. If your primary AI cloud is not Azure, the layer responsibilities still apply; the component map changes.

The pattern preserves three things the CIO does not want to lose: the legacy investment, the institutional process knowledge, and the option to swap AI providers as the market shifts. It adds two things the CIO has been told they need: a unified AI front door for users, and an orchestration plane that scales with the work volume rather than the team count.

It is not the only pattern. The vendor-locked alternatives (ServiceNow Otto, Salesforce Agentforce Operations, Pega Agent Experience) ship the same idea bundled with a system of record. Where your data already lives in one of those stacks, the bundle is the right choice. Where your data lives across 5-7 systems with no single dominant vendor, the bundle becomes a rip-and-replace migration first. That is the gap this pattern fills.

A Scale Precedent, Before AI Orchestration Was Viable

Between 2018 and 2020 I worked on the case-management backbone of a global multi-region IT support operation. Multilingual customer base, multiple intake channels (enterprise customer-submitted, third-party-vendor-submitted, internal first-party escalations), regional staffing across multiple time zones with local-business-hours coverage. The operation worked.

AI orchestration was not part of it. The architecture I am about to describe is what the same problem deserves now, with current tools. The 2018-2020 engagement supplies scale credibility, not AI receipts.

All of this ran on humans, templates, and process discipline. No AI. What the operation did by hand is exactly what AI orchestration is for:

Classified cases by severity, product, and customer tier
Deduplicated against an open backlog deep enough that no one could hold it in working memory
Routed by team ownership, recent skill, and which time zone could pick up the next shift
Drafted customer communications from templates, then edited
Summarized case state across legacy systems for shift-to-shift handoff
Coordinated cross-org work through email, partner portals, internal CRM, and a code/work tracker, with the case manager translating between them

Every one of those steps is now an obvious AI orchestration candidate. The reference architecture in the rest of this article is the answer to "what would the same operation look like if you built it new in 2026 with Foundry Agent Service, Azure AI Search agentic retrieval, Cosmos DB change feed, Logic Apps as MCP servers, and a swappable model plane?"

The 2026 Reference Architecture for AI Over Legacy Systems

The architecture has six horizontal layers and two cross-cutting concerns. Each layer has a single responsibility. The orchestrator owns the canonical work-item schema. Everything else either feeds into the orchestrator, is queried by it, or executes on its behalf.

Layer 1: Channels

Work enters through whichever surface the user prefers. A web submission form for partners. A Microsoft Teams app for internal teams. Email intake for legacy customers. Customer-facing and partner/ISV portals for organizations that have already invested in those surfaces. The Operational Front Door does not require migrating channels; it requires connecting them.

Layer 2: AI Front Door (Copilot Studio)

The front door is the slot in the architecture that hands a structured work item to the orchestrator. Multiple tools can fill it: the Teams native bot framework, a custom web UI, M365 Copilot extensibility, or Copilot Studio. Each is the right answer in some shops. In M365-heavy shops Copilot Studio is a strong default because it ships M365 SSO, Teams-app integration, citizen-customizable topics, and connector access without custom UI work, and the citizen-developer customization layer matters more than front-end flexibility for most non-power-users. Where M365 is not the user surface, the same slot belongs to whichever tool gives you citizen-customization plus the identity story.

The front door does four things: intake (capture the user's input across modalities), classification (severity, product, tier, language), deduplication (is this the same as an existing open case), and first-touch dialog (ask the clarifying questions that turn an ambiguous request into a routable work item).

It does not make routing decisions. That is the orchestrator's job. The front door produces a structured work item conformant to the canonical schema and hands it off.

Layer 3: Orchestrator (Foundry Agent Service)

Microsoft Foundry Agent Service is the orchestration backbone. (For the Foundry vs Azure OpenAI decision specifically, see Azure AI Foundry vs Azure OpenAI: The 2026 Decision.) It hosts the agents that own the canonical work-item schema, the state machine that tracks work-item progression, and the routing logic that decides which team, geography, and engineer the work goes to next. Each agent has a dedicated Microsoft Entra identity for scoped resource access, and OAuth On-Behalf-Of passthrough is supported when downstream tools need the calling user's identity rather than the agent's.

The orchestrator does not own the data. The legacy systems own the data. The orchestrator owns the schema contract against which the legacy systems are addressed. This separation is what makes the rest of the architecture vendor-portable. The canonical-schema discipline is the same idea explored from the data side in Dataverse MCP, Business Skills, and Coding Agents for stacks where Dataverse is the system of record.

Multi-agent composition in Foundry Agent Service lets a main agent delegate to specialized sub-agents (triage, routing, summarization, customer-comms drafting). Foundry Agent Service itself is GA; the multi-agent workflows API that replaces the deprecated classic Connected Agents primitive is preview as of 2026, so net-new builds should compose at the GA agent + A2A-tool layer where the design permits and treat the workflows orchestration surface as a preview dependency.

Layer 4: Two-Layer RAG

The orchestrator queries two RAG layers with different freshness budgets and different update mechanics. The next section breaks them down.

Layer 5: Connector Layer (MCP Gateway)

Legacy systems are reached through Model Context Protocol servers. Standard Logic Apps now expose workflows as remote MCP servers with access to over 1,400 connectors (Dataverse, SQL, SharePoint, SAP, ServiceNow, and most of the enterprise integration surface). Easy Auth must be configured to enable the default OAuth 2.0 endpoint; the MCP endpoint speaks Streamable HTTP and Server-Sent Events.

Maturity note: Logic Apps as MCP servers is in public preview as of 2026. Microsoft's documented limits today (one connector per MCP server, one action per tool, built-in service provider-based and custom connectors not yet supported) constrain the initial connector matrix. Expect API shifts; pin Logic App versions and budget a migration sprint per quarter.

Custom MCP servers cover what the Logic Apps connector library does not. Azure Functions hosting and OpenAPI 3.0 tool definitions are the canonical paths.

API Center registers and governs the MCP server inventory. This is where compliance reviewers see what tools exist, who can call them, and what they do. API Center's MCP integration is also in preview as of 2026.

The whole point of this layer is that the orchestrator does not know it is talking to ITSM, CRM, or a partner portal. It is talking to a tool that conforms to the schema contract. Swap the underlying legacy system, rewire the connector, the orchestrator code does not change.

Layer 6: Legacy Systems of Record (Unchanged)

The 5-7 legacy systems stay where they are. Typical inventory:

Internal CRM / case management (the work-item system of record)
ITSM and ticketing for incident escalation
Code or work tracker (ADO/Jira-class) for engineering coordination
Customer-facing submission portal (read-back surface)
Partner / ISV portal (read-back surface)
Knowledge base of historical fixes and workarounds
Telemetry or test-result feed

The architecture does not require any of them to change. It requires them to expose stable enough APIs that a connector can survive the next two years.

If a legacy system is on its way out, plan the connector lifetime accordingly. If a legacy system is stable, the connector is a long-lived asset.

Side: AI Provider Plane (Interchangeable)

To the right of the orchestrator sits the AI provider plane. Foundry Model Router routes prompts across 18+ models including GPT, Claude, DeepSeek, Llama, and Grok. The agent code calls the standard Chat Completions API; the router decides which model handles each request based on the configured mode (Balanced, Quality, Cost) and the eligible-model subset.

Claude is the right pick for tough policy interpretation and ambiguous-severity cases where the reasoning needs to be defensible (just understand the marketplace billing trap before you commit Foundry credits to it). OpenAI's function-calling discipline shines on structured-output paths where the orchestrator needs clean JSON for a system-of-record update. Open-weights models (Llama, DeepSeek) absorb the high-volume classification work where token cost dominates. The router decides; the orchestrator is agnostic to model choice.

Model swap significantly reduces (it does not eliminate) the work involved in changing providers, provided the prompt-portability and tool-call discipline from the Six Rules article has been followed at build time. Even with that discipline, family-level swaps (GPT to Claude to Llama) tend to surface coupling at the prompt and tool-definition layer that no architecture eliminates fully. The honest claim is "the swap drill is a sprint, not a rewrite," not "config change only." This is the test of vendor independence and the reason the orchestrator owns the schema.

What this pattern centralizes, and what it leaves alone

Centralize:

The orchestration layer (routing, state machine, handoff logic)

The canonical operational work-item schema

Identity propagation (Entra OBO at every hop)

Observability and trace correlation

Routing policy

Do not centralize:

Domain workflows (each legacy system keeps its own)

Business logic (that lives in the system of record)

Source-of-truth data ownership

Approval systems

Per-system rules of the road

The pattern's leverage comes from owning the coordination plane while leaving the systems of record alone. Centralize more than this and the orchestrator becomes the very thing it was supposed to replace.

Cross-Cutting: Identity + Governance

Down the left side of the diagram runs the identity and governance band. Microsoft Entra ID propagates the calling user's identity through every tool invocation via OAuth OBO. APIM sits between the orchestrator and external endpoints for rate limiting, authentication enforcement, and observability. Agent 365 is Microsoft's new enterprise control plane for agents: registry, access control, visualization, interoperability, and security. Foundry-built and Copilot-Studio-built agents auto-register; registry sync for non-Microsoft frameworks (Bedrock, Vertex AI) is in preview as of 2026. The complement to the registered-agent control plane is the discovery side of governance: see Shadow AI Governance for Microsoft Enterprises for the unregistered-agent problem the registry does not solve on its own.

This band is not glamorous and tends to get cut in slides. It is the load-bearing piece. If identity does not propagate cleanly through every hop, the orchestrator either runs as a single super-user (compliance disaster) or fragments into per-system service accounts that nobody can audit. Neither survives an enterprise security review. For the broader networking + identity foundation this sits on, see The 2026 Azure AI Landing Zone Reference Architecture.

The Two-Layer RAG, in Detail

The single most overlooked design decision in enterprise RAG is freshness budget. Different knowledge has different update cadences. Bundling everything into one index optimizes for nothing and breaks both extremes: the slow knowledge becomes stale, or the fast knowledge does not make it in.

This pattern splits RAG into two layers. Layer 1 covers what changes weekly or slower. Layer 2 covers what changes per minute or faster. They use different stores, different update mechanics, and different query mechanics. They are joined at orchestrator query time, not at index time.

Layer 1: Org / Skills / Process (Slow, Curated)

Layer 1 knows the things that change weekly or slower. Which team owns which product. Which engineers have which skills. What the escalation policy says. What SLA tier each customer segment has. The content of resolved cases that have been promoted into the knowledge base.

The right substrate is Azure AI Search agentic retrieval. Extractive retrieval and the core knowledge-source types are GA in the 2026-04-01 REST API. The query-planning, answer-synthesis, and configurable-reasoning-effort surfaces this architecture leans on for the audit story are preview-only in 2025-11-01-preview and have already gone through two rounds of breaking changes in eight months. Plan for an API migration during a 6-9 month build.

The pipeline takes the orchestrator's question, uses an LLM as a query planner to decompose it into focused subqueries, runs the subqueries in parallel across the indexed corpus, applies semantic reranking, and returns a three-part response: content (the grounding passages), references (the source documents and chunks with citable URIs), and activity (the query plan, subqueries, ranking scores, and token-cost trace).

The three-part response is what makes Layer 1 audit-defensible in principle. Compliance can trace every claim back to its source and see which queries the system ran. This is the Microsoft surface heading toward the "regulated workload" audit story, with the caveat that the audit-relevant surfaces are still maturing. For the governance scaffolding that wraps around the audit story, see AI Governance Framework for Microsoft Enterprises.

Update mechanic: scheduled reindex of canonical corpora (knowledge base, org chart export, skills database, SLA policy documents). Cadence: weekly or on-publish. Freshness budget: days.

Layer 2: Live Case State (Fast, Derived)

Layer 2 knows the things that change per minute. Open case states across every legacy system. Recent state transitions in the last 24-72 hours. Similar-case resolutions in the last 14 days. Current queue depth per team per geography. Active assignments per engineer.

The right substrate is a Cosmos DB change-feed materialized view. Each legacy system emits state changes into a Cosmos container (via Logic App webhooks, Service Bus, or direct CDC). The change feed processor consumes those events at-least-once and rebuilds a derived view optimized for the orchestrator's read patterns: by team, by geography, by similar-case fingerprint.

The query mechanic is deterministic, not LLM-mediated. A point lookup and a range filter against the materialized view return the live state in milliseconds. No retrieval reasoning effort, no token cost, no probabilistic anything in the read path.

Update mechanic: change-feed processor with at-least-once delivery. Freshness budget: sub-minute.

The Join at Query Time

When the orchestrator asks "who should triage this case," it asks Layer 1 the planning question ("which team owns this product, what does the escalation policy say, what skills does the work require") and Layer 2 the state question ("which engineers on that team have current availability, who recently resolved a similar case"). The orchestrator combines the two before deciding.

Layer 1 alone tells you who should do the work in principle. Layer 2 alone tells you who can do the work right now. The triage answer needs both.

Joining at query time, rather than at index time, is the load-bearing choice. It prevents fast-changing operational state from forcing re-index cycles across slower-moving organizational knowledge. The freshness budgets stay isolated. The governance domains stay separable. Per-layer SLAs stay realistic. Bundling them into one index optimizes for nothing and breaks both extremes when the volume scales.

A note on terminology. The phrase "two-layer RAG" appears in other architecture writing with a different sense, typically partitioning along access-control or enterprise-wrapper concerns rather than the freshness axis used here. Both partitionings can coexist in the same system; the enterprise-wrapper concerns (auth, guardrails, evaluation harness, monitoring) apply equally to both layers in this pattern.

This split is one applied realization of the broader Enterprise Context Architecture framework, where informational context lives in Layer 1, operational context lives in Layer 2, authorization context propagates through Entra OBO, and environmental context lives in the orchestrator configuration.

Vendor Independence, in Practice

Three serious vendors ship the locked-stack version of this pattern as of 2026. All three are credible. All three work very well when your case data already lives on their platform. All three combine orchestration, system of record, and AI provider plane in one stack. The lock-in is across all three layers simultaneously.

Vendor	Product	What gets bundled	Right pick when
ServiceNow	Otto (Knowledge 2026)	Now Assist + Moveworks under one experience. AI agent studio, orchestrator, control tower.	ServiceNow is your system of record and you have no migration appetite. Cross-system orchestration centered on ServiceNow data.
Salesforce	Agentforce Operations	Multi-Agent Orchestration with shared context across channels. Specialized agents in Slack, Teams, IT service desk.	Your case data already lives in Salesforce. Back-office process automation as the primary use case.
Pega	Agent Experience	Any Pega workflow becomes an agentic engine. Main agent orchestrates specialized Pega flows.	Your business processes are already modeled in Pega. Workflow-centric orchestration over Pega-owned state.

The strongest counter from each vendor's senior architect is worth steel-manning. A ServiceNow architect would argue the Operational Front Door reinvents workflow governance externally: orchestration without process ownership becomes integration spaghetti, and enterprise AI requires governed workflows, approvals, SLAs, and audit state that Otto provides natively. A Salesforce architect would argue Data Cloud plus Agentforce reduces the need for an external orchestration layer because the unified operational data already lives in the platform. A Pega architect would argue the orchestration problem was solved a decade ago via case management; AI is merely another decisioning input, so why build a parallel orchestration plane that has to be defended at every architecture review?

The pattern's answer in each case is the same. When no single vendor owns more than half the case data, none of those platforms is the system of record for the work. Their bundled orchestration is excellent inside their stack and awkward outside it. The orchestrator (which you own) sits at the center precisely because no single vendor's gravity dominates the 5-7 systems.

That vendor independence is real, but it only earns its keep for organizations mature enough to operationalize evaluation, routing, and governance across providers. Without that operating model, the swappable plane sits unused and the bundle's speed-to-value wins by default.

The honest trade between bundled and unbundled: speed and fewer FTEs on one side; orchestrator ownership compounding over years on the other. The bundle ships in 90 days because the vendor made the schema decisions for you. The unbundled pattern buys 18 months of build pain to escape lock-in that may not bind for 5+ years. Pick the trade you can defend at the board.

The Operational Front Door pattern unbundles those three. The orchestrator (which you own) is at the center. Legacy systems of record stay where they are. AI providers swap behind the orchestrator's schema contract. The architectural difference is small in any single diagram and large over the project's lifetime.

The test of vendor independence is the swap drill. The day you replace your primary model in production is the day you find out whether the architecture is actually portable, or whether the model has crept into the schema, the prompts, the tool definitions, and the evaluation harness. The Six Rules for LLM-Agnostic AI Agents lay out the discipline that keeps the swap clean: abstract behind a gateway, route per task complexity rather than per agent, keep prompts portable, tier your traffic, pin model versions in production, run a quarterly swap drill. This article is the case-application of those rules across 5-7 systems.

Where Microsoft, Copilot Studio, and Foundry Actually Fit

The CIO question this answers: do I buy Copilot Studio, or do I build on Foundry? The honest answer is both, plus custom code for the schema contracts. The decision matrix:

Component	Microsoft surface	Why it fits there
End-user front door	Copilot Studio	M365 SSO, Teams app, citizen-customizable topics. The non-power-user majority talks to AI through Copilot Studio, not through a custom UI.
Orchestrator backbone	Foundry Agent Service	Per-agent Entra identity, OAuth OBO, agentic retrieval, evaluators, MCP gateway. The audit and telemetry surface lives here.
Cross-provider routing	Foundry Model Router	Cheap models for triage, frontier for policy interpretation. Model swap as deployment config rather than code change.
Layer 1 RAG (slow)	Azure AI Search agentic retrieval	Three-part response (content + references + activity) gives compliance the audit story when paired with the preview query-planning surface.
Layer 2 RAG (fast)	Cosmos DB change feed materialized view	Sub-minute freshness for live case state. At-least-once delivery via change feed processor.
Connectors to legacy	Logic Apps as MCP servers + API Center	1,400+ connectors. Easy Auth required. Streamable HTTP + SSE. API Center governs the inventory.
Identity propagation	Entra ID + APIM	Load-bearing across every tool call. The thing that breaks first when shortcuts get taken.
Enterprise governance	Agent 365	Registry, access control, visualization, security across every agent, regardless of where it was built.
Tough policy reasoning	Claude (via Foundry or direct)	Ambiguous severity, cross-system reconciliation, defensible reasoning chains.
Structured output paths	OpenAI (via Foundry or direct)	Function-calling discipline for system-of-record updates where schema adherence matters.
Schema contracts + state machine	Custom code	The canonical work-item schema, the orchestrator state machine, the identity-propagation glue. The things you do not license to a vendor.

The Mobilezone case study published by Microsoft is a public demonstration of the front-door portion of this pattern at production. Two agents, "Supporto" for internal IT support and "Mia" for customer service, both built on Copilot Studio with an MCP server providing curated data access. The team's banked lesson is the one this architecture takes seriously: keep workflows simple before introducing AI. The full Operational Front Door pattern is the same shape at larger scale with the orchestration plane made explicit.

What This Does Not Do

Ten honest limits worth naming before the budget conversation:

It does not replace your ITSM tool. ITSM stays the system of record for incidents. The orchestrator routes through it, not over it. If the goal is ITSM consolidation, that is a different project with different math.
It does not fix bad case-management process. AI on a broken process makes broken faster. The Mobilezone team published this lesson in their case study: keep workflows simple before introducing AI. If the severity scale in one office does not match the severity scale in another, AI orchestration amplifies the inconsistency in plausible-sounding outputs.
It does not survive identity sprawl. If your offices have separate identity providers and no Entra (or single-IdP) discipline, the orchestrator's tool-call identity propagation breaks at the first geography boundary. Fix identity before fixing orchestration.
It does not ship in 90 days. Six to nine months is the realistic minimum for the connector layer, the two-layer RAG, the schema standardization, and the governance build, plus a planned migration sprint per quarter to absorb preview-API churn (Logic Apps MCP, API Center MCP, agentic retrieval query-planning surface) through 2027. The CIO who is told otherwise is buying a demo, not a system.
It does not survive without a schema owner. Someone has to own the canonical work-item schema and have the political capital to enforce it across teams. Without that role, every connector becomes its own decision, the schema fragments into per-team variants, and the orchestration plane decays.
It does not eliminate model hallucination. Two-layer RAG reduces grounding errors and the Layer 2 deterministic-lookup path keeps live state out of the LLM read path. Neither eliminates the model failure modes that come with delegated reasoning. High-severity case classification still routes through a human reviewer; the architecture is what makes that review tractable, not what replaces it.
It does not replace vendor-stack solutions where they fit. If your case data already lives in ServiceNow, Salesforce, or Pega and you have no migration appetite, their bundled orchestration is the right answer. The Operational Front Door pattern is for stacks with no single dominant vendor, not for stacks where one already owns the system of record.
It does not auto-resolve data quality and semantic mismatch. The canonical work-item schema assumes you can map the 5-7 legacy systems to it cleanly. If the same customer is keyed three different ways across CRM, ITSM, and the partner portal, the orchestrator will inherit the ambiguity and route the same case to three different teams. Master-data hygiene precedes orchestration; if it is not in place, budget for an MDM workstream as a prerequisite, not as a follow-on.
It does not give you free observability. Distributed agent traces across the orchestrator, MCP connectors, two-layer RAG, and the AI provider plane do not assemble themselves into a debuggable picture. The default Foundry observability surface handles the agent side, but correlating across the legacy-system call paths and the preview-API surfaces (which may not emit the trace headers you expect) is its own discipline. Plan observability as load-bearing as the schema discipline, not as a Day-90 add.
It does not solve the organizational and people problems that orbit the architecture. Three real ones: (a) governance fragmentation when the orchestrator's authority crosses team boundaries that have never shared a canonical schema; (b) talent scarcity, because architects who understand both legacy integration and modern agent frameworks are expensive and rare, and the build needs both; (c) ongoing connector maintenance when legacy vendors ship competing AI features and their APIs drift to accommodate. Budget for the people side as deliberately as you budget for the code side.

Cost Shape (Illustrative)

Order-of-magnitude anchors for the steering-committee conversation. Numbers are illustrative; your scale, channel mix, and case volume will move them.

Orchestration plane build (one-time): $1.5–3M across 6–9 months. Roughly 60% on connectors, 25% on the canonical schema + state machine + identity-propagation glue, 15% on evaluator harness and governance plumbing.
Per-non-trivial-legacy-system connector: $150–400K depending on API surface stability, auth model, and SLA requirements. Trivial connectors (well-documented REST, OAuth-ready) can land at half that; bespoke legacy systems with no API contract can run double.
Two-layer RAG infrastructure: $200–500K across the data preparation, index build, change-feed processor, and evaluation harness, depending on corpus size and update cadence.
Run-rate model + retrieval costs: typical case-routing decision burns 2–4K tokens triage + 4–8K tokens retrieval + 2K tokens summarization. At 10K cases/month, expect $3–8K/month on model spend if routing is well-tiered. Cosmos DB RU/s for the change-feed materialized view runs $1–3K/month at this scale.
FTE shape (steady state): 1 schema owner / tech lead + 2–3 connector engineers + 1 evaluation lead + 1 SRE (often shared with the platform team). Five to six FTEs total for the orchestration plane plus the existing teams operating each legacy system.

Compare against vendor-locked alternatives at per-seat pricing across the same population. As a heuristic: the build math wins when you have 5–7 unbundled systems and more than 18 months of legacy preservation in front of you. It loses when one vendor already owns the majority of your case data.

When This Breaks at Month 6

The architecture above ships. The team is six months in. A senior architect who has run this pattern at scale will tell you the failures are predictable. Four are common enough to plan for explicitly.

Cascading retries on a sleepy connector. A legacy ITSM endpoint slows from 200ms to 4s under load. The orchestrator's tool-call timeout fires before the response lands. The retry policy fires a duplicate call. The agent sees two pending tool invocations, classifies the second as an unrelated case, and creates a phantom ticket. By the time someone notices, the queue carries several hundred phantom tickets and the on-call engineer is hunting through trace logs that don't quite line up.

Stale identity propagation across a token refresh. Entra OBO refreshes a user's token mid-conversation. The orchestrator caches the prior token in its agent context. The next downstream tool call goes out with the stale token. APIM rejects with 401. The agent retries with the same stale token. The user sees a "case routed to nobody" status and opens a complaint that takes longer to triage than the original case.

Semantic mismatch caught by the materialized view. Layer 2 sees a case update from the CRM with a customer ID that does not match the customer ID the partner portal opened the case under. The change-feed processor handles both as separate records. The orchestrator routes the same case twice. Master-data hygiene was not a Day 1 priority. It is now, retroactively, with backfill.

Provider outage during a routed task. Foundry Model Router falls back from frontier to fast tier when the primary model rate-limits. The fast model classifies the case differently. The orchestrator routes to the wrong team. The user gets escalation feedback at a different SLA tier. The audit trail shows the routing change but no one was watching for it because the routing decision is normally invisible.

None of these are theoretical. All are the kind of operational scar tissue that does not show up in the architecture diagram. Plan an incident-response discipline for each before the system carries production load, and rehearse the response in a non-emergency window so the on-call engineer is not learning the trace tooling at 2am.

CIO Checklist

Seven gating questions to ask before committing budget. If you cannot answer "yes" to at least five of seven, the orchestration project will most likely stall in year two.

Are your 5-7 systems stable enough that the connector layer will outlast 18 months of work?
Is your identity story unified (Entra ID, or a single IdP) across the user populations who will interact with the orchestrator?
Do you have a named person who owns the canonical work-item schema and is empowered to enforce it?
Do you have an evaluation discipline for model outputs that goes beyond "store the logs," including groundedness scoring, response-completeness checks, and a regression harness?
Do you have legal sign-off for the cross-system data joins the orchestrator will perform?
Is the legacy-system replacement timeline deferred long enough (typically 24-36 months) to amortize the connector investment?
Do you have the political capital to standardize handoff vocabulary and severity definitions across geographies?

The hardest scale lesson, generalizable from any multi-region operation: process standardization is the load-bearing piece, not the AI. AI orchestration sits on top of that discipline. Where the process is consistent, AI amplifies efficiency. Where the severity scale in one region does not match the severity scale in another, AI amplifies the inconsistency. The architecture is the easier half. The standardization is the harder half.

The 24-36 Month Window for AI Over Legacy Systems

Based on the current vendor announcement cadence (Otto, Agentforce Operations, and Agent Experience all landed within twelve months of each other), the next 24 to 36 months look like the window. After that, the locked-stack vendors will most likely sell you a polished version of this pattern with all the schema decisions made for you and all the lock-in costs that implies.

There is a deeper consequence worth naming. The orchestration layer becomes the operational control plane for enterprise work. Once it owns routing, identity propagation, retrieval, and workflow initiation across the legacy stack, it changes ownership politics, funding models, and vendor leverage in ways that outlast any single model rotation. Most enterprise AI programs fail because they treat the model as the architecture. In production, the architecture is identity, orchestration, contracts, and operational ownership. The model is the swappable surface, not the foundation.

Build the schema you own. Build the connectors you can keep. Build the AI plane you can swap. Run the model-swap drill once a quarter so the portability is a measured fact, not an aspiration. Those four are the things that make the architecture defensible at year five, when the third major model rotation lands and the second wave of consolidation pitches arrives.

The Six Agentic Adoption Patterns: A Practitioner Decode of Microsoft's New Playbook (2026)

Alex Pechenizkiy — Mon, 10 Aug 2026 14:51:40 +0000

Microsoft just published a 52-page framework that almost no one in your steering committee has read yet. This is the practitioner read on what it gets right, what it leaves unsaid, and how to use it without becoming its captive audience.

The Agentic Transformation Patterns Playbook came from the Microsoft Copilot Acceleration Team in April 2026. It is the most operating-model-centric Microsoft framework I have seen for enterprise AI, distinct from the model-selection and product-adoption guidance Microsoft published through 2024-2025. Treat it as v1 of a still-refining artifact, not a validated standard: it is five weeks old at writing, authored by one team, and the field has not yet had a deployment cycle long enough to test the prescriptions. The framework's whole thesis is on page 52:

"Agents don't scale through technology. They scale through people, ownership, and operating discipline. You don't need a bigger model. You need a better operating model."

That sentence holds up to a senior read. The rest of this article is how the framework holds, where it understates the difficulty, and how to use it.

Two calibrations before going further. First, the framework leans on Microsoft surfaces at mixed maturity. Plan accordingly: Patterns 1-3 sit on GA surfaces and ship today; Patterns 4-6 depend on capabilities still hardening.

Microsoft surface maturity (mid-2026)

GA today: M365 Copilot, Copilot Studio, Foundry Agent Service, Foundry Model Router.

Preview as of mid-2026: Logic Apps as MCP servers, API Center MCP integration, Foundry agentic retrieval query-planning, Agent 365 cross-platform registry sync.

The orchestrated (Pattern 4), external-facing (Pattern 5), and AI-first (Pattern 6) work the playbook describes depends on the preview surfaces. Budget for API churn during the next 12-18 months.

Second, the playbook reflects one team's framing at one point in time. Competing taxonomies exist. The value here is the operating-model framing, not the patterns themselves as a settled industry standard.

TL;DR + the Monday move

Microsoft's playbook gives you six adoption patterns, a 5x5 maturity model, a CoE framework, and a 90-day starter play. The patterns are design choices, not stages; most enterprises run 2-3 simultaneously. The biggest practical insight is the "scale-breaker" concept: your weakest capability driver is your ceiling, so find that one gap and invest there first.

Monday move: pick the 1-2 patterns that match your current priorities. Name a single owner per pattern. Run the 5x5 diagnostic. Find your scale-breaker. Don't try to do everything everywhere.

Where the framework understates the work: organizational politics. The 5x5 has 25 cells. None of them measure the political capital to enforce schema decisions across team boundaries that have never shared a contract. That is the scale-breaker the playbook does not name.

The Assist to Execute Shift

The playbook opens (page 3) with a single conceptual shift it argues changes everything downstream. AI agents are moving from assisting humans to executing work. In Assist mode, the agent supports a human decision, and the human is fully accountable. In Execute mode, the agent performs work across systems, makes decisions, orchestrates workflows, and the human shifts to overseeing outcomes rather than producing them.

The shift creates four new demands:

Ownership: who is accountable for this agent
Risk: what happens when it goes wrong
Lifecycle: who maintains and improves it over time
Governance: what it is allowed to do and not do

Those four demands are the entire reason the rest of the playbook exists. If your agents are still in pure Assist mode, the operating-model overhead of the framework is mostly overkill. Once any agent crosses into Execute, the playbook's vocabulary becomes useful scaffolding for the operating-model conversation that has to happen.

What the playbook leaves unsaid is the schema question. Execute mode demands a canonical schema for the work being done, owned by someone with authority across the systems the agent touches. The playbook implies this in its CoE section but never names it as load-bearing. I have argued elsewhere that schema ownership is the architectural foundation under which the rest of any orchestration plane has to sit. See the companion piece on AI orchestration over legacy systems for the reference architecture that takes that idea to its logical end.

Six Adoption Patterns, Not Stages

The framework's central contribution is naming six distinct adoption patterns. The point Microsoft makes repeatedly is that these are design choices, not maturity stages. You do not progress from Pattern 1 to Pattern 6 in sequence. Most enterprises pursue 2-3 patterns simultaneously, and each pattern demands its own governance, ownership, and maturity depth.

Here are the six, with the kind of agents they describe and what they actually look like in practice:

Pattern	What it does	Where it lives
1. Employee AI Enablement	Individual productivity assistants that draft, summarize, research, and automate personal workflows. Humans retain decision authority.	M365 Copilot in Word, Excel, Outlook. Teams chat assistants. Personal flows.
2. Business Expert Empowerment	Scaling SME judgment via agents that answer domain questions, interpret guidelines, and surface expert knowledge on demand. Expert remains accountable for credibility.	Policy and compliance Q&A. Engineering standards. Risk assessment support. Regulatory interpretation.
3. Workplace & IT Services	Agents that handle intake, triage, and end-to-end execution of internal services. Service owners govern; agents operate.	IT helpdesk. HR services. Finance. Facilities. Procurement workflows.
4. Core Business Process Transformation	Agents that orchestrate complex revenue-impacting workflows across multiple systems. Routine decisions autonomous; exceptions escalate.	Claims processing. Order-to-cash. Financial close. Manufacturing quality. Supply chain.
5. External Engagement	Customer- and partner-facing agents that cross the enterprise trust boundary. Every interaction affects brand.	Customer support. Digital concierge. Partner enablement. Status tracking. Vendor onboarding.
6. AI-First Capabilities	Net-new capabilities built around agent loops. Sense, decide, act, learn. Things that were not possible before AI.	Continuous optimization engines. Fraud detection. Market sensing platforms. Predictive planning. Autonomous workflow generation.

In my read, most enterprises will find themselves cleanly inside Patterns 1 and 2, struggling honestly with Pattern 3, and overreaching into Patterns 4 and 5 before they have the maturity. Pattern 6 is for organizations that have already shipped autonomous agentic systems into production at least once and are building new business capabilities on top; in our read, outside digital-native orgs and based on the field maturity we see today, most enterprises are 18-36 months away from a real Pattern 6 deployment.

The pattern-vs-stage distinction is the playbook's most underappreciated insight. Many CIOs will read the list and conclude they should do Pattern 1 first, then graduate to Pattern 2, and so on. That is wrong. The patterns are different design choices for different work, and you choose based on what you are trying to do, not based on where you sit on a maturity curve.

The 5x5 Maturity Model

The playbook then introduces a maturity model (Section 2, page 25 onward) that is meaningfully different from the typical "Initial, Repeatable, Defined, Capable, Optimized" five-rung ladders that have dominated enterprise frameworks since CMM. The Microsoft version is a 5x5: five capability drivers (AI Strategy & Experience, Business Strategy, Governance & Security, Technology & Data, Organization & Culture) crossed with five maturity levels (100 Initial, 200 Repeatable, 300 Defined, 400 Capable, 500 Optimized).

The model's strongest contribution is the explicit acknowledgment that 500-everywhere is not the goal. Different patterns demand different target maturity profiles. An Employee Enablement pattern can succeed with 200-300 across most drivers and a 300 in Organization & Culture. A Core Business Process Transformation pattern demands 500 in Strategy and Business Strategy, 400 across Governance, Technology, and Culture. The match between pattern and target maturity is the framework's primary diagnostic.

The concept the playbook calls a "scale-breaker" is the most operationally useful part of the framework. Your weakest capability driver becomes your ceiling, regardless of how strong the others are. An enterprise sitting at 100/300/400/200/100 across the five drivers cannot scale Pattern 4 (which needs 500/500/400/400/400) because of the 100 in Organization & Culture and the 100 in AI Strategy. The 400 in Governance is wasted capacity until the other drivers catch up. The diagnostic tells you where to invest first: not where to spend the most, but where to close the gap that blocks scale.

Where the model is honest: it admits that "most organizations are a patchwork" and that the unevenness is exactly where scale breaks. Where the model is silent: organizational politics. The 5x5 does not capture the political maturity to enforce schema decisions across team boundaries, to name a single accountable owner across functions that have never shared one, or to defund a high-visibility pilot that is not producing results. Those decisions are the actual scale-breakers in most enterprises I have worked with, and they do not show up in any of the 25 cells.

The Top 5 Scale-Breakers

Page 34 of the playbook lists the five most common signals that maturity gaps are blocking scale. Most organizations recognize at least three. The list is genuinely useful as a diagnostic, but each one has an honest interpretation that the playbook understates.

Many pilots, no portfolio. The playbook prescribes picking 1-2 outcomes and 1-2 patterns and naming business owners. The honest add: most enterprises cannot name one outcome owner who has the authority to defund competing initiatives. Until that authority exists, the portfolio discipline is rhetorical.

One-off agents, no reuse. The playbook prescribes standardizing reference architecture, integration patterns, and telemetry. The honest add: this is the schema-contract argument extended. Without a canonical schema owned by someone with cross-team authority, every reuse attempt becomes a negotiation. See AI orchestration over legacy systems for the architecture pattern.

Great demos, low adoption. The playbook prescribes designing golden paths for the top scenarios. The honest add: golden paths require a process owner, not just a UI designer. The most common failure mode is a beautifully designed flow that nobody is empowered to enforce across teams.

Licenses are not usage. The playbook prescribes systematic enablement: role-based training, community, champions, incentives. The honest add: license plus enablement still loses without leadership role-modeling. If the executives do not visibly use the agents themselves, the rest of the organization reads it as theater.

Shadow agents appearing. The playbook prescribes a minimum baseline of named owner, audit trail, release gate, monitoring, and risk-tiered escalation. The honest add: governance baselines catch some shadow agents but not the ones running on personal Copilot subscriptions or third-party tools that never touched your tenant. The playbook is silent on this Tier 0 (agents that exist below the governance horizon). See Shadow AI Governance for Microsoft Enterprises for the discovery side.

The diagnostic value of the list is real. Most steering committees can run through it in 15 minutes and identify two or three signals they have. The fixes are harder than the playbook suggests, but naming the failure modes precisely is the first step.

The CoE Framework: Three Structures, Matched to Pattern

Section 3 of the playbook (pages 35-48) introduces the Center of Excellence as the operating vehicle that turns intent into repeatable execution. The framework names four CoE functions (Govern, Enable, Optimize, Scale) and three structural options (Centralized, Hybrid, Federated). The strongest contribution is the explicit matching of structure to pattern.

Structure	Best for	How it works
Centralized	Employee Enablement, Workplace & IT (early), External Engagement	One team sets rules, delivers, and monitors. Maximum consistency and control. Best when you are early, when risk is high, or when agents cross enterprise boundaries.
Hybrid	Business Expert Empowerment, Workplace & IT (as it matures)	Central team sets standards and supplies expertise; local teams build within guardrails. Matrix model where the CoE enables rather than controls.
Federated	Core Business Process, AI-First Capabilities	Business units own agent outcomes and delivery end-to-end. The CoE provides standards, enablement, and governance by exception. Requires mature teams who can own agent lifecycle independently.

Most CoEs start centralized and stay there past their useful life. The framework's matching gives you a clean exit ramp: as patterns mature, the CoE structure should shift to match. A Centralized CoE running Pattern 4 (Core Business Process) at scale is a bottleneck the playbook explicitly warns against.

The framework's six core CoE roles plus four edge roles (pages 40-41) cover the staffing model honestly:

Six core CoE roles: Executive Sponsor (strategic), Business Owner (value), CoE Lead / AI Program Manager (operating), Agent Product Owner (product), Platform & Operations (run), Security / Risk / Compliance (trust).
Four edge roles: Makers, Domain Experts, Service Owners, Adoption Leads.

Page 38 names a 7-stage agent lifecycle (Intake → Triage → Build → Deploy → Monitor → Improve → Retire), and page 42 maps a 10-row RACI across those stages plus overlay activities (agent strategy & prioritization, knowledge curation, release gate, incident response, performance review, retirement). The mapping translates cleanly to existing change-management discipline.

The framework's strongest contribution is the explicit decision-rights split:

Centralize (HOW scale works)	Delegate (WHO builds everything)
Platform and environment strategy	Domain prioritization (which use cases matter most)
Security and compliance policies	Agent design within architecture standards
Architecture standards and reference patterns	Knowledge curation (what content the agent uses)
Release readiness / go-no-go gate criteria	Day-to-day operations for lower-risk agents
Monitoring standards and alerting thresholds	User experience and interaction design
Agent risk classification tiers	Domain-specific success metrics and KPIs
Autonomy limits	Continuous improvement
Responsible AI guidelines	Delivery execution

Where the framework is weakest: it assumes the existence of an Executive Sponsor with both budget AND political capital. In our experience, you have one or the other in most enterprises, rarely both. The Executive Sponsor role is the role most likely to be assigned to someone who cannot actually fulfill it, and the framework does not name that risk. A future companion piece will go deeper on CoE anti-patterns.

Risk-Tiered Governance

Page 46 of the playbook splits agents into three risk tiers with proportionate controls. This is the cleanest part of the framework and the most directly portable to existing risk management practice.

Tier	What it covers	Required controls
Tier 1: Low Risk	Individual productivity agents (drafting, summarization, research)	Named owner. Basic monitoring. Standard release checklist. Self-service deployment within guardrails.
Tier 2: Medium Risk	Expert knowledge agents and internal service agents	Named owner plus domain expert validator. Knowledge quality monitoring. Formal release gate with review. Accuracy tracking and feedback loops.
Tier 3: High Risk	Business-critical and external-facing agents	Named owner plus formal process owner. Production-grade SLA monitoring. Security review plus responsible-AI assessment. Decision rights framework. Incident response plan. Quarterly maturity review.

The framework explicitly warns against over-governing low-risk agents (kills adoption) and under-governing high-risk ones (creates liability). That principle is sound and undersold in most governance writing.

One tier the framework misses: Tier 0, agents in personal Copilot subscriptions or third-party tools that never registered with your tenant. These are invisible to your governance plane by definition. The Tier 3 controls do not apply because the agent does not exist in your environment. The discovery problem precedes the governance problem; see again Shadow AI Governance for Microsoft Enterprises for the discovery-side companion.

The 90-Day Play

Section 4 of the playbook (pages 49-50) is a concrete starter roadmap.

Days 0-30: Foundation.

Pick 1-2 adoption patterns that match current priorities.
Name a specific owner (a person, not a team) per initiative.
Run the maturity diagnostic across all five drivers.
Identify your top scale-breaker (the one gap that blocks everything).
Audit your tenant: how many agents exist already, who owns them.

Days 30-60: Stand Up.

Define minimum governance guardrails (ownership, release gates, monitoring).
Stand up the CoE rhythm, even if it is three people and a weekly standup.
Deliver 1-2 agents to production with monitoring from day one.
Create a shared intake process for new agent requests.
Start weekly health checks on all production agents.

Days 60-90: Scale.

Treat agents as production services, not experiments.
Measure outcomes, not just usage and adoption.
Run your first leadership scorecard on a monthly cadence.
Review maturity progress against your scale-breaker.
Decide what scales next.

The 90-day frame is realistic if you already have a Power Platform CoE or equivalent governance scaffolding. If you are starting from zero AI governance, treat the 90-day play as Phase 1 of a 12-month build. The honest gap the framework leaves: what to do when the CoE rhythm does not get attended. In our experience, most CoEs fail not from absent process but from absent participation, and the playbook is silent on enforcement.

Where the Playbook Will Land for Different Enterprise Types

Adopt the framework selectively. Your enterprise's current posture determines how much of it applies and how fast you can absorb it.

Enterprise type	What the playbook gives you	Where to skip-read
Already running a Power Platform CoE	An extension of what you already do. The new vocabulary (Adoption Lead, Agent Product Owner, scale-breaker, 5x5) plugs into existing rhythms cleanly. Adoption typically takes ~3 months in our experience.	Skip nothing; this is an additive read.
Single Pattern 1 deployment (M365 Copilot only)	The conceptual scaffolding (Assist→Execute shift, the six patterns, maturity-as-diagnostic).	Skip the CoE depth and the 90-day play until you are actually deploying Pattern 2 or 3.
Actively running Patterns 3-5 already	The missing governance vocabulary. Adopt the tier classification, role definitions, and weekly/monthly/quarterly operating rhythm. The single highest-value adoption is the decision-rights split between Centralized and Delegated.	Skip the maturity diagnostic if you already know your scale-breaker.
Mixed-stack (Microsoft + ServiceNow / Salesforce / Pega)	The patterns themselves are vendor-portable. The CoE structures map cleanly onto non-Microsoft operating models (a ServiceNow workflow + CMDB shop, for example, can adopt the Centralized → Hybrid CoE evolution without changing its platform stack). The risk-tier model is universal.	Skip the Microsoft-surface assumptions in the implementation guidance; adapt to your dominant stack.

Working example: Pattern 4 schema ownership in a Pega-dominant stack. Take a claims-processing orchestration spanning the Pega case manager, the document store, and the policy admin system. The schema ownership question maps 1:1 to the Microsoft framing: who owns the canonical work-object contract, who chairs change-review, who gates releases that touch the claims data model. The CoE structure (Centralized for risk control, Hybrid as the team matures) is identical. The tactical differences sit in implementation surfaces: Pega rules layer instead of Logic Apps for orchestration, Constellation UI instead of Copilot Studio canvas, Pega's case life-cycle telemetry instead of Foundry agent traces. The same exercise runs cleanly for a Salesforce Service Cloud + MuleSoft shop or a ServiceNow Now Assist + Workflow Studio shop. That is what vendor-portable means here: the patterns and the CoE structures move; the surface choices do not.

Budget anchor for the steering committee. The playbook is silent on the people-cost of the CoE operating model it prescribes. Order-of-magnitude estimates from our experience: a 10K-employee enterprise running Patterns 1-2 with light Pattern 3 typically needs 4-8 FTEs in the first year across the named CoE roles (blend of net-new hires + reassigned platform and governance staff); a 50K-employee enterprise with Patterns 3-5 active typically runs 12-20 FTEs steady-state across central CoE plus federated business-unit ownership (this is central staffing only; per-region embedded ownership for follow-the-sun coverage adds on top). Treat these as illustrative ranges, not commitments; your scale, geography, and regulated-data posture move them.

One regulatory flag the playbook does not surface. For multi-region enterprises (especially EU plus US footprints), Pattern 5 (External Engagement) and Pattern 6 (AI-First Capabilities) raise data-residency and audit-logging concerns the framework treats as out of scope. Map per-region residency requirements to your Tier 3 controls before greenlighting either pattern.

The Line Buried on Page 52

The framework's whole thesis appears in two sentences at the end of the document:

"Agents don't scale through technology. They scale through people, ownership, and operating discipline. You don't need a bigger model. You need a better operating model."

That line is the strategic implication for hiring, funding, and vendor selection over the next 18 months. In our view, the technology decisions (model choice, platform choice, provider lock-in) will matter less over time than the operating-model decisions (who owns the schema, who chairs the CoE, who has the authority to defund a stalled pilot). Among the enterprises we work with, most are still funding AI as a technology investment while the bottleneck is already shifting to operating-model investment.

The architectural read for me is direct. The Operational Front Door reference architecture (linked above) is the architecture layer beneath the operating model the playbook describes. Both pieces argue the same thing from different altitudes: the orchestration layer becomes a new control plane for enterprise work, and the architecture you build for it determines who owns the politics for the next decade.

Adopting this playbook does not eliminate the architect's responsibility for schema ownership, integration design, deterministic-tooling boundaries on high-stakes calculations, or for the political work of enforcing decisions across team lines that have never shared a contract. The playbook gives you vocabulary and operating cadence. It does not give you the authority, the schema, or the integration substrate the patterns presuppose.

The playbook is worth reading. It is the most operating-model-centric Microsoft framework I have seen, and that is the right framing for the next 18 months of enterprise AI work. The framework's gaps (organizational politics, schema enforcement, Executive Sponsor reality, Tier 0 invisibility, surface-maturity calibration) are honest gaps. They are where the practitioner work begins.

The Scale-Breaker Microsoft Doesn't Name: Why Your AI Program Stalls Where the Playbook Doesn't Look (2026)

Alex Pechenizkiy — Sun, 09 Aug 2026 14:27:09 +0000

Microsoft's 2026 Agentic Transformation Patterns Playbook names a useful 5x5 maturity model: five capability drivers (AI Strategy & Experience, Business Strategy, Governance & Security, Technology & Data, Organization & Culture) scored on five levels (100 Initial → 500 Optimized). The framework's most operationally useful concept is the "scale-breaker": your weakest capability driver becomes your ceiling, regardless of how strong the others are. Find the gap. Invest there first. (The playbook actually uses the term two ways: this weakest-driver ceiling, and a separate Top 5 list of warning signals like "many pilots, no portfolio" and "shadow agents appearing." I am extending the first sense.)

The model is good. The diagnostic works. But there is a sixth capability driver the framework does not name and does not measure, and in my experience it is the scale-breaker I hit most often in enterprise AI programs. It is political maturity, and it sits underneath all five of the named drivers.

This is the contrarian read on the playbook's maturity model. The framework decode is here if you want the full walk.

The argument in one sentence

The 5x5 maturity model has 25 cells. None of them measure whether your organisation has the political capital to enforce a decision across team boundaries that have never shared a contract. That is the scale-breaker the framework does not look at and the one that stops most enterprise AI programs.

The Five Named Drivers

The playbook's five drivers are real and matter. Before naming the sixth, give the framework its due:

Driver	What it measures	Why it matters
AI Strategy & Experience	Strategic clarity, prior AI delivery, in-house AI literacy	Defines what the organisation is trying to do and how much existing capability it can build on
Business Strategy	Alignment of AI investment to measurable business outcomes	Without business-outcome alignment, AI work becomes technology theatre
Governance & Security	Risk management, identity, content safety, compliance posture	Determines what classes of work the organisation can responsibly accept
Technology & Data	Data platform maturity, integration discipline, infrastructure governance	The substrate that all agent work runs on; weakness here caps everything
Organization & Culture	Change-management capability, adoption discipline, leadership AI fluency	Determines whether deployed agents become used or shelved

Each of these is necessary. The playbook is right to score them and right to call out the scale-breaker concept. An enterprise sitting at 100/300/400/200/100 across the five drivers cannot scale Pattern 4 (which needs 500/500/400/400/400) because the two 100s drag everything down, regardless of how strong the 400 in Governance is.

The model's diagnostic value is that it forces conversation about uneven capability. Most enterprises score consistently uneven (strong in some drivers, weak in others) and the model makes the unevenness explicit. That part is genuinely useful.

What the model does not capture is the sixth driver underneath.

The Sixth Driver: Political Maturity

Political maturity is the organisation's capacity to make and enforce decisions that cross team boundaries. It is the capacity to settle disputes between business units that have competing priorities. It is the capacity to defund a high-visibility pilot that is not producing results. It is the capacity to require a domain team to consume a central standard against its preferences. It is the capacity for the Executive Sponsor to use authority when the situation requires it, not just when the situation is comfortable.

None of these capacities are measured by the 5x5 maturity model. They are not part of AI Strategy (which measures clarity of intent, not capacity for enforcement). They are not part of Business Strategy (which measures alignment, not authority to override). They are not part of Governance & Security (which measures controls, not the political will to apply them). They are not Technology & Data (which measures infrastructure, not authority over it). And they are not Organization & Culture (which measures change-management capability, not the underlying capacity for cross-team decision-making that change-management depends on).

Political maturity sits underneath all five. It is what makes the five drivers actually move in production rather than on a slide deck.

Where Political Maturity Bites

Five places in any AI program where the absence of political maturity stops the work:

The schema-ownership decision. The architecture pattern that lets Execute-mode agents work is a canonical work-object schema owned by a named person with authority across the systems the agent touches. Naming that person is a political decision. In most enterprises every team's local schema is sacred and no one wants to be the team whose schema gets overridden. Without political capital, the canonical schema is never named, the agent does the schema reconciliation in inference, and the integration is brittle. The AI orchestration over legacy systems reference architecture names schema ownership as the architectural foundation; political maturity is what lets that foundation get poured.

The defunding decision. In my experience most agent programs have at least one pilot that has been "almost ready" for the better part of a year. The CoE quarterly review notes the pilot. The Executive Sponsor knows it is stalled. The team running the pilot believes they are close. Without political maturity, the pilot continues consuming budget and attention indefinitely. With political maturity, the pilot is named as done, archived, and the team is redeployed. In my experience, most CoE failure cases I have seen trace back to inability to make this decision.

The reuse mandate. The framework's CoE model defines three structures (Centralized, Hybrid, Federated), and in the Centralized structure one team sets the rules, delivers, and monitors. My read is that reusable standards naturally live in that Centralized column, but putting them there only works if domain teams can be told they cannot do it their own way. Standardisation requires exactly that conversation. Domain teams that already have working informal patterns will resist. Without political capital, the central standards are published but not enforced; teams politely ignore them and continue with their local approaches.

The vendor-selection enforcement. Once the enterprise has standardised on a model provider, a CoE structure, or a deployment pipeline, ongoing enforcement requires saying no to teams that want to use a different vendor for legitimate-sounding reasons. The new VP wants Pega instead of Logic Apps. The acquired business unit wants ServiceNow instead of Dataverse. The senior engineer who left wants to use LangChain instead of Foundry. Each individual case has reasonable arguments. Without political capital, exceptions accumulate and the standardisation erodes one decision at a time.

The escalation closure. Cross-team disputes about agent ownership, data residency, evaluation thresholds, and incident response will reach the Executive Sponsor for resolution. The framework assumes the Executive Sponsor will resolve them. In practice the resolution requires choosing between two senior leaders who both have legitimate positions. Without political capital, the Executive Sponsor defers, the dispute remains open, the agent work that depends on resolution stalls, and the cadence becomes a graveyard of unresolved escalations.

Every one of these is the same root pattern: a decision is required, the framework names the role responsible for the decision, and the role-holder does not have the political capacity to actually make it.

Why the Framework Does Not Name It

Microsoft's playbook is, by design, a vendor-published framework. Vendor frameworks have to be portable across customer organisations. Political maturity is a customer-specific property that varies enormously across organisations of similar size and similar tech stack. Naming it as a driver would force the playbook into difficult diagnostic territory ("how politically mature is your organisation?") that no vendor framework can credibly address.

The framework's silence on political maturity is therefore reasonable. Microsoft cannot publish a maturity model that grades customer politics. What the framework cannot do, the practitioner read has to do for itself.

The Sixth-Driver Test

The diagnostic for political maturity is not a scored cell in a matrix. It is a behavioural test. Five questions to ask honestly:

1. Can your Executive Sponsor defund a high-visibility pilot?

Test: in the last 24 months has the Executive Sponsor (or their predecessor in the same role) explicitly told a senior leader "the pilot you championed is being shut down because it is not producing"? If yes, political maturity exists. If no, either the sponsor has never had to make the decision (small program) or has chosen not to (insufficient political capital).

2. Has your organisation named a single canonical owner for a contested data domain in the last 5 years?

Test: customer master data, employee data, financial transaction data, or product catalogue data. Has the organisation explicitly named one team's version as canonical and required the other teams to consume it? If yes, the political infrastructure for schema ownership exists. If no, every contested domain still has 3+ competing canonical versions and the AI agent will do reconciliation in inference.

3. Does your existing software-delivery operating model enforce architecture standards, or are standards advisory?

Test: when a team wants to use a non-standard tool or pattern, does the architecture review board have the authority to say no, or does the conversation end with "we'll allow this exception"? If standards are enforced, the AI CoE's architecture mandates will hold. If standards are advisory, AI CoE mandates will erode the same way.

4. When two business units have competing priorities, does the organisation produce a clear resolution within one quarter?

Test: name the most recent cross-business-unit dispute about resource allocation. Was it resolved in a quarter? Or is it still open six quarters later? Cross-business-unit AI decisions (agent ownership, data sharing, eval threshold-setting, incident response) will surface this exact dynamic.

5. Does the organisation make hard role-clarity calls when functions overlap?

Test: in the last 18 months, has the organisation explicitly resolved an overlap between two functions (e.g., "agent product management sits in Product, not in IT") rather than leaving the overlap to be sorted out informally? AI work is full of these overlaps: who owns Agent Product Owners, where Eval-dataset curation reports, whether Adoption Leads sit in HR or in business units. Without political maturity, every overlap is left to drift.

If you score 4-5 out of 5 on this test, your organisation has the political maturity to make the framework work as described. If you score 2-3, you have selective political maturity; the framework will work in some areas and stall in others. If you score 0-1, naming the political maturity gap explicitly is the first piece of work before standing up the AI program.

What to Do When Political Maturity Is Low

Three patterns work in low-political-maturity environments. The framework still has value; the application has to adapt.

Build agents that do not require cross-team enforcement. My read of Pattern 1 (Employee Enablement) and Pattern 2 (Business Expert Empowerment) is that they can succeed entirely within a single business unit without requiring cross-team political decisions. The schema is local to the unit; the eval is owned by the unit; the deployment is contained. This is the right place to start when political maturity is low.

Make the political work visible. When a decision requires political maturity that does not exist, name the gap explicitly in the operating cadence: "this agent requires cross-team schema ownership which we have not been able to assign; the agent is blocked on that political decision, not on engineering." Make the political bottleneck visible so it gets addressed, not absorbed.

Earn enforcement authority one delivered outcome at a time. Political capital is built by delivering visible value with the resources you have, then turning that visibility into authority for the next decision. The first agent that ships with cross-team integration despite political headwinds earns the CoE the credibility to require the next agent to use the canonical schema. The work is sequential, not parallel.

The Honest Read for the Steering Committee

If your AI program has stalled at Pattern 2 or Pattern 3 despite reasonable scoring on the 5x5 maturity model, the bottleneck is probably not in the model. It is probably political maturity. Take that finding to the steering committee with specificity: which decision is stalled, which role-holder would normally make it, what political precondition is missing.

The framework gives you vocabulary and structure. The framework does not give you authority. Authority is the precondition for the framework to produce outcomes, and it is the one capability driver no vendor will ever score in a matrix.

Risk-Tiered Agent Governance: Microsoft's Tier 1/2/3 Model Annotated for Real Deployments (2026)

Alex Pechenizkiy — Sat, 08 Aug 2026 14:24:23 +0000

Microsoft's 2026 Agentic Transformation Patterns Playbook is, in my read, the cleanest enterprise governance writing on AI agents to date. The risk-tier framework in particular (page 46) is portable to most existing risk-management practice. Three tiers, proportionate controls, sound principle. The framework names the controls at the right altitude; this piece extends them down to the operational layer, names the tooling, defines the cadence, and adds the Tier 0 the playbook does not surface.

If you have read the practitioner decode of the playbook, this is the depth read on the governance chapter.

The Playbook's Three Tiers (Source Frame)

The playbook splits agents into three risk tiers based on what the agent does and who it affects.

Tier	What it covers	Required controls (playbook framing, lightly paraphrased)
Tier 1: Low Risk	Individual productivity agents (drafting, summarisation, research)	Named owner. Basic monitoring. Standard release checklist. Self-service deployment within guardrails.
Tier 2: Medium Risk	Expert knowledge agents and internal service agents	Named owner plus domain expert validator. Knowledge quality monitoring. Formal release gate with review. Accuracy tracking and feedback loops.
Tier 3: High Risk	Business-critical and external-facing agents	Named owner plus formal process owner. Production-grade SLA monitoring. Security review plus responsible-AI assessment. Decision rights framework. Incident response plan. Quarterly maturity review.

The principle is right. Over-governing low-risk agents kills adoption. Under-governing high-risk agents creates liability. Proportionate controls match the risk surface to the operational discipline.

What the framework leaves at framework altitude (which is reasonable for a published framework) is the concrete operational layer beneath each control. This piece annotates each tier with what the controls mean in practice, what tooling supports them, what cadence they need, and how to operationalise the tier classification itself.

The specific thresholds and time-boxes below (the >90% source-grounding bar, the 10-50 sampled responses, the 15-90 minute review windows) are starting points to calibrate to your volume and risk appetite, not Microsoft-prescribed values. Treat them as illustrative anchors, not settled numbers.

Tier 1 (Low Risk): Productivity Agents

Examples that fit this tier: an M365 Copilot use case drafting an email, a meeting-summary agent in Teams, a research assistant that pulls together a briefing from internal documents, a personal "draft my response" agent for support tickets, a code-completion helper for internal scripts.

Examples that do not fit this tier (and many will mistakenly land here): any agent that writes to a system of record, any agent that operates on customer data outside the user's own scope, any agent that automates a workflow that previously had explicit approval steps. These are not Tier 1 even if they feel lightweight.

Concrete controls

Named owner: who and what authority. A single person, named in the agent registry, accountable for the agent's lifecycle. For Tier 1 the owner is typically the team lead or the IT enablement lead for the business unit. Authority: can pause the agent, can request changes from the team that built it, can escalate to Tier 2 review if the agent's scope expands.

Basic monitoring: what to actually monitor. Usage telemetry (number of invocations per user per week), basic error rate (failure to produce output), and user-feedback signal (thumbs up/down or equivalent if the surface supports it). Tooling: M365 admin telemetry, Copilot Studio analytics, or equivalent platform-native dashboards. Cadence: monthly review at the business-unit level.

Standard release checklist: what to include. Five items: (1) agent description in plain language, (2) named owner, (3) data sources confirmed appropriate for the tier, (4) basic monitoring wired up, (5) prompt or configuration reviewed by one peer. The checklist takes 15-30 minutes per agent. Anything heavier is over-governance for Tier 1.

Self-service deployment within guardrails: where the guardrails actually sit. Tenant-level DLP policies, content-safety defaults, model-selection allowlists, and connector approval lists. These are platform configurations set once by the central platform team, not per-agent decisions. Documented in the Power Platform governance pattern.

Escalation triggers (when Tier 1 becomes Tier 2)

A Tier 1 agent becomes Tier 2 when any of these conditions are met:

Usage extends beyond the original team to other business units
The agent starts being used to make decisions that affect others (recommendations that get acted on without review)
The agent's data sources expand to include customer data, regulated data, or cross-business-unit data
A specific incident reveals impact wider than the original tier assumed

The escalation is mechanical, not subjective. The named owner triggers the review when any condition is met. The review confirms or adjusts the tier.

Tier 2 (Medium Risk): Expert and Internal Service Agents

Examples that fit this tier: an HR policy Q&A agent answering employee questions, an IT helpdesk first-line agent handling password resets and basic troubleshooting, a finance agent answering expense-policy questions, a compliance agent surfacing regulatory interpretation, an engineering standards agent helping developers find the right pattern.

Examples that do not fit this tier: anything customer-facing (that is Tier 3), anything that orchestrates a complete workflow (often Tier 3), anything that touches systems with financial or regulatory exposure (often Tier 3 even if it feels internal).

Concrete controls

Named owner plus domain expert validator. Two named people. The owner accountable for the lifecycle (usually a Service Owner or Team Lead). The domain expert validator accountable for content correctness (the subject-matter expert who would otherwise have answered the questions the agent answers). Authority for the validator: can require knowledge-base updates, can require prompt changes, can mark agent responses as wrong and trigger an investigation.

Knowledge quality monitoring: what to measure. Three signals: response accuracy (sample-based human review of N responses per week, typically 10-50 depending on volume), source-grounding rate (percentage of responses that cite their source from the approved knowledge base, threshold >90%), and user-correction signal (cases where users flag a response as wrong, with the trend tracked over time). Tooling: typically a combination of Foundry's evaluation surface, an internal review interface, and a flagging mechanism in the agent UI.

Formal release gate with review: what the review covers. Three reviewers: the named owner, the domain expert validator, and a Security/Risk integrator. The review checks: (1) eval results pass the agreed thresholds, (2) knowledge sources are approved and current, (3) no scope creep since the previous release, (4) any incidents from the previous release have been addressed. Cadence: at every release, no exceptions. Time: 60-90 minutes for the first review of a new agent; 20-30 minutes for routine releases of an existing agent.

Accuracy tracking and feedback loops: what to wire up. A monthly accuracy report keyed to the agent, with trend lines for accuracy, source-grounding, and user-correction rates. A feedback-to-knowledge-base loop: corrections from the validator flow back into the knowledge source and into the eval dataset. A monthly cross-validator session where validators across multiple Tier 2 agents share findings.

Escalation triggers (when Tier 2 becomes Tier 3)

A Tier 2 agent becomes Tier 3 when:

The agent starts writing to systems of record (creating tickets, updating cases, sending external communications)
An incident reveals customer impact (even if internal-facing, the consequences reached customers)
The agent's scope expands to include high-stakes operational decisions (eligibility, authorisation, monetary impact)
Regulatory exposure changes (new regulation applies to the domain the agent operates in)

Tier 3 (High Risk): Business-Critical and External-Facing

Examples that fit this tier: customer-facing support agents, claims-processing agents, eligibility-determination agents, agents that send communications to external parties, agents that authorise financial transactions, agents in regulated industries operating on regulated workflows.

Concrete controls

Named owner plus formal process owner. Two named people. The owner accountable for the agent's technical lifecycle. The process owner accountable for the business outcome the agent supports (the senior operations leader who would otherwise own the workflow). Authority for the process owner: can defund the agent, can require workflow redesign, can mandate manual fallback if agent quality degrades.

Production-grade SLA monitoring: what counts. Latency p50/p95/p99 by agent endpoint, error rate by endpoint, eval-result trend on continuous-evaluation samples, end-to-end workflow outcome metrics keyed to business KPIs. Tooling: OpenTelemetry traces to Azure Monitor with custom dashboards per agent, application-insights alerting on threshold breaches, on-call rotation that owns the agent endpoint same as any other production service.

Security review plus responsible-AI assessment. Security review: standard application-security review extended for the AI-specific surfaces (prompt injection vulnerability, model-output validation, downstream-system blast radius). Responsible-AI assessment: bias evaluation against representative population samples, harm-pattern testing, content-safety validation, accessibility review for affected populations. Cadence: at every major release, on-demand for incidents, at scheduled intervals (annual minimum) even without changes.

Decision rights framework. Documented matrix: for each class of decision the agent makes, who has authority to approve the underlying policy, who has authority to roll back the agent if the policy is being applied wrong, and who has authority to override individual decisions on appeal. This is operational governance, not framework slideware. The matrix has to be readable by an auditor and explicit enough to act on during incidents.

Incident response plan. Specific to AI-agent incidents: how to roll back the active agent version (using the AgentOps CI/CD pattern), how to switch to manual workflow fallback, how to communicate with affected customers, how to investigate the root cause (eval-result inspection, traffic-sample replay, prompt-and-tool-call audit), how to file the regulatory disclosure if required. Run a tabletop exercise quarterly.

Quarterly maturity review. Three-month review of: SLA performance against targets, incident review, eval-result trend, scope-creep audit, regulatory compliance audit, customer-impact review. Output: explicit decision to continue, modify, or retire the agent. This is where the political maturity from the scale-breaker discussion shows up. The review has to be able to produce a "retire" decision when warranted.

Three Tier 3 controls I would add beyond the playbook

In my experience three things every Tier 3 agent needs are easy to miss, and the playbook leaves them implicit:

A defined manual fallback. When the agent has to be paused (incident, eval degradation, compliance review), the business workflow must continue. The fallback is a fully documented manual process with named operators ready to take it on. Without the fallback, pausing the agent is impossible without unacceptable business impact, and the agent ends up running through incidents rather than being paused.

A change-of-context discipline. Tier 3 agents operate on context that changes (regulations update, business rules shift, customer populations evolve). A defined process for evaluating whether contextual changes require agent re-validation, with named owners triggering the re-validation, prevents the slow drift that makes a Tier 3 agent quietly become non-compliant over six months.

A model-deprecation rollback plan. Tier 3 agents are particularly exposed to provider-side model deprecation (the AgentOps decode names this gap). A defined plan for re-evaluation when the model version changes, with a rollback path if the new model fails the same thresholds, must exist before the agent enters production.

Tier 0: The Tier the Playbook Does Not Name

The playbook's three tiers cover agents that exist inside the enterprise governance perimeter. They assume the agent has been registered, owned, and classified.

My read is that the most consequential governance gap in 2026 enterprise AI is the agents that exist outside the perimeter. The playbook does not make this argument; it is the inference this piece adds. Tier 0 is the set of agents your governance plane does not see.

What Tier 0 includes

Agents in personal Copilot subscriptions (employees signing up for Copilot Pro with personal email accounts, using it for work tasks)
Agents in third-party SaaS that includes its own AI features (CRM with built-in AI, support tool with AI agent, productivity SaaS that added AI)
Agents built and deployed by individual employees using consumer AI APIs and connected to work data through plugins or browser extensions
Agents in acquired business units running on different tech stacks not yet integrated into central governance
Agents in shadow IT (deployments by business units circumventing central IT)

Why Tier 0 is the highest-priority governance work

Tier 0 agents are operating on work data, producing work outputs, and affecting work decisions, just like the Tier 1-3 agents. The difference is they are invisible to the governance plane. The Tier 1-3 controls do not apply because the agent does not exist in the inventory.

The risks: data leakage (work data going to consumer AI surfaces with consumer terms of service), regulatory exposure (work decisions made by agents that have not been risk-assessed), reproducibility breakdown (agents that disappear when an employee leaves or when a personal subscription lapses), audit failure (the regulator asks for the agent inventory and the answer is incomplete by an unknown amount).

Controls for Tier 0: discovery before governance

You cannot govern what you cannot see. Tier 0 controls are about discovery first.

Network egress monitoring with AI-surface detection. Endpoint and network telemetry that flags traffic to known AI providers (OpenAI, Anthropic, Mistral, third-party AI SaaS surfaces) and to personal subscription endpoints for known AI products. Tooling: existing CASB and SIEM extended with AI-provider categorisation. Output: weekly report of AI-surface usage by user, with anomaly detection on volume and pattern.

Tenant-level AI inventory crawl. For Microsoft tenants: scheduled crawl of Microsoft Graph for Copilot usage by license type, distinguishing tenant-licensed Copilot from personal Copilot accessing work data. For other SaaS: API-level inventory of AI features in connected SaaS, with periodic re-discovery as SaaS vendors add new AI features.

Browser-extension policy enforcement. Managed browser policy preventing installation of AI plugins not on the approved list. For BYOD scenarios, awareness training plus DLP at the network level.

SaaS connector approval gate. Approved-vendor list for SaaS with AI features, with new SaaS requiring tier classification before connecting to work data.

Shadow-IT amnesty programme. Periodic (typically annual) amnesty programme inviting business units to declare their AI deployments without consequence, in exchange for governance integration. This is faster than discovery alone and surfaces deployments that central governance would otherwise miss for months.

See Shadow AI Governance for Microsoft Enterprises: Discovery to Control for the deeper read on the discovery problem.

Operationalising the Tier Classification

The framework gives you three tiers (four with Tier 0) and concrete controls. The remaining operational question is how to assign tiers consistently across an agent fleet of 10, 100, or 1,000+ agents.

The pattern that works is a tier-decision tree, evaluated at the agent intake gate, by the named CoE intake reviewer. Six binary questions:

Does the agent write to any system of record? → if yes, Tier 2 minimum
Is any output of the agent customer-visible or partner-visible? → if yes, Tier 3
Does the agent operate on regulated data (HIPAA, GDPR scope, PCI, etc.)? → if yes, Tier 3 minimum
Does the agent make decisions with financial or contractual consequences? → if yes, Tier 3 minimum
Does the agent operate on cross-business-unit data? → if yes, Tier 2 minimum
Is the agent's output acted on without human review? → if yes, escalate by one tier from the answer above

Precedence matters when more than one question fires. Evaluate Q2 to Q4 first (any yes sets Tier 3), then Q1 and Q5 (which set a Tier 2 minimum), then take the highest tier those produce, and apply Q6 last as a single +1 escalation on top of that result. Q6 never lowers a tier; it only raises it.

In our experience the decision tree produces a tier in roughly 5 minutes. The tier classification is reviewed at the formal release gate. Tier changes between releases trigger re-review.

A common failure mode: organisations classify agents at Tier 1 to avoid the heavier controls, then discover the agent is actually doing Tier 2 or Tier 3 work after a scope creep or an incident. The decision tree applied honestly prevents this. The named intake reviewer should be senior enough to override a team that wants to under-classify.

The Honest Read for the Steering Committee

The risk-tier framework is the part of the playbook most directly portable to existing risk-management practice. Use it. Add Tier 0 to the model from day one. Use the decision tree to keep tier assignment honest. Treat Tier 3 controls as production-engineering discipline, not as governance overhead. Run the discovery work for Tier 0 as a parallel workstream, not as a one-time project.

The governance work is not heroic. It is the boring, repeatable discipline that prevents the visible failures the headlines will eventually write about whichever enterprise was the first to skip it.

The Pilot Trap: Why Most Agent Initiatives Never Become Portfolio (2026)

Alex Pechenizkiy — Fri, 07 Aug 2026 14:47:08 +0000

Microsoft's 2026 Agentic Transformation Patterns Playbook lists "many pilots, no portfolio" as the first of five scale-breakers most enterprises hit. The framework is right. In our observation of mid-sized to large enterprises through the back half of 2026, roughly 80-90% of agent pilots either fail outright or settle into a permanent pilot state. They are not retired. They are not scaled. They consume budget at low levels, occupy attention at irregular intervals, and never graduate to portfolio status with the discipline that production work demands.

This is the practitioner read on why the trap exists, how to recognise that you are in it, and what graduating from pilot to portfolio actually requires.

If you have read the practitioner decode of the playbook, this is the depth read on the first scale-breaker.

The diagnostic in one paragraph

In our observation you are in the pilot trap when your enterprise has 5+ AI agent pilots, no clear portfolio owner, no defunding decision in the last 12 months despite at least one stalled pilot, no shared infrastructure across the pilots, and no quarterly review that produces explicit go/no-go decisions. This is the modal state of enterprise AI in mid-2026.

Why Pilots Stall

Pilots stall for predictable reasons. None of them are individually catastrophic. Together they constitute the pilot trap.

No portfolio owner with defunding authority. The pilots get authorised individually, often by different sponsors in different business units. No one person has authority over the portfolio of pilots collectively. When a pilot stalls, no one has the standing to defund it. It continues consuming a low level of attention and budget indefinitely.

No shared infrastructure investment. Each pilot stands up its own environment, its own evaluation patterns, its own deployment scripts, its own monitoring. The marginal cost of the next pilot is therefore as high as the first. Pilots cannot accelerate by building on each other's work. The economics never improve.

No measurable success criteria from the start. The pilot is authorised on the basis of "let's try Copilot for [team X]" or "let's see what we can do with agents in [function Y]" without explicit success criteria. When the pilot runs for 4-6 months, in our experience, without a clear answer to "did this work," the pilot continues by inertia rather than by graduation.

No graduation path defined. Even when the pilot is successful, there is no defined path from pilot status to portfolio status. The team running the pilot does not know what they need to demonstrate to graduate. The CoE does not know what they would need to see to authorise graduation. The pilot continues at pilot maturity because no one has named what production maturity would require.

No defunding criteria. Just as graduation is undefined, retirement is also undefined. A pilot that produces no clear value also has no clear path to retirement. It quietly continues, consumes attention, and absorbs budget that could fund the next attempt.

Demo theatre wins over honest assessment. The pilot demos well. The team is invested in the pilot's continuation. The honest assessment ("this is not producing the value we hoped") is uncomfortable for everyone. The cadence accommodates this by celebrating partial progress rather than measuring against the original success criteria.

What "Portfolio" Actually Means

The framework uses "portfolio" loosely. Operationally, portfolio status means an agent has crossed five thresholds that pilot status does not require:

Threshold	Pilot status	Portfolio status
Named owner with cross-team authority	Team lead or sponsor; authority within the team only	Agent Product Owner with cross-team authority defined explicitly
Measurable success against business KPIs	Often implicit; success = pilot continues	Defined business KPIs reported quarterly; agent retired if KPIs missed two quarters running
Production-grade infrastructure (CI/CD, evaluation, monitoring)	Often ad-hoc; deployed from a notebook or a one-off script	Full AgentOps pipeline with evaluation gates, multi-environment promotion, rollback capability
Risk-tier classification and tier-appropriate controls	Often Tier 1 by default regardless of actual risk	Explicit tier classification with tier-appropriate controls implemented and audited
Incident-response plan and on-call coverage	Best-effort; if it breaks, someone notices eventually	Defined incident response, named on-call, post-incident review process; manual fallback documented for Tier 3

Portfolio status is a substantial investment per agent. The discipline a pilot can defer with low cost is exactly the discipline a portfolio agent must have in place. The graduation work is real and it has to be funded explicitly.

The Three Patterns That Work

In our observation, three patterns produce reliable pilot-to-portfolio graduation:

Pattern 1: The Portfolio Owner with Authority

Name one person whose role is "owner of the agent portfolio." This person has authority across all pilots: to authorise graduation, to require retirement, to consolidate redundant pilots, to direct shared-infrastructure investment. The role is typically a senior CoE Lead or an equivalent senior product/platform leader. The role's existence and authority is the single most important pattern. Without the role, no other pattern stabilises.

The role's authorities, made explicit:

Quarterly review of every pilot with graduate/continue/retire decision
Authority to direct the shared-infrastructure roadmap
Authority to consolidate redundant pilots (when two business units have similar pilots, the portfolio owner can require consolidation)
Authority to defund (with notice and process) any pilot that has been stalled for two consecutive quarterly reviews
Budget authority for the portfolio's shared-infrastructure investment

Pattern 2: Shared Infrastructure Investment as a Platform Discipline

The marginal cost of the next pilot should be a fraction of the first. This requires shared infrastructure investment: the Foundry CI/CD pipeline, the evaluation harness, the monitoring dashboards, the deployment scripts, the risk-tier templates, the incident-response patterns. Build them once, reuse them for every subsequent pilot.

The platform-engineering investment is, in our experience, roughly 1-2 FTEs of dedicated platform work over a 6-12 month period to build the shared infrastructure. Treat that as a starter you should calibrate to your environment, not a Microsoft figure. Without this investment, each pilot reinvents the wheel and the program never scales economically.

This is operationally similar to how DevOps platform teams build shared CI/CD platforms for application engineering. The agent equivalent uses the same principle: invest in shared substrate once, treat the next deployment as a configuration on the substrate.

The substrate here happens to be Foundry because that is the Microsoft path this playbook describes, but the discipline is substrate-agnostic. The same portfolio economics apply whether your shared layer is Foundry, a LangGraph or own-built stack, or a mixed-model fleet. The operating model, not the vendor, is what breaks the per-pilot cost spiral.

Pattern 3: Quarterly Portfolio Review with Explicit Decisions

Every quarter, every pilot and every portfolio agent gets reviewed. The review produces an explicit decision: continue (with named milestones for the next quarter), graduate (with the graduation work explicitly funded), or retire (with the retirement process owned). No fourth option.

The discipline of forcing an explicit decision every quarter is what prevents the indefinite-pilot pattern. Most pilots do not deserve to continue indefinitely. Forcing the decision surfaces the ones that do not.

The review has to be attended by the Executive Sponsor or by someone with their delegated authority. Without senior attendance, the review devolves into status reporting rather than decision-making.

The Anti-Patterns to Recognise

Three anti-patterns trap enterprises in the perpetual-pilot state.

The pilot factory. The CoE or transformation function authorises new pilots faster than it retires old ones. The pilot inventory grows. The infrastructure investment per pilot stays low. The graduation rate stays low. The portfolio never materialises. The CoE looks busy from the slide deck (many pilots) but produces little operational value.

The lighthouse pilot that never extends. The CoE picks one flagship pilot, invests heavily in it, ships it to production with full discipline, and showcases it as proof the program works. The pilot is genuinely successful. The flagship investment, however, does not transfer to other pilots. The shared infrastructure that supports the flagship is too custom to reuse for other agents. The next ten pilots restart from scratch. The flagship becomes a one-off rather than a template.

The vendor-led pilot suite. A vendor (often Microsoft, often a systems integrator) leads several pilots in parallel as part of an engagement. The pilots run well during the engagement. When the engagement ends, the in-house team cannot maintain them. The pilots degrade or are retired without producing the in-house capability that would let the enterprise run agents independently.

Each anti-pattern produces visible activity without producing portfolio. The remedy is the same as the success pattern: the Portfolio Owner with authority who can recognise the anti-pattern and redirect investment.

The Graduation Test

A pilot is ready to graduate to portfolio when it can demonstrate all of the following at the quarterly review:

The pilot has produced measurable business value against pre-defined KPIs (not just usage; outcome)
The pilot has a named Agent Product Owner who can take it to production
The pilot can be re-implemented on the shared infrastructure (Foundry CI/CD pipeline, evaluation harness, monitoring) without requiring a custom rebuild
The pilot has a risk tier classification and the tier-appropriate controls can be implemented
The pilot has executive sponsor commitment to fund the graduation work explicitly
The pilot's failure modes have been characterised and the response plan is defined

A pilot that meets all six can graduate. A pilot that meets four or five can stay in pilot for another quarter with explicit milestones for the gaps. A pilot that meets three or fewer should be retired honestly. The discipline of applying the test the same way to every pilot is what produces a portfolio.

The 90-Day Move If You Are In The Trap

If you have read this far and recognise your organisation in the pilot-trap description, three actions in the next 90 days will start moving the program out of the trap:

Days 0-30: Inventory and triage. Run a complete inventory of every AI pilot in the enterprise: who sponsors it, who runs it, what it does, what stage it is at, what success metrics were defined originally, what value it has produced. Triage into three buckets: candidates for graduation (the strongest 1-3), candidates for retirement (the weakest), candidates for continuation with explicit milestones.

Days 30-60: Name the Portfolio Owner and the first graduation. Appoint the Portfolio Owner explicitly with the authorities listed above. Pick one pilot as the first graduation candidate. Begin the graduation work (Agent Product Owner assignment, AgentOps pipeline setup, risk-tier classification, incident-response plan) with explicit funding and a named due date.

Days 60-90: Begin the shared-infrastructure investment. Allocate 1-2 FTEs to begin building the shared infrastructure (CI/CD pipeline template, evaluation harness template, monitoring dashboard template). The first deliverable: the pipeline that supports the first graduating agent. The second deliverable: the pipeline templated so the second graduating agent reuses most of the work rather than rebuilding it.

In the same 90 days, retire at least one pilot honestly. The act of retiring a pilot demonstrates that the framework works and creates the precedent that the program is willing to make hard calls. Without at least one retirement, the discipline does not stick.

What This Looks Like When It Works

An enterprise that has escaped the pilot trap looks different from the inside in five specific ways:

The agent inventory is small (in our experience roughly 3-7 portfolio agents, not 15+ pilots) and the agents in the inventory are in active production with measurable outcomes
The Portfolio Owner is named and attends every steering committee with a current portfolio status
The shared infrastructure (CI/CD pipeline, evaluation harness, monitoring) is in use across multiple agents; new agents deploy on the substrate without rebuilding it
Quarterly reviews produce explicit decisions on every agent; retirements happen at a steady rate rather than never (in our experience, roughly one retirement per year per handful of portfolio agents, but calibrate that to your own program)
The next pilot is authorised against an explicit hypothesis with named success criteria, named graduation path, and committed graduation budget

This shape is achievable. In our experience it is roughly what mature enterprise AI programs look like once they have been running for a couple of years with explicit portfolio discipline, though the timeline varies with how aggressively the organisation applies the graduation test. The gap between this shape and the modal pilot-trap shape is operational discipline, not technical capability.

The Honest Read

The pilot trap is not a technology problem. It is an operating-model problem. Microsoft's framework correctly identifies it as the top scale-breaker. The remedy is operating-model discipline: name the Portfolio Owner with real authority, invest in shared infrastructure, run the quarterly review with explicit decisions, retire pilots that have stalled.

None of this is heroic. It is the boring repeatable discipline that distinguishes enterprises that produce real AI outcomes from enterprises that produce slide decks about AI. Whether your organisation can apply the discipline is the test that matters more than which agents you build first.

Don't Build an AI Center of Excellence Until You Read This (2026)

Alex Pechenizkiy — Wed, 05 Aug 2026 15:56:55 +0000

Microsoft's 2026 Agentic Transformation Patterns Playbook devotes its longest chapter to the AI Center of Excellence. The framework is sound on paper. It names six core CoE roles, four edge roles, three structural options (Centralized, Hybrid, Federated), and a 7-stage agent lifecycle (Intake to Retire), and it matches each structure to an adoption pattern. Most of the chapter is correct. The problem is the seven assumptions underneath the framework, none of which the document names, and all of which most enterprises will violate on day one.

This is the contrarian companion to the practitioner decode of the playbook itself. If you are about to set up an AI CoE in the next 90 days, this is the read that goes before the kickoff slide deck.

Who this is for

The CIO, AI program lead, or transformation lead who has been told to "stand up an AI Center of Excellence" and is sitting in front of the Microsoft playbook trying to map the framework to their org chart. The framework will work for some teams. It will fail in specific named ways for others. The seven failure modes below are how to tell which group you are in before you commit to the structure.

What the Playbook Gets Right

To be clear: Microsoft's CoE framework is the strongest enterprise-AI operating-model document in the market today. Three things in the chapter genuinely advance the conversation:

The matching of CoE structure to adoption pattern is correct and underdiscussed. The playbook matches each structure to a pattern: Centralized for Employee Enablement and External Engagement, Federated for Core Business Process and AI-First Capabilities once teams are mature. My read is that this implies an evolution path: as your dominant pattern matures from enablement to core-process transformation, structure should shift from Centralized toward Federated.

The decision-rights split between Centralize (HOW scale works: platform, security, architecture, release gates, risk classification) and Delegate (WHO builds: domain prioritization, agent design within standards, knowledge curation, day-to-day ops) is the single most actionable artefact in the chapter. Most CoEs centralize the wrong things and delegate the wrong things. The split corrects that.

The 7-stage agent lifecycle (Intake → Triage → Build → Deploy → Monitor → Improve → Retire) is the Scale function of the CoE framework (pages 35-48), mature change-management discipline applied to agents. In my experience it maps cleanly onto a standard RACI, though the playbook itself stops at the lifecycle stages and does not publish a RACI table. It plugs into existing enterprise governance cleanly.

The architecture is right. The problem is what the framework assumes about the enterprise that adopts it.

The seven assumptions in one line

Executive Sponsor with both budget and political capital · CoE Lead who can hire across functions · Agent Product Owners with cross-team authority · domain teams willing to surrender autonomy · Security/Risk integrated from day one · clean Power Platform CoE prerequisite · enough budget to staff before measuring ROI.

Most enterprises violate at least three of these on day one. The CoE structure is sound; the assumptions are where it breaks.

Assumption 1: The Executive Sponsor Has Both Budget AND Political Capital

The framework names Executive Sponsor as the first core CoE role. The role is described as setting strategic direction and securing funding. The unstated assumption is that this person has both the budget authority to fund the CoE through its foundation period (in my experience 18-24 months) and the political authority to defund stalled initiatives, settle cross-business-unit disputes, and enforce architecture decisions that some teams will resist.

In our experience, you have one or the other. Rarely both.

The CTO has the technical authority but often not the cross-functional political capital to require Marketing to use the standard agent pattern instead of its own. The Chief Digital Officer has the political capital but often not the technical literacy to read an eval report and call a pilot stalled. The Chief AI Officer (where the role exists) is often a senior IC promoted into a leadership role without the budget authority of a CFO-adjacent peer.

What to do: name the Executive Sponsor explicitly. Audit the role against the two-dimensional test (budget authority + political authority). If only one dimension is present, name a co-sponsor for the other. A single under-powered Executive Sponsor is worse than two co-sponsors with complementary authority because the framework relies on this person to break ties.

Assumption 2: The CoE Lead Can Hire Across Functions

The CoE Lead (also called AI Program Manager in the playbook) is described as the operating owner. The role description is straightforward: run the cadence, coordinate across CoE functions, report to the Executive Sponsor.

The unstated assumption is that this person has hiring authority across the six core CoE roles and the four edge roles. In most enterprises the Platform & Operations role reports into IT; Security/Risk/Compliance reports into a separate compliance function; Adoption Leads report into HR or the relevant business unit. The CoE Lead has dotted-line influence over most of them and direct hiring authority over none.

The framework treats the CoE as if it is a single team. In practice it is a matrix of people whose direct reports point elsewhere.

What to do: before you stand up the CoE, get explicit dotted-line agreements signed by the function heads (CISO, CHRO, business-unit GMs) that name the people who will spend a defined percentage of their time on CoE work. Without that explicit allocation, the CoE Lead is a coordinator without authority.

Assumption 3: Agent Product Owners Have Cross-Team Authority

The Agent Product Owner is the role most enterprises have not yet made. The playbook formalises it: someone who owns the agent's lifecycle, prioritisation, success metrics, and continuous improvement. Think Product Manager for one or several specific agents.

The unstated assumption is that this person has the authority to enforce schema decisions across teams that have never shared a contract, to require domain experts to maintain golden evaluation datasets, and to defund agent improvements that produce no measurable user value.

This authority does not exist by default. It comes from being granted explicitly by the Executive Sponsor and renewed by the operating cadence. Most enterprises will appoint the first Agent Product Owner from the team that owns the most visible agent, often without giving them explicit cross-team authority. The result is a Product Owner who can iterate the agent within their team but cannot enforce reuse, standards, or eval discipline outside their team.

What to do: in the formal role definition, name the authorities that the Agent Product Owner has. Specifically: authority to require schema input from named upstream teams, authority to set the agent's eval pass threshold, authority to mark a quarterly release as "do not promote" based on evaluation results. Without explicit authority, the role is a coordinator with extra reporting overhead.

Assumption 4: Domain Teams Will Surrender Some Autonomy

The CoE structure assumes that domain teams will accept centralised standards, reference architectures, release gates, and reuse mandates. In Federated mode the assumption is softer (CoE provides standards; business units own delivery within them). In Centralized mode the assumption is hard (CoE owns delivery; business units consume).

Most domain teams will resist the surrender of autonomy. Domain teams that built their first agent independently and shipped it to production are not eager to hand the next agent to a central team. Domain teams that have informal Copilot Studio adoption inside their business unit may already have working patterns they do not want overridden.

The framework treats this as a change-management problem. It is also a power-and-trust problem that change-management cannot solve alone.

What to do: name the things the CoE owns and the things domain teams own, and make the boundary explicit and small. The Centralize-versus-Delegate split in the playbook is the right starting point. Adapt it to your specific power dynamics. In a low-trust enterprise (recent IT failure, organisational restructure, leadership turnover) the CoE has to win earnest credibility one delivered agent at a time before it can require domain teams to consume its standards.

Assumption 5: Security and Risk Are Integrated From Day One

The framework names Security/Risk/Compliance as one of the six core CoE roles. The intent is clear: these functions are inside the CoE, not external reviewers.

The unstated assumption is that the enterprise has already integrated Security/Risk/Compliance into its existing software-delivery operating model with enough maturity that the AI-specific extensions (responsible AI assessment, content safety review, data-residency mapping, agent-identity governance) can layer on top.

Most enterprises have not done this for traditional software. Security review is a gate at the end of the project, not a partner during design. Risk classifications are documented but rarely enforced in deployment automation. Compliance review is reactive to incidents, not proactive in design.

If your existing software-delivery model treats Security and Risk as terminal gates, the AI CoE will repeat that pattern. AI work moves faster and breaks more visibly, which amplifies the cost.

What to do: before standing up the AI CoE, audit how Security and Risk integrate with your existing software delivery. If they integrate well, extend the same model to AI. If they integrate badly, fix the underlying model first. The AI CoE will not fix the underlying gap; it will make it more visible.

Assumption 6: The Power Platform CoE Foundation Already Exists

The framework treats the Power Platform CoE pattern as a prerequisite that most enterprises already have. The published Power Platform CoE Starter Kit is mature, well-documented, and widely adopted. If your enterprise runs Power Platform at scale and has the CoE pattern in place, extending it to AI agents is an additive read.

If you do not have a Power Platform CoE, you have a larger problem than the playbook describes. The AI CoE depends on:

Tenant-level governance posture (managed environments, DLP policies, capacity allocation)
Repo-and-pipeline discipline (source-controlled solutions, automated release gates)
Inventory and observability tooling (per-environment audit, application/solution registry)
An adoption-and-enablement motion (training, champions, community)

These are exactly what a mature Power Platform CoE produces. Without them, the AI CoE has to build all of them in parallel with the AI-specific work (eval-dataset curation, risk-tier classification, agent-version lifecycle). The 90-day timeline in the playbook becomes a 12-month timeline. Treat the playbook as Phase 2 of the work; Phase 1 is the Power Platform CoE foundation.

One thing the playbook understates: most enterprises already run non-Microsoft agents (OpenAI Assistants, LangChain services, third-party SaaS copilots). The CoE has to govern those too, or it governs only the half of the estate it can see, which collapses back into the Shadow AI problem.

Assumption 7: There Is Budget to Staff Before You Have ROI Receipts

The playbook names six core roles plus four edge roles but does not size headcount. From our experience, that translates to a rough, order-of-magnitude 4-8 FTEs for a mid-sized enterprise running light Pattern 3 work, scaling higher for larger orgs running Patterns 3-5. Treat that as a starter you should calibrate, not a published figure. Either way, it is a substantial investment.

The unstated assumption is that the organisation has budget authority to fund this staffing through the foundation period (18-24 months in my experience) before the AI program produces measurable ROI. In our experience the first 6-12 months of an AI CoE are foundation work: standing up environments, defining tier classifications, building eval datasets, setting up release pipelines, running training. ROI from production agents typically follows after.

Most enterprise budget cycles do not work this way. In our experience the CFO who approves 4-8 FTE positions will expect a return-on-investment narrative within roughly 12 months. If the CoE cannot produce measurable agent-delivered outcomes within that window, the budget gets cut at the next cycle, often before the foundation work is complete.

What to do: budget the CoE in two phases. Phase 1 (months 1-6) is foundation work, justified by capability building and risk reduction, not ROI. Phase 2 (months 6-12) is delivery work, justified by measurable outcomes from the first 2-3 production agents. Tie Phase 2 budget continuation to Phase 1 deliverables explicitly. The CFO will accept this structure if it is named upfront; the CFO will not accept it if it is presented as "trust us, ROI comes eventually."

The Seven Assumptions at a Glance

Here is the whole spine in one place: each assumption, what the playbook quietly assumes, what most enterprises actually have, and the fix.

Assumption	What the playbook assumes	What most enterprises have	Fix
1. Executive Sponsor	One sponsor with both budget and political authority	One dimension or the other, rarely both	Name a co-sponsor so budget and political authority are both covered
2. CoE Lead	Hiring authority across all ten roles	Dotted-line influence, direct authority over none	Get signed time-allocation agreements from function heads before launch
3. Agent Product Owner	Cross-team authority over schema, evals, defunding	Authority only inside their own team	Name the specific cross-team authorities in the role definition
4. Domain teams	Will surrender autonomy to central standards	Will resist; many already shipped their own agents	Make the owned/delegated boundary explicit and small; earn credibility one agent at a time
5. Security and Risk	Integrated into delivery from day one	Terminal gates at the end of projects	Fix the underlying delivery model first; the CoE will not fix it
6. Power Platform CoE	Already exists as a prerequisite	Often absent or immature	Treat the playbook as Phase 2; build the Power Platform CoE foundation first
7. Budget before ROI	Funding for the foundation period before receipts	CFO expects ROI within 12 months	Split the budget into a foundation phase and a delivery phase, named upfront

When the CoE Pattern Works and When It Fails

The framework works when the seven assumptions hold or when the gaps are explicitly named and addressed. It fails when the gaps are unnamed and the CoE is set up against assumed authority that does not exist.

The enterprise-size bands and timelines below are rough field heuristics from our own engagements, not figures published in the playbook. Calibrate them to your org.

Enterprise type	Will the CoE pattern work as-described?	Required adaptation
Mature Power Platform CoE, integrated Security/Risk in software delivery, named AI Executive Sponsor with both budget and political authority	Yes. Adopt the framework as-described. Adoption typically takes ~3 months.	None substantial. Audit role authorities and integrate.
Mature Power Platform CoE but Security/Risk operates as terminal gate	Partially. The pattern will work for the agent lifecycle but Security/Risk integration will lag.	Stand up the AI CoE first with explicit security-integration milestones. Treat security maturity as a parallel workstream, not a CoE deliverable.
No Power Platform CoE, mid-sized enterprise (5K-15K employees)	Not in 90 days. The framework's prerequisite stack does not exist.	Treat the playbook as Phase 2. Spend Phase 1 (3-6 months) on Power Platform CoE foundation. Then layer AI CoE on top.
Large enterprise with strong central IT but historically autonomous business units	Centralized CoE will fail; Federated is too early. Start Hybrid.	Negotiate explicit Centralize/Delegate boundaries with business-unit GMs before standing up CoE. Without the negotiation, the CoE will be ignored.
Enterprise with no formal AI governance, no executive sponsor named	No. The structure has nowhere to land.	Do not stand up the CoE. Spend 90 days getting executive sponsorship explicit. Then revisit.

The Three Anti-Patterns We See Repeatedly

The Empty CoE. The CoE is stood up with named roles but no actual staffing allocation. People are "10% on CoE" in a way that means zero hours per week in practice. The cadence is on the calendar but unattended. Decisions are made in the cadence and not enforced outside it. Quarterly review meetings produce slide decks but no behaviour change. The CoE exists on the org chart and nowhere else.

The Permission Bottleneck. The CoE accumulates approval authority faster than it can process the queue. Every new agent has to go through the CoE for review. The CoE has 3 reviewers and 200 agent proposals. Backlogs grow. Business units route around the CoE by deploying agents through other channels (personal Copilot subscriptions, third-party tools, "experiments" that are actually production workloads). The CoE produces governance theatre while the actual agents proliferate ungoverned.

The Tooling Substitute. The CoE buys tooling (governance platforms, agent registries, eval-dataset management tools) as a substitute for the harder operating-model work. The tools sit unused or underused. The expected operating-model outcomes do not materialise. The CoE blames the tools rather than naming the underlying assumption gap.

All three anti-patterns trace to the same root cause: setting up the structure without first verifying the seven assumptions hold.

The Honest 90-Day Adaptation

If you have to stand up an AI CoE in the next 90 days, treat the playbook's 90-day play as a target shape, not a literal sequence. Sequence the work like this:

Days 0-30: Verify the assumptions. Run the seven-assumption test against your organisation. Name the Executive Sponsor and audit their two-dimensional authority. Get dotted-line agreements from function heads. Audit Security/Risk integration in existing software delivery. Verify or build the Power Platform CoE foundation. Get explicit Phase 1 + Phase 2 budget structure approved.

Days 30-60: Stand up the bare-minimum CoE. Three roles, not ten: the CoE Lead, one Agent Product Owner, one Security/Risk integrator. Run weekly cadence. Take in two pilot agents. Do not extend the CoE structure until the bare minimum is producing reliable signal.

Days 60-90: Extend or stop. If the bare-minimum CoE is working (the two pilot agents are progressing through the lifecycle with named owners and trackable evals), extend the structure. Add the Platform & Operations role. Add an Adoption Lead. Plan the move from Centralized to Hybrid in the next 90-day cycle. If the bare-minimum is not working, stop and diagnose the assumption gap before adding structure. More structure on top of a broken foundation produces more visible failure, not better outcomes.

From Assist to Execute: The Reference Architecture Implications Microsoft's Playbook Doesn't Draw (2026)

Alex Pechenizkiy — Tue, 04 Aug 2026 16:08:36 +0000

Microsoft's 2026 Agentic Transformation Patterns Playbook opens with a conceptual shift: AI agents are moving from assisting humans to executing work. The playbook names the operating-model consequences (ownership, risk, lifecycle, governance) clearly. What it stops short of drawing is the reference architecture beneath the shift. The architecture beneath Execute is substantially different from the architecture beneath Assist, and the gap is where most enterprise designs will quietly break.

This is the architectural companion to the practitioner decode of the playbook itself. The decode walks the operating-model framework; this piece walks the reference architecture implications.

Where this fits in the cluster

Read this if: you are designing or reviewing the reference architecture for an enterprise that is moving its first agents from Pattern 1 (Employee Enablement) to Pattern 3 (Workplace & IT Services) or Pattern 4 (Core Business Process Transformation). The Assist-to-Execute boundary is precisely where these transitions happen, and the architecture you set up at the boundary determines, in our experience, what happens for the next 18 months or so.

The Conceptual Shift in One Paragraph

In Assist mode, the agent supports a human decision. The human remains accountable. The agent's failures are corrected by the human in the loop. The architecture is straightforward: a single application surface, the user, the agent, and one or two backing systems. Most failures are caught by the human reviewing the output before acting on it.

In Execute mode, the agent performs work across systems. It writes to systems of record, triggers downstream workflows, and operates on behalf of the user without the user reviewing each action. The human shifts to overseeing outcomes rather than producing them. The architecture has to assume that the human will not catch most failures in real time. Everything that was implicit in Assist (the human will notice, the human will correct, the human is accountable) has to become explicit in Execute (the system has to notice, the system has to correct, accountability has to be designed in).

Microsoft names the operating-model consequences (ownership, risk, lifecycle, governance) in the Agentic Transformation Patterns Playbook, where the Assist-to-Execute framing is set out. The architectural consequences are larger, and they are the author's extension below.

What Changes Architecturally at the Boundary

Crossing from Assist to Execute changes seven things in the reference architecture. None of them are individually difficult. Together they constitute a different system shape, and a design that worked in Assist will not survive contact with Execute without explicit rework.

Architectural concern	Assist mode design	Execute mode design
Authority surface	User authority delegated to the agent for the duration of one interaction	Persistent agent identity (Entra Agent ID per agent version) with scoped OBO tokens and least-privilege permissions
Deterministic boundary	Implicit; human inspects each output before acting	Explicit; high-stakes calculations go to deterministic tools (Logic Apps, code-interpreted scripts, schema-validated APIs) not to the model
Schema contract	Loose; the agent and one or two backing systems can negotiate shape per call	Canonical; a named owner controls the work-object schema across all systems the agent touches
Failure detection	Human-in-the-loop; the user notices wrong output and rejects it	Telemetry + continuous evaluation; the system samples production behaviour against quality, safety, and cost baselines
State persistence	Session-scoped; conversation context lives in the chat surface	Case-scoped; durable state lives in a system of record (Cosmos DB, Dataverse, or equivalent) with a change feed
Rollback semantics	Re-run the prompt; user iterates manually	Switch the active agent-version pointer; downstream systems must tolerate the rollback without state corruption
Auditability	Chat transcript + manual export	Per-action audit log keyed to agent-version, user identity, and source system; retention policies aligned to compliance regime

Each row is a substantive design change. Together they mean that the architecture you used for Pattern 1 (Employee Enablement) does not extend to Pattern 3 or Pattern 4 without explicit rework. The transition is not a scale-up of the same design; it is a different design.

The Authority Surface Shifts From User to Agent

In Assist mode, the user is logged in, the agent runs in the user's session, and any system call inherits the user's permissions. This is the standard delegated-permissions pattern. Most M365 Copilot integrations work this way today.

In Execute mode, the agent often acts when the user is not logged in (overnight batch, asynchronous workflows, multi-step processes that span hours or days). The agent needs its own identity. Microsoft's Entra Agent ID is the surface I would reach for here. My read is that you provision a distinct agent identity per deployed agent version and grant it scoped permissions through standard Azure RBAC. The playbook does not specify the identity mechanics; this is the architecture I would draw under it, and it produces a stable identity per agent-version that rollback and audit can key off.

The architectural implication is that every downstream system the agent writes to has to support a service-principal-style caller, not just a user-on-behalf-of caller. Many legacy SaaS systems still require interactive user sessions or have token lifetimes that do not accommodate long-running asynchronous workflows. These systems become integration friction at the Execute boundary. The AI orchestration over legacy systems reference architecture describes the integration pattern in detail (the Operational Front Door + Logic Apps as MCP servers + APIM enforcement).

A second implication is least-privilege design at the agent-version level. Each deployed agent version gets a dedicated identity. That identity should be granted only the permissions the specific agent version needs, not a permissive role that covers all possible future agents. When the agent's tool set changes, the new agent version gets a new identity with new permissions; the old version retains its old identity until rolled out of production. This is operationally heavier than a single shared service principal and is the right cost to pay for auditability and rollback safety.

The Deterministic Boundary Must Be Drawn Explicitly

In Assist mode, when the agent does a calculation, the user sees the answer and can verify it. The calculation can live anywhere: in the model, in a tool call, in a code interpreter, in a chained reasoning step. If it is wrong the user catches it.

In Execute mode, the agent performs the calculation and acts on the result. Wrong calculations produce wrong actions. The architectural rule that emerges is: any calculation with material consequence must run on deterministic substrate, not on the model. This means:

Financial calculations (totals, allocations, tax, fees, interest) go to code, not to the model. The model can orchestrate; the math runs in Python or in a schema-validated API.
Eligibility and routing decisions with regulatory or contractual implication go to declarative rules engines (Logic Apps with explicit conditions, Pega rules, or equivalent), not to the model's inference.
Schema-validated transformations (data mapping, format conversion, structural validation) go to explicit transformation steps, not to the model's "format this as JSON" reasoning.

The model orchestrates the workflow. The model does not perform the high-stakes operation. Drawing this line explicitly during design is the practitioner discipline the playbook implies but does not name. The companion piece on AI orchestration over legacy systems covers the deterministic-tooling integration patterns in depth.

The Schema Contract Becomes Load-Bearing

In Assist mode, the agent often touches one or two backing systems per interaction. The shape of the data can be negotiated per call. If the system returns slightly different shapes for different cases, the model's flexibility absorbs the variance.

In Execute mode, the agent orchestrates across many backing systems per workflow (in the workflows I have seen, roughly four to ten). Each system has its own canonical shape for the same business concept (a "customer" in CRM, a "client" in billing, an "account" in support, an "entity" in compliance). Without a canonical shape that the agent operates on, the agent ends up doing reconciliation logic in the model, which is exactly where it should not be.

The architectural pattern that works is a canonical work-object schema (a "case," an "incident," a "claim," an "order") owned by a named person with cross-team authority. The systems map to and from the canonical shape at the integration boundary. The agent operates on the canonical shape only. When systems change their internal shapes (which happens), the mapping layer changes; the agent does not.

The political precondition for this pattern is that the canonical schema has an owner with authority to require upstream systems to conform to the mapping. In our experience this is the single most underweighted prerequisite for Execute-mode work. Without schema ownership with authority, the agent ends up doing the schema reconciliation in inference, which is brittle, costly, and unauditable.

Failure Detection Moves From Human to System

In Assist mode, the user is the failure detector. Wrong outputs get rejected and the agent learns (or the user iterates). The detection signal is implicit in user behaviour: low task-completion rate, high re-prompt rate, low user satisfaction.

In Execute mode, the user is not in the loop for most actions. Failure detection has to move to the system. Two layers are required:

Continuous evaluation on production traffic. A sampled subset of agent actions is run through the evaluation suite in production, with results trended against the CI/CD baseline. When quality, safety, or cost metrics drift from baseline, alerts fire. The AgentOps reference architecture decode covers the continuous-evaluation surface in detail.

Outcome monitoring keyed to business KPIs. The agent's actions produce outcomes in downstream systems. Those outcomes are observable: claims processed correctly, support tickets resolved within SLA, financial transactions reconciled. Continuous monitoring of these outcomes catches failures that evaluation alone misses, especially edge cases the eval dataset does not cover.

The architectural change is that every Execute-mode agent must wire telemetry into two surfaces: the AI evaluation surface (token usage, hallucination rate, grounded-response rate) AND the business outcome surface (the downstream system's metrics). OpenTelemetry traces forwarded to Azure Monitor handle the AI surface; the existing business observability handles the outcome surface; the correlation across the two is a deliberate engineering effort.

State Persistence Becomes Case-Scoped

In Assist mode, conversation context lives in the chat surface. When the session ends, the context is gone (or summarised into a transcript). The agent does not maintain durable state across sessions.

In Execute mode, the agent often operates on a case that persists across days, weeks, or longer (a claim, an incident, a procurement workflow, a customer onboarding). The case has durable state that the agent reads and updates. The state lives in a system of record (Cosmos DB, Dataverse, or equivalent) and is queryable by other agents, by reporting systems, and by the human overseer.

A change feed on the durable state (Cosmos change feed, Dataverse change tracking) is the architectural pattern that lets multiple agents collaborate on the same case without coordination bottlenecks. Agent A updates the case; the change feed notifies Agent B that something it cares about changed; Agent B reacts. This is the architecture pattern that lets multi-agent workflows scale.

The implication is that Execute-mode architectures need an explicit case-state-store choice early in the design. Retrofitting case state after the agent is in production is expensive. Make the choice during the Assist-to-Execute transition.

Rollback Semantics Must Be Designed In

In Assist mode, rollback is trivial. The user re-prompts. The previous output is discarded.

In Execute mode, rollback is a system property. The agent has taken actions in downstream systems. Reverting to a previous agent version does not automatically undo those actions. The architectural pattern that works is to treat agent actions as event-sourced where possible: the agent emits intent (write this record, trigger this workflow, send this notification); a separate workflow layer executes the intent and records the result. When a rollback is needed, the events are replayable or compensable independently of the agent.

For systems where event sourcing is not feasible (legacy systems with imperative write APIs), the rollback pattern is compensating transactions: each agent action is paired with an explicit compensating action, and the agent's downstream workflow records what compensations would need to fire on rollback. This is operationally heavy and is one reason why integrations with legacy systems are the slowest part of Execute-mode adoption.

The architectural rule: every Execute-mode action that writes to a downstream system needs a defined rollback path. Either the action is event-sourced (replay or skip), or the action is paired with a compensating action (recorded for rollback), or the action is explicitly tagged as non-reversible (and gated with additional approval). Without this discipline, the agent-version rollback that the AgentOps reference architecture describes works for the agent runtime but does not roll back the downstream side effects.

Auditability Becomes Per-Action

In Assist mode, the audit surface is the chat transcript. The user's interactions with the agent are logged at the conversation level. This satisfies most compliance regimes for low-stakes work.

In Execute mode, the audit surface is per-action. For each action the agent takes, the audit log must record: which agent version executed it, on whose authority (user OBO or agent identity), against which source-of-record systems, with what input, producing what output, with what confidence signals from the evaluation surface. This audit log is keyed to enable both ex-post review (a regulator asks: did this agent action comply with policy on this date?) and ex-ante drilldown (an outcome looks wrong: trace the agent action that produced it).

The architectural pattern is structured action-logs forwarded to a queryable store with retention policies aligned to your compliance regime (often several years for financial and healthcare records, but confirm the exact period against your own counsel, it varies by regime and by record type). Application Insights with extended retention handles most non-regulated cases; for regulated workloads the audit log often needs its own immutable store (Azure Data Lake with WORM retention, or equivalent).

The Architecture Boundary Diagram

The seven changes above add up to a different system shape at the Execute boundary. The reference architecture for an Execute-mode agent maps those seven concerns onto eight named layers (the seven concerns plus the agent runtime itself) that an Assist-mode agent does not need:

This is not theoretical. The AI orchestration over legacy systems reference architecture is one specific instantiation of the Execute-mode pattern. The AgentOps CI/CD reference architecture is the deployment pipeline that ships Execute-mode agents. Together with this architectural read, those three documents are the practitioner reference for the Assist-to-Execute boundary.

The Honest Engineering Cost

The Assist-to-Execute transition is the single largest engineering investment in an enterprise AI program. In our experience the cost breaks down approximately as:

Authority surface refactor (Entra Agent Identity adoption, OBO patterns, downstream system permission audits): 4-8 engineer-weeks per agent integrated
Deterministic-tooling extraction (moving high-stakes calculations out of the model and into code or rules): 4-12 engineer-weeks per major workflow
Canonical schema definition and ownership negotiation (the political work, not the technical work): 6-12 weeks of cross-functional time, often longer
Case-state-store stand-up and change-feed wiring: 4-8 engineer-weeks
Continuous evaluation telemetry integration and continuous-monitoring dashboards: 4-8 engineer-weeks
Per-action audit log design and compliance review: 4-12 engineer-weeks depending on regulatory exposure

Total: 26-60 engineer-weeks for the architectural foundation, before the first Execute-mode agent ships. The playbook treats this work as preconditions to Pattern 3 and Pattern 4 deployment. It is. Treat the transition as a quarter-plus of dedicated engineering investment, not as a side effect of building the next agent.

When to Make the Transition

The transition is right when:

You have a specific business workflow where human-in-the-loop review is the bottleneck (most claims processing, most IT helpdesk first-line, most expense routing)
The workflow has a measurable outcome (resolution time, accuracy rate, throughput) that justifies the foundation investment
The systems the agent will write to have stable APIs and named owners willing to engage on schema discussions
Your organisation has the political maturity to name a schema owner with cross-team authority
Your security and compliance functions are integrated with software delivery enough to accept service-principal-style callers and per-action audit logs

The transition is premature when:

The agent's value proposition is "save users a few minutes" and that value does not justify, in our experience, 6+ months of architectural foundation work
The downstream systems require interactive user sessions and refactoring them is out of scope
Schema ownership cannot be politically assigned (the named owner role is contested or undefined)
The compliance regime requires controls (full per-action attestation, real-time human review, segregation of duties) that the Execute pattern cannot satisfy

The architectural test is straightforward: can you draw the seven Execute-mode concerns on a whiteboard, map them onto the eight layers, and name the owner for every component? If yes, the transition is feasible. If no, name the gaps and decide whether to address them or to stay in Assist mode for this workflow.

AgentOps on Microsoft Foundry: A Practitioner Decode of the New CI/CD Reference Architecture (2026)

Alex Pechenizkiy — Mon, 03 Aug 2026 16:15:51 +0000

Microsoft just published an end-to-end CI/CD reference architecture for Foundry agents. It is the first official Microsoft document that treats agent deployment as a first-class engineering discipline, not as a side effect of agent authoring. This is the practitioner read on what it gets right, where it understates the operational work, and what to do with it on Monday.

The CI/CD for AI Agents on Microsoft Foundry reference came out 2026-05-22 from Lee Stott on the Microsoft Tech Community Educator Developer Blog. Two reference repos accompany it: leestott/foundry-cicd for the pipeline implementation, ericchansen/foundry-agents-lifecycle (Eric Chansen) for the agent demo. The framework's one-line thesis is the reframing on which the rest of the document hangs:

"Agents follow a standard CI/CD pattern, but with a critical shift: promotion happens at the agent version level, and release gates are driven by evaluation outcomes, not just test results."

Treat the document as v1 of a still-refining artefact. It is one week old at writing, sits on a tech-community blog rather than Microsoft Learn, and has not yet been pressure-tested by a real enterprise deployment cycle. The architecture itself is sound. The understated parts are where the practitioner work begins.

Microsoft surface maturity (mid-2026)

This GA-vs-Preview split is my read as of mid-2026, not a list from the source; verify against the latest Foundry release notes before you plan around it.

GA today: Foundry Agent Service (hosted + prompt-based runtimes), Azure AI Projects SDK, Azure DevOps + GitHub Actions, Azure Container Registry, Azure Monitor, Application Insights, Entra Agent Identity, OIDC Workload Identity Federation.

Preview / hardening as of mid-2026: azure-ai-evaluation SDK at its current API surface, continuous-evaluation pipelines on production traffic, Foundry control-plane agent registry features.

The Layer 1, 2, and 3 pieces (developer + CI + CD) ship today on stable Microsoft surfaces. Layer 4 and Layer 5 (Foundry runtime + control plane) depend on surfaces that are mostly GA but still maturing the operational surface around continuous evaluation.

TL;DR + the Monday move

Microsoft's reference architecture has 5 layers (Developer → CI → CD → Foundry Agent Service → Monitoring + Governance). The single most important reframing, to my read: your deployment artefact is no longer a container image, it is an agent version (an immutable bundle of code, prompt, model, and tool config). Promotion gates fire on evaluation outcomes, not just test pass/fail.

Monday move: stand up the CI evaluation gate first. A failing eval blocks the PR before anything else moves. Once that gate is reliable on one agent, replicate the pattern across the fleet. Do not try to set up the full 3-environment topology until the eval gate is producing trustworthy signal.

Where the framework understates the work: evaluation dataset maintenance is treated as a sidebar. In practice it is a named engineering role and a budget line. A stale golden dataset turns the entire pipeline into theatre.

The Assist-to-Execute Shift Demands AgentOps

The companion piece on the Microsoft Agentic Transformation Patterns Playbook opens with the shift from Assist mode (agent supports a human decision; human accountable) to Execute mode (agent performs work across systems; human oversees outcome). Execute mode demands four operating-model commitments: ownership, risk, lifecycle, and governance.

The CI/CD reference architecture is the lifecycle commitment made concrete. It is not optional. The moment any agent crosses from Assist to Execute, the operational surface area grows enough that ad-hoc deployment becomes a liability.

What the reference architecture adds beyond classic software CI/CD is the recognition that probabilistic systems need probabilistic release gates. A unit test that passes today on input X will still pass tomorrow on input X. An agent that answers correctly today on prompt X may answer differently tomorrow because the model weights drifted, the upstream retrieval changed, a tool dependency updated, or the eval dataset became stale. The pipeline has to assume non-determinism and gate accordingly.

The reframing the reference puts at the top is, in my view, the single most useful sentence in the document. The deployment unit is no longer a container or a tag, it is an agent version: an immutable artefact bundling model selection, system instructions, tool definitions, and configuration. Promotion happens at that version level. Rollback is a pointer-swap, not a re-deployment.

The 5-Layer Architecture at a Glance

The reference flow is five layers from developer commit to production observability.

Layer	Responsibility	Key components
1. Developer	Source-controlled repo for agent code, configuration, and infrastructure	Python or .NET agent code, agent.yaml or prompt definitions, MCP/REST tool configurations, Bicep or ARM IaC for Foundry project provisioning
2. CI Pipeline	Build, validate, evaluate every push or PR before producing a versioned agent artefact	Docker build (hosted) or YAML schema validation (prompt), ruff + bandit static checks, pytest unit + tool tests, evaluation gate against golden dataset, ACR push
3. CD Pipeline	Promote one agent version through three Foundry project environments with eval and human-approval gates	Stage 1 Dev (smoke + eval), Stage 2 Test (scenario + HITL + safety), Stage 3 Prod (versioned promote + endpoint enable)
4. Foundry Agent Service	Runtime for the deployed agent versions, with built-in lifecycle and identity	Hosted + prompt-based runtimes, versioned deployments, Entra Agent Identity per version, RBAC per project, distributed traces + structured logs
5. Monitoring + Governance + Control Plane	Platform-level governance, observability, and continuous evaluation across the deployed fleet	Agent registry + version history, OpenTelemetry forwarded to Azure Monitor + Application Insights, continuous evaluation on sampled production traffic, Azure Policy + RBAC enforcement

Honest observation, and this is my read rather than a number from the source: Layer 2 and Layer 3 are where most of the operational discipline lives, call it roughly four-fifths of the new engineering work. The developer layer is what most teams already have. Foundry Agent Service is what Microsoft provides. The control plane is what the platform team configures once. The CI + CD pipeline is where new engineering work goes, and it is where, in my read, most teams will need to invest most heavily over roughly the next 6 to 12 months.

Evaluation Gates: the Real Differentiator

Classic software pipelines gate on tests. Agent pipelines add a category Microsoft calls evaluation-driven quality gates. These run at two points: pre-merge during CI, and pre-promotion during CD. The published threshold table is the most directly useful artefact in the document.

Category	Metric	CI threshold	Prod threshold
Quality	Hallucination rate	< 5%	< 3%
Quality	Task completion rate	> 90%	> 95%
Safety	Grounded response rate	> 95%	> 98%
Safety	Policy violations	0	0
Performance	p95 latency	< 4000 ms	< 3000 ms
Cost	Token usage per query	Track only	Alert on > 20% regression

The threshold values themselves are reasonable starters but they are not universal. A claims-processing agent has very different acceptable hallucination tolerance than a meeting-summary agent. A code-review agent has different latency tolerance than a customer-service agent. Microsoft frames these as "thresholds" without saying "these are illustrative starters." Treat them as illustrative starters. Calibrate to your specific use case, your specific user expectations, and your specific liability exposure.

The hidden cost the document acknowledges briefly but does not quantify is dataset maintenance. The article does say "stale datasets produce misleading pass/fail signals" and "treat your golden evaluation set as a first-class engineering artefact alongside the agent code itself." That is correct but understates the work. A real golden dataset needs:

A named owner with authority over what goes in and what comes out
A change-review process that mirrors code review
Quarterly coverage audits against real production traffic patterns
A drift detection process that flags when production cases diverge from dataset cases
Versioning that ties each eval run to a specific dataset version

Most teams do none of this. The result is a dataset that was representative on day one and unrepresentative by month six, producing eval scores that no longer reflect real-world performance. The eval gate becomes theatre.

A second silent cost is token spend. Every PR triggers an eval run. Every eval run costs tokens at the rate of your model provider. At fleet scale (say, on the order of 100+ PRs per week across 10+ agents) the eval budget becomes a non-trivial line item. The reference architecture says nothing about cost-control patterns: sampled eval runs on draft PRs, full eval runs only on PRs marked ready-for-review, or per-team token budgets enforced at the pipeline level. These are decisions every team will face once the pipeline is running at scale.

Hosted vs Prompt-Based Agents: Pipeline Differences in Practice

The reference architecture handles two deployment models. The split is real and the operational implications differ.

Capability	Hosted agents	Prompt-based agents
Deployment unit	Container image plus agent definition	YAML / prompt configuration bundle
Build step required	Yes: Docker build plus ACR push	No: YAML validation only
Supported frameworks	Agent Framework, LangGraph, Semantic Kernel, custom code	Foundry declarative runtime
Promotion artefact	Versioned agent with container image reference	Versioned prompt / config bundle
CI focus	Code quality, tool tests, evaluation	Prompt schema validation, evaluation
Rollback mechanism	Switch active agent version (pointer)	Switch active agent version (pointer)
Runtime management	Foundry manages container lifecycle	Foundry manages declarative runtime

Hosted agents inherit all the Docker supply-chain problems (base-image pinning, dependency version drift, SDK churn) on top of the AI-specific evaluation problems. A team running hosted agents needs both standard container-security discipline (CVE scanning, SBOM tracking, base-image refresh cadence) and AI-specific evaluation discipline. The reference architecture covers the AI side cleanly; the container-supply-chain side is treated as standard practice and left to the team.

Prompt-based agents look simpler because there is no Docker build. The complexity moves to the prompt-version lifecycle. A small change to a prompt can shift behaviour across thousands of test cases. The golden dataset needs coverage of prompt edge cases (jailbreaks, prompt injection, edge-case phrasings) that does not exist for the hosted-agent code path. Prompt-based deployment is operationally lighter on day one and operationally similar on day ninety once the prompt-version testing is mature.

Multi-Environment Topology

Microsoft recommends a three-environment topology with separate Foundry projects per environment.

Option	Structure	Best for	Trade-off
A (Recommended)	Dev Project → Test Project → Prod Project (separate Foundry projects)	Enterprise workloads	Full RBAC isolation, distinct connection strings, separate evaluation signals, easier governance audit
B (Lightweight)	Single Foundry project with agent version tags (dev/test/prod)	Small teams, prototyping, internal demos	Simpler initial setup, weaker environment separation, RBAC has to be enforced at agent-version granularity

Option A is the right call for any team running agents in production. The cost is operational: three Azure subscriptions or three resource groups (the boundary depends on your landing zone), three sets of connection strings, three sets of policy assignments. Teams without a clean dev/test/prod Azure landing zone will spend the first month of adoption fixing landing-zone problems before the CI/CD pipeline can be set up cleanly. Plan for this.

OIDC Workload Identity Federation between the pipeline and Azure is the right authentication pattern. It avoids storing long-lived Azure credentials in pipeline secrets, rotates the trust automatically, and produces audit logs for every deployment action. Adopt OIDC from day one even on the Dev environment; the cost of retrofitting it later is high.

Where the Reference Architecture Understates the Work

The architecture itself is correct. The framework is sound. There are six places where the document understates the engineering work the patterns demand.

Multi-model evaluation is unaddressed. Many real enterprise agents route across Foundry, Claude, and OpenAI by workload type. Eval suites that work for one provider do not automatically work for another (prompt formatting differs, tool-call semantics differ, refusal patterns differ). The reference architecture assumes a single-model deployment per agent. Multi-model deployments need per-model eval suites and a routing-layer eval test that the architecture does not name. The companion piece on LLM-agnostic AI agents covers the routing-layer side of this.

Model deprecation breaks the reproducible triple. The (code, prompt, model) triple is auditable today. When Microsoft retires gpt-4o or upgrades a model behind the same name, the old triple is no longer reproducible. The article does not address provider-side model lifecycle. A real AgentOps practice needs: explicit model-version pinning, a deprecation-monitoring process, a re-evaluation campaign on every forced model upgrade, and a rollback plan that anticipates the model itself being unavailable.

The HITL approver authority gap. Required human approval before Production deploy is the right gate. The assumption is that the approver has both the technical literacy to read eval results and the product authority to defund a stalled promotion. Most enterprises have one or the other, rarely both. The product manager who has authority does not always have the technical literacy; the engineer who has the literacy does not always have the authority. This is the same political-maturity gap that the Agentic Patterns Playbook decode names in its critique of the CoE framework.

Continuous evaluation on production traffic raises PII and audit concerns. The article mentions sampled production traffic but does not address sampling-rate decisions, PII redaction before eval, audit logging for sampled traffic, or how to handle eval failures that would themselves expose PII in incident reports. In regulated industries (finance, healthcare, public sector) these are gating decisions, not implementation details.

Pipeline parity is operational debt. Microsoft publishes both a GitHub Actions workflow and an Azure DevOps YAML pipeline as parallel reference implementations. Both are well-designed. In practice teams pick one and stick with it. Maintaining both is operational debt the article does not name. The decision criteria are real: shop-existing tooling, identity model fit, RBAC and approval-gate ergonomics, evaluation-result reporting integration with your existing developer surfaces.

Cost regression alerting needs an owner and authority. "Alert on > 20% token regression" is a correct control. Who receives the alert and what authority they have to act on it (roll back, defund, downgrade model selection, require redesign) is not specified. Without a named owner and a defined escalation path, the alert becomes a Slack notification that no one acts on.

The Cross-Stack Test: AgentOps Beyond Microsoft

The same vendor-portability question we asked of the Patterns Playbook applies here. Are these patterns Microsoft-stack-implicit, or do they transfer cleanly to non-Microsoft operating models?

The CI/CD shape transfers cleanly. The eval-gate-as-release-gate principle is universal. The (code, prompt, model) version-pinning principle is universal. The Dev → Test (with HITL) → Prod promotion sequence is universal. The OIDC + workload identity pattern is universal across major identity providers.

The implementation surfaces differ. A team running Pega-based agent orchestration over Pega case management can adopt the same release-gate discipline with Pega's own deployment tooling and a custom evaluation script. A team running Salesforce Agentforce can wire eval gates into Salesforce DX. A team running n8n or LangChain or LangGraph outside Microsoft can adopt the same CI sequence (lint, test, eval, build) using GitHub Actions or GitLab CI without touching Foundry.

What does not transfer cleanly is the agent registry. Foundry's built-in agent registry, version history, and Entra Agent Identity per deployed version are platform features that have no direct cross-stack equivalent today. Teams running agents outside Foundry will need to build or buy the registry layer. This is one of the strongest practical reasons to standardise on Foundry for new enterprise agent workloads if the rest of your stack is Microsoft-aligned.

The Monday Move for Different Team Types

Adopt the reference architecture selectively. Your team's current posture determines the right starting move.

Team posture	Where to start	Where to skip-read
Already running Power Platform ALM with release gates	This maps cleanly onto your existing discipline. Adopt the eval-gate Python script as a new gate type in your existing pipeline. The CI structure plugs into Azure DevOps cleanly if you are already on ADO.	Skip nothing; this is additive.
One Foundry agent in Dev, no pipeline yet	Stand up the Dev project plus the eval-gate Python script first. Run it on every PR. Do not try to set up Test or Prod environments until the eval-gate is producing trustworthy signal for at least one full release cycle.	Skip the multi-environment topology decision until you have eval-gate confidence.
Running 10+ agents across Foundry plus Claude plus OpenAI	Build the per-model evaluation suite first. The routing layer is a separate concern; treat the AgentOps pipeline as per-model and converge at the routing layer. The LLM-agnostic agents companion (linked above) covers the routing side.	Skip the single-pipeline assumption; you need one CI pipeline per backing model.
No release discipline today	Start with eval-gate-on-PR for one agent. Add the Test environment after one quarter of running the eval-gate cleanly. Add Prod after another quarter. The temptation to set up all three environments on day one is the most common failure mode.	Skip the full reference architecture; treat it as the 12-month target, not the Monday move.

Budget anchor. The reference architecture is silent on the engineering cost of standing up the pipeline. Order-of-magnitude estimate from our experience: a team adopting AgentOps for the first time typically spends 4-8 engineer-weeks on the initial pipeline (developer environment standardisation, CI eval-gate Python script, single-environment CD, OIDC trust setup). A team running 10+ agents at scale typically allocates 1-2 dedicated FTEs to AgentOps platform engineering plus shared eval-dataset curation across product teams. Treat these as illustrative ranges; your specific use cases, your team's prior CI/CD maturity, and your regulated-data posture move them.

The Real Deployment Artefact Is the Agent Version

Microsoft's whole reframing in one line:

"Treat the agent version as your deployment artefact, and evaluation outcomes as your release gate."

Internalise that and the rest of the architecture organises itself. The container image is supporting infrastructure. The pipeline is the production line. The agent registry is the audit surface. The runtime is the execution surface. The thing that ships, the thing that promotes, the thing that rolls back, is the agent version.

The strategic implication for hiring, funding, and platform-engineering investment over the next 12 months is direct. Hiring: the Agent Product Owner role the Patterns Playbook formalises becomes the role that owns the agent version across its lifecycle. Funding: the eval-dataset curation that the reference architecture treats as a sidebar is in fact a budget line and a named engineering responsibility. Platform engineering: the AgentOps pipeline becomes a platform-team deliverable, not a per-product-team improvisation.

Microsoft has done the harder half of the work by publishing the reference. The remaining half is operational discipline: eval-dataset ownership, multi-model evaluation, model-deprecation rollback plans, HITL approver authority, continuous-evaluation PII handling, and pipeline-choice consolidation. Those are the practitioner gaps, and they are where the next 12 months of enterprise AgentOps work actually happens.

The Agent Product Owner: Microsoft Just Formalized the Hire Most Enterprises Haven't Made (2026)

Alex Pechenizkiy — Sun, 02 Aug 2026 14:55:56 +0000

Microsoft's 2026 Agentic Transformation Patterns Playbook names a role most enterprises have not yet formalised: Agent Product Owner. The role is described as the operating owner for one or more deployed agents across their full lifecycle. The framing is right, the role is real, and most enterprises have not yet hired for it. This is the practitioner read on what the role actually does, what to hire for, and why it is the most consequential new AI role of the next 18 months.

If you are sitting on a steering committee asked "do we need to hire for AI?" and the answer keeps being "we need data scientists and ML engineers," this is the read that names the role you are actually missing.

Who this is for

Hiring managers, AI program leads, CIOs, and senior architects responsible for naming and staffing AI roles. Also: senior product managers, senior delivery leads, and senior engineering managers considering whether to transition into the role.

Why the Role Exists

The Assist-to-Execute shift that opens the playbook (decoded here) changes what an AI agent is operationally. In Assist mode the agent is a feature inside a productivity tool. The team that owns the productivity tool owns the agent. In Execute mode the agent is a system that performs work, produces outcomes, has its own deployment lifecycle, and accumulates technical and operational debt over time. It needs an owner the same way any other production system needs an owner.

The existing organisational shapes do not fit. Data Science teams build the model but do not own deployed agent lifecycles. ML Engineering teams own the model-serving infrastructure but not the agent's business outcomes. Application development teams own application surfaces but not the agent's behaviour or evaluation. Product Management owns user outcomes but typically not technical lifecycle. None of these existing roles owns the agent end-to-end.

The Agent Product Owner sits at the intersection: technical enough to read evaluation results and reason about prompt-tooling design, product enough to define success metrics and prioritise improvements, operational enough to own the agent in production. The role is genuinely new, not a relabelling of an existing role. It is the human accountability layer for the kind of agent-over-legacy-systems estate covered in the orchestration reference architecture.

What the Agent Product Owner Actually Does

The playbook names the role; the six responsibilities below are my breakdown of what owning a deployed agent end-to-end actually requires, each measurable:

Responsibility	What it looks like in practice
Agent lifecycle ownership	From the intake of the agent request through retirement. Includes scope definition, vendor and model selection, integration sequencing, release-gate decisions, ongoing improvement priorities, and the retirement decision when the agent has reached end-of-useful-life.
Success-metric definition and tracking	Defines the agent's success metrics (typically a small set of business-outcome KPIs plus quality, safety, and cost technical metrics). Owns the dashboard. Reports trend to the steering committee. Triggers reviews when metrics drift.
Golden evaluation dataset ownership	Owns the evaluation dataset that the agent's CI/CD pipeline runs against. Ensures coverage of edge cases, prompt-injection scenarios, and policy boundaries. Updates the dataset as the agent's tasks evolve.
Cross-team coordination	The agent typically depends on data, tools, and integrations owned by other teams. The Agent Product Owner coordinates across those teams, negotiates schema contracts, manages dependencies, and escalates blockers to the Executive Sponsor.
Release-gate authority	Has the authority (within the risk-tier framework) to mark a release as ready-for-production or not. Has the authority to defund a stalled improvement. Has the authority to roll back to a previous agent version when evaluation thresholds breach.
Incident response leadership	When the agent has an incident in production, leads the response: triage, rollback, root-cause analysis, remediation. Owns the post-incident review.

The role is closer to a Senior Product Manager for a production service than to a traditional internal-product role. It has authority that internal product roles often lack (release-gate, defunding), and it requires technical depth that traditional product roles often do not. The golden evaluation dataset that this role owns is the same artefact the AgentOps CI/CD pipeline runs against on every release.

What to Hire For

The hiring criteria for an effective Agent Product Owner are unusual because the role straddles disciplines. In our experience, candidates from five backgrounds can grow into the role, each with different gaps to close.

Senior Product Manager with technical depth. Strongest fit when the candidate has shipped technical products (developer tools, platform products, infrastructure SaaS) and is comfortable with eval-result interpretation, prompt-tooling design tradeoffs, and CI/CD discipline. Gaps to close: depth on AI-specific risk surfaces (prompt injection, eval-dataset curation, model-deprecation patterns), depth on agent-specific telemetry and observability.

Senior Delivery Lead / Solution Architect with prior LLM exposure. Strongest fit when the candidate has led the delivery of agent solutions and has direct hands-on with at least one production agent. Gaps to close: product discipline (defining and tracking outcome metrics, prioritising improvements based on metric movement rather than feature requests), stakeholder management with senior business leaders.

ML Engineer or Data Scientist with production deployment experience. Strongest fit when the candidate has been responsible for keeping ML systems running in production with measurable business impact. Gaps to close: product discipline, cross-team coordination, business-outcome framing.

Senior Engineering Manager from a SaaS background. Strongest fit when the candidate has operated production services with named SLAs and direct accountability for outcomes. Gaps to close: AI-specific risk surfaces, eval-dataset discipline, agent-lifecycle specifics (prompts and tools are not the same as code and APIs even when the deployment pipeline rhymes).

External hire from a vendor or consultancy with AI deployment specialism. Strongest fit when the candidate has shipped multiple agents across multiple enterprises and brings pattern recognition for what works and what does not. Gaps to close: the specifics of your enterprise stack, your data politics, your existing operating-model maturity. In our experience, the external hire has to be partnered with an internal sponsor for the first 6 months or so.

The wrong hire: anyone who thinks of agents primarily as model-tuning problems. Modelling is part of the picture. The role is fundamentally about operating a production system that happens to include AI, not about building AI models. The role is platform-shaped, not platform-specific. The same authority mapping holds whether your agents run on Foundry, Bedrock, or a mixed multi-model estate.

The Role-Authority Mapping

The framework names the role and the lifecycle, but it does not map authority to specific decisions. The matrix below is my recommended mapping, not Microsoft-stated content; calibrate it to your governance model. The mapping of role authority to specific decisions is where the role either works or becomes a coordinator without teeth. Adopt an explicit authority mapping when defining the role:

Decision	Who has authority	Escalation path
Agent scope expansion (add new use case, new data source, new system integration)	Agent Product Owner approves; CoE notified	CoE if scope crosses tier boundaries or extends to new business units; Executive Sponsor if cross-business-unit politics surface
Release gate (ready for production or not)	Agent Product Owner with the named release reviewers (Security/Risk, Domain Expert)	CoE if the reviewers disagree and the disagreement cannot be resolved at the working level
Rollback in production	Agent Product Owner has unilateral authority to roll back	Notify CoE within 24 hours; full incident review at next CoE cadence
Defund a stalled improvement	Agent Product Owner proposes; Executive Sponsor approves if the improvement was a steering-committee priority	Quarterly review where unfunded improvements get re-evaluated against current portfolio priorities
Retire the agent	Agent Product Owner proposes; Executive Sponsor approves; CoE coordinates the retirement process	Steering committee if retirement has cross-business-unit impact
Eval threshold adjustment	Agent Product Owner with eval-dataset owner agreement	CoE if the new threshold is materially different from peer agents; Risk/Security if the new threshold reduces a safety control
Cross-team schema mandate (require an upstream system to consume the canonical schema)	Agent Product Owner proposes; CoE coordinates with the upstream team owner; Executive Sponsor adjudicates if disputed	Quarterly portfolio review; this is the political-maturity test, not a technical one

Without this explicit authority mapping, the role becomes a coordinator with extra reporting overhead. With it, the role becomes the operational engine of the agent program. The cross-team schema mandate row is the hardest one to get right, because it is the political-maturity test, not a technical one.

Reporting Line and Organisational Placement

The role's reporting line shapes how the work actually gets done. Three patterns work, each with trade-offs:

Reporting pattern	Best for	Main risk
Pattern A: reports into the AI CoE	Early-stage programs where program coherence matters more than business-unit alignment. Strongest match to the playbook's framing.	The Agent Product Owner sits further from the business unit consuming the agent, which can slow priority alignment.
Pattern B: reports into the consuming business unit (matrix with CoE)	Mature programs with multiple agents per business unit. Strongest alignment to business outcomes.	Agent-program coherence is harder to maintain when each owner reports into a different business-unit head.
Pattern C: reports into central Product or IT, embedded into the business unit by assignment	Large enterprises with strong central Product or IT functions. Keeps program coherence while maintaining business-unit proximity.	Most operationally complex of the three; the matrix can create ambiguity about who sets priorities.

Pattern A works best for early-stage AI programs where consistency matters more than business-unit alignment. Pattern B works best for mature AI programs with multiple agents per business unit. Pattern C is the most operationally complex but typically the right answer for large enterprises with strong central functions.

The Compensation Conversation

The role is new enough that compensation benchmarking is unreliable. In our observation as of mid-2026, market compensation for Agent Product Owner sits between Senior Product Manager and Director of Product, weighted toward Director when the candidate is owning Tier 3 (high-risk, external-facing) agents.

Tier 1 and 2 work can be done by a strong Senior PM. Tier 3 work requires Director-level operating authority, which typically requires Director-level compensation to attract candidates with the depth required. Most enterprises will under-compensate the role at first because the role does not yet have a clear comparator in HR's role library. This produces a hiring pattern where the role gets filled with under-qualified candidates, the role does not deliver, and the conclusion is "AI Product Management is not a real discipline." The conclusion is wrong. The compensation was.

Expect the role to settle around senior-director-equivalent levelling (L7/L8 in Microsoft terms, or your stack's equivalent) in 18-24 months. That is an order-of-magnitude read, not a benchmark. Pay early hires accordingly.

The Career Path Question

For the candidate considering whether to transition into the role, three things to know:

The role is operationally heavy. It is closer to running a production service than to running a product. The cadence is similar to SRE-adjacent product roles: daily eval-result review, weekly incident review, monthly outcome review, quarterly maturity review. Candidates expecting a roadmap-and-quarterly-launch cadence will find the role uncomfortable.

The role has unusual visibility. Agent incidents reach executive leadership faster than traditional product incidents because AI failures are inherently interesting to senior leaders. Successes also reach executive leadership faster. The role's visibility is asymmetric in both directions; treat that as a feature for career-acceleration purposes and a cost for stress-management purposes.

The role is becoming load-bearing. Over the next 18-24 months the role's importance to enterprise AI programs will increase substantially. In our observation, Senior Agent Product Owners with roughly 2-3 years of production AI ownership will be in high demand. The role is one of the most consequential career bets a senior Product or Engineering candidate can make in 2026.

What This Means for the Steering Committee

Three actions to take in the next 90 days if you do not yet have Agent Product Owners hired:

Name the first Agent Product Owner before the next agent ships. Pick the most consequential agent in current production or near-production deployment. Assign a named Agent Product Owner. Give them the explicit authority mapping above. Do not stand up additional agents until the first Agent Product Owner is functioning in the role.

Define the role in HR's role library. Get the role definition into the formal levelling structure. Compensation tied to operational responsibility (number of agents owned, risk tier of agents, business impact of agents). Career path defined upward (Senior Agent Product Owner, Principal Agent Product Owner, Director of Agent Product Management as the program scales).

Plan the hiring sequence. First hires: experienced internal candidates with technical depth and product instinct (likely Senior PMs or Senior Delivery Leads with prior LLM exposure). Second wave: external hires from vendors and consultancies who can bring pattern recognition. Third wave: external hires from peer enterprises who have done the role at scale (these will be rare and expensive in 2026; budget accordingly).

The Honest Read

The Agent Product Owner is the most consequential new role in enterprise AI in 2026. Microsoft's framework formalising it is correct. Most enterprises will under-hire for it because the role does not fit existing role libraries cleanly and because the compensation conversation is uncomfortable.

The enterprises that staff the role well and give it real authority will run agent programs that work. The enterprises that staff it poorly or give it title without authority will continue to produce great demos and low adoption, which the playbook itself names as one of the top five scale-breakers.

Hire well. Pay accordingly. Give the role real authority. The agent program runs on this role.

Dataverse MCP Server: Tool Shape Is Your New Security Perimeter

Alex Pechenizkiy — Sat, 01 Aug 2026 14:53:53 +0000

Read the Dataverse MCP Server announcement as a feature and you miss the point. Read it as a warning and it snaps into focus.

Microsoft is telling you, politely, that the contract you define decides whether an AI agent acts safely inside your system of record. Not the platform. You.

That contract has a name in the Model Context Protocol world. It's the tool shape. And it's the most important governance decision you'll make this year that nobody scheduled a meeting about.

What actually changed

Before MCP, an agent reaching Dataverse meant composing queries. FetchXML, SQL, whatever it could assemble from natural language. You were trusting an LLM to author the access pattern, and then trusting your security layer to catch whatever it got wrong.

The Model Context Protocol flips that. Each capability becomes a self-describing tool: a name, a description, a typed inputSchema, a structured result, and behavioral annotations that mark whether the action is read-only or destructive.

The agent no longer writes arbitrary queries. It invokes vetted, schema-bound actions. Metadata discovery, record read, CRUD, prompt and knowledge tools.

This narrows the error surface and the attack surface at the same time. But only if the tools are shaped tightly. A loosely shaped tool gives back everything you just took away.

MCP is Anthropic's open protocol, not a Microsoft invention. That choice is the whole strategy, and we'll come back to it. The short version: the agent UI is being commoditized, the data plane is not.

Tool shape is the first line, not the last

Here is the trap, and it's the one most teams will walk into.

People hear "schema-bound, governed tools" and assume the tool definition is the security boundary. It isn't. Tool shape is a first-line control. It shapes intent and narrows the surface. It is not the authoritative enforcement floor.

The real floor is still Dataverse. Security roles. Row-level security. Column-level security through Field Security Profiles. That machinery has guarded your data for years and it does not stop being the enforcement layer just because an agent is the caller.

But it only works under one condition: the agent has to run in the invoking user's delegated context.

That's the whole game in one sentence.

When the call carries the user's identity, row-level and column-level security travel with it. The agent sees exactly what that human would see. When the call runs under a broadly permissioned service principal instead, every per-user control evaporates. The agent sees everything the app registration can see, which is usually far too much.

Now combine the two failure modes:

A broadly shaped tool ("execute any query")
Running under a generously permissioned service principal

That collapses both layers at once. You've handed an LLM the keys to your system of record, and neither tool shape nor Dataverse security is standing in the way. This is the dominant failure mode, and it will not show up in a demo. It shows up six weeks later in an audit.

Layer	What it enforces	What collapses it
Tool shape (MCP contract)	What an agent can request; typed inputs; read-only vs destructive intent	A generic query-passthrough tool that accepts arbitrary operations
Dataverse security (roles, RLS, CLS)	What a given identity may read or write at row and column granularity	Running under a service principal instead of delegated user context
Both together	Defense in depth: narrow intent enforced against per-user permissions	Broad tool + over-permissioned app user. Both fail simultaneously

Stop trusting the prompt

A predictable instinct is to write the guardrails into natural language. "Only return records the user owns." "Never delete." "Refuse sensitive columns."

Don't. Prompt-level instructions are guidance, not enforcement. They are bypassable by construction, and treating them as a control is how you end up explaining an incident to people who don't care about your system prompt.

Two things are trustworthy: schema-level constraints in the tool shape, and Dataverse-level enforcement under delegated identity. Everything else is a suggestion.

The takeaway is blunt. If a control can be talked out of, it isn't a control.

The new risk class nobody budgeted for

MCP introduces a supply chain. Tools have definitions, definitions have metadata, and metadata flows into the model's context. That opens a category of attack that most Dataverse teams have never had to model.

Tool poisoning. A malicious or careless tool definition shapes agent behavior in ways the author didn't intend.
Prompt injection through tool metadata. The description field is not decoration. It's read by the model, and hostile content there can redirect behavior.
Confused deputy. The agent, holding more authority than the request deserves, gets tricked into using it on someone else's behalf.

Treat every tool definition and every input as untrusted. The same way you'd treat a public API endpoint that anyone on the internet can call, because functionally that's closer to the truth than it feels.

The competitive read

Here's the part that makes this strategic rather than just operational.

Microsoft could have built a Copilot-only walled garden. They didn't. They standardized on an open protocol, which means OpenAI, Claude, and your custom agents can all reach Dataverse through the same door.

That looks like giving something away. It isn't. It moves lock-in upward.

The agent and model layer becomes interchangeable, a commodity. The value-accruing assets stay exactly where Microsoft wants them: the tables, the business logic, Entra for identity, Purview for governance. Commoditize the agent UI, own the data plane.

If you're making platform bets, that's the signal. Don't over-invest in any single agent runtime. Invest in the substrate that every agent has to come through. Identity and governed data outlast whichever model is winning this quarter.

What actually breaks when you turn it on

The hard work was never enabling the server. That's a switch.

The hard work is that almost no organization designed its schema or its security model for agent consumption. Your tables assumed a human in a form with a security role. Now the caller is a tireless, fast, occasionally hallucinating process that will invoke whatever you expose.

So the real project is a decision, table by table and action by action: which of these should ever be agent-callable? Most of them shouldn't be, at least not yet, and certainly not for writes.

The first five moves

Do these in order. Each one assumes the previous is in place.

Where this leaves you

The Dataverse MCP Server is genuinely good engineering. It also quietly relocates a security boundary into a place most teams aren't looking: the tool contract, and the identity it runs under.

Get the shape tight and the identity delegated, and you get defense in depth that's better than what most orgs run today. Get either wrong, and you've connected a language model directly to your record of truth with the guardrails switched off.

Microsoft told you which one it is. The contract is yours to define.

This surface is evolving fast. Tool catalog names, GA versus preview status, and the precise delegated-versus-service-principal propagation semantics should be checked against current Microsoft Learn documentation before you design against them. The architecture principle holds; the exact knobs are still moving.

The APIM AI Gateway Tier Is Microsoft Admitting LLM Traffic Broke Your Gateway

Alex Pechenizkiy — Fri, 31 Jul 2026 15:57:50 +0000

One prompt can cost 100x another, and your gateway cannot tell the difference. As an illustration: a request carrying a 500-token prompt and a request stuffing 50,000 tokens of retrieved context into the same endpoint look identical to a request counter, yet differ by two orders of magnitude on the token meter. Same per-token rate on the Azure OpenAI pricing page, 100x the tokens, 100x the cost. That is arithmetic, not a benchmark.

This is why AI cost governance on Azure fails when it runs on request-based policies, and it is why Microsoft just shipped a dedicated tier for the problem. From the Tech Community announcement: "Today, we are introducing the AI Gateway tier of Azure API Management, now in public preview. It gives platform teams a purpose-built experience." A dedicated tier is Microsoft conceding, in the product structure itself, that LLM traffic is not just another API workload. The Azure API Management AI gateway story started as a bundle of policies bolted onto existing tiers. Now it is a product. That shift tells you more than the feature list does.

Why AI cost governance on Azure breaks generic gateways

Every classic gateway control assumes roughly uniform request cost. Rate limits, quotas, throttling tiers, chargeback by call volume: all of it presumes that 1,000 requests from Team A cost about the same as 1,000 requests from Team B. LLM traffic destroys that assumption. Token counts per request vary by orders of magnitude, model choice multiplies the per-token price, and streaming responses mean the cost of a call is not even known when the request is admitted.

So a rate limit of 1,000 requests per minute is not a cost control. It is a concurrency control wearing a cost control's badge. Two teams can sit under identical request quotas while one of them runs a token bill many multiples of the other's, and your gateway telemetry will show two well-behaved consumers.

The workaround pattern is well documented across community writeups and Microsoft's own samples: parse the usage block out of the completion response, emit a custom metric, build the attribution dashboard yourself. It works in a demo. It falls apart when you add streaming (usage arrives at the end of the stream, if at all, depending on API options), multiple model deployments with different prices, and failover across regions. The custom policy that handled one deployment becomes a maintenance liability the moment you multiply deployments.

If your gateway measures requests instead of tokens, you have monitoring, not governance. I made the longer version of that argument in the engineering case for token-level cost controls, and the new tier is Microsoft agreeing with it.

What is actually in the Azure API Management AI gateway tier, and what is repackaged

Here is the honest lineage, because the announcement-rewrite crowd will not give it to you. Most of the headline capabilities did not appear with this tier. Microsoft shipped them earlier as GenAI gateway policies inside the existing APIM tiers, and they are documented on Microsoft Learn under AI gateway capabilities in API Management: the azure-openai-token-limit and model-agnostic llm-token-limit policies for token-based rate limiting, the emit-token-metric policies for per-consumer token telemetry, semantic caching via cache lookup and store policies backed by a Redis-compatible cache, and backend pools with load balancing and circuit breakers for routing and failover across model deployments.

So the capability delta between "Premium tier plus GenAI policies" and the new tier is smaller than the marketing suggests. What the tier changes, per the announcement's own framing, is the operational model: a "purpose-built experience" for platform teams whose primary traffic is model calls, instead of hand-authored XML policy fragments, a separately provisioned cache, and self-assembled token dashboards in Application Insights.

A caveat on the table below: the left column is verifiable today in the Learn policy docs. The right column reflects the announcement's positioning of a preview product. Treat it as Microsoft's description, not an independently tested capability list, and verify each item against the preview docs before you architect around it.

Capability	Generic APIM tiers + GenAI policies (DIY)	AI Gateway tier (announcement positioning)
Token-based rate limiting	Available: llm-token-limit policy, XML-authored per API or product	Described as first-class in the purpose-built experience
Semantic caching	Partial: policy pair plus a Redis-compatible cache you provision and pay for separately	Positioned as part of the tier; verify cache dependencies in preview docs
Model routing and failover	Partial: backend pools, priority groups, circuit breakers, all wired in policy XML	Positioned as built-in routing across model deployments
Token and cost observability	Partial: emit-token-metric to App Insights, dashboards are your job	Positioned as LLM-aware observability in the tier experience
Configuration experience	XML policy authoring, per-API, easy to drift across teams	The announcement's core pitch: a dedicated platform-team experience
Pricing model	Existing tier price plus cache and observability costs	Preview; no dedicated pricing published on the Azure pricing page at time of writing

The takeaway: judge this tier on the operational delta, not the feature checklist. The features mostly existed. The packaging is what is new, and packaging is what determines whether your platform team actually operates the thing consistently.

The platform team power shift: containing shadow AI

Strong position: routing every model call through a central gateway is the right architecture. Not one option among several. The right one. Direct OpenAI and Azure OpenAI keys scattered across application teams are the new shadow IT, except worse, because the spend is variable, the data exposure is prompt-shaped, and nobody can answer "what did we send to which model last month" at audit time.

Microsoft's own architecture guidance backs the pattern. The Learn architecture center publishes guidance on fronting Azure OpenAI with a gateway: clients hold gateway credentials, the gateway holds managed identity to the model backends, and every consumer gets metered, throttled, and content-filtered at one enforcement plane. Slot this into the broader AI governance framework Microsoft is assembling and the division of labor is explicit: policy and identity form the control plane, and the APIM AI gateway is the enforcement plane. I mapped that larger structure in an AI governance framework on Azure that actually works; the gateway is the layer where the framework stops being a document and starts rejecting requests.

Now the practitioner caveat the docs skip. Onboarding sounds clean until you meet the application teams that embedded raw Azure OpenAI keys long before anyone stood up a gateway. Discovery of shadow usage comes first, and it is archaeology: credential audits, egress inspection, the works. Cutover is not atomic, so you run parallel paths for a while, which temporarily breaks the "single enforcement point" guarantee you bought the gateway for. And a central gateway is a new choke point: budget for high availability and the extra latency hop, because you just put yourself on the critical path of every AI feature in the company.

The takeaway: the gateway only governs traffic that flows through it. Pair adoption with key rotation on the backends and network controls that block direct model endpoints, so bypass is not a choice teams get to make.

Pricing and positioning: when the APIM AI gateway tier beats retrofitting

The honest answer on preview pricing: at the time of writing, the Azure API Management pricing page lists the classic and v2 tiers and does not yet publish dedicated AI Gateway tier pricing. Until numbers appear there, any cost comparison against the tier is structural, not numerical, and anyone quoting you a per-unit figure is guessing.

The structural question still has a real answer, and it hinges on the pricing model shape, not the rate card. Retrofitting means you pay for an existing tier sized for your whole API estate, plus the Redis-compatible cache, plus the observability plumbing, plus the engineering hours to author and maintain policy XML across every AI-facing API. A dedicated tier, if it deploys as its own instance the way the announcement's platform-team framing suggests, means AI traffic gets its own capacity and its own line on the bill.

That gives you actual decision criteria:

Traffic mix. If AI calls are a rounding error next to your REST estate, retrofit. The GenAI policies on your existing tier cover you. If AI is a large or fast-growing share of gateway traffic, a dedicated instance isolates its scaling and its blast radius.
Operational overhead. If your platform team already lives in APIM policy XML, the DIY path costs less than it looks. If they do not, the purpose-built experience is the product you are actually buying.
Isolation and scope. A separate deployment gives AI traffic its own failure domain and its own cost attribution boundary, which is half of chargeback solved by structure alone.

As illustrative math only, using industry-standard inputs (calibrate against your own data, actuals vary): a team spending 20 engineering hours a month maintaining custom token-metering policies is burning roughly an eighth of a full-time engineer on something the tier promises as configuration. Priced at a loaded senior-engineer rate, that recurring eighth of an FTE dominates most plausible rate-card differences. It is the same lesson I keep landing in the spend caps that don't actually cap: the expensive part of AI cost control is never the SKU, it is the engineering you do around the SKU's gaps.

Preview means preview

Read Microsoft's supplemental terms for previews before anchoring a budget or an architecture commitment on this tier. Preview features can change or be withdrawn, carry no SLA, and production support commitments differ from GA services. Do not assume the pricing, terms, or region coverage you see in preview survives to GA.

Decide on traffic mix and organizational scope. The feature checklist will not settle it, because the features mostly exist on both paths.

Preview caveats and a first-week adoption playbook

What not to do yet: production-critical workloads, hard budget enforcement that can block a revenue path, or a wholesale APIM migration. Preview is for building your baseline, not your dependency.

Here is the first move I would make, framed as a recommendation, not a measured result:

Pick one high-volume internal AI workload Internal, because a preview gateway on a customer-facing path is a self-inflicted incident. High-volume, because you want token variance to show up fast.
Route it through the AI Gateway tier Keep the existing direct path warm as a fallback. Yes, this temporarily violates the single-enforcement-point principle. Accept it for the pilot.
Instrument token spend per consumer for two to four weeks Per team, per app, per model deployment. This window is a recommendation for getting a usable distribution, not a measured outcome; noisy workloads need longer.
Compare against your current attribution For most orgs the comparison is against nothing, which is itself the finding you take to leadership.

One more caveat: preview region availability and feature scope shift while a service is in preview, so confirm what is deployable in your regions from the current docs rather than from any blog post, including this one.

The takeaway: use the preview to build your token-spend baseline now. Teams that do this make GA adoption a pricing decision. Teams that wait make it a discovery project.

The bigger signal: Azure is verticalizing infrastructure around AI

Put this release next to its siblings and a direction emerges. AI Foundry as a dedicated development surface. Agent-specific runtimes and tooling. Now an AI-specific tier of a gateway product that has been generally available for over a decade. Azure is giving AI workloads first-class infrastructure treatment rather than bolting AI features onto general-purpose services and calling it done.

My prediction, flagged plainly as opinion with no inside knowledge behind it: expect AI-specific tiers and SKUs in adjacent services. Networking, observability, and identity are the obvious candidates, because token-shaped traffic stresses each of them in ways request-shaped traffic never did. Plan your platform architecture assuming AI traffic gets its own control points, because the vendor clearly is.

For AI cost governance on Azure, that changes the baseline. Token-level governance is no longer an advanced pattern you script into place; it is becoming the product default, and request-level controls are becoming legacy debt. Architect your governance model so an AI-specific enforcement layer is a slot you fill, not a redesign you absorb. The organizations that treat the AI Gateway tier as a slot already had the socket wired. Everyone else is about to find out what retrofitting costs.

DEV Community: Alex Pechenizkiy

Can You Trust AI With Dataverse Security? Four Designs, Three Wrong

The AI Stack You Would Want for Security Work

What This Evidence Does and Does Not Support

The Test Case

Two Failure Classes, Not Three Wrong Designs

Mechanic Error #1: Field Security Profile Block-By-Role

Mechanic Error #2: Parental Relationship to a Comment Child Table

Category Error: JSON Snapshot as Security Boundary

What Are the Correct Dataverse Security Designs for This Case?

The Real Architectural Axis: What Is Cheap to Mechanically Verify?

Why the Tools Didn't Catch It: Orchestration, Not LLM Failure

Where Is the Trust Boundary for AI in Microsoft Security Code?

What I Would Build Now

What I Would Actually Do Today

Frequently Asked Questions

AI Orchestration for Legacy Systems: The Operational Front Door Pattern (2026)

What Is the Operational Front Door?

A Scale Precedent, Before AI Orchestration Was Viable

The 2026 Reference Architecture for AI Over Legacy Systems

Layer 1: Channels

Layer 2: AI Front Door (Copilot Studio)

Layer 3: Orchestrator (Foundry Agent Service)

Layer 4: Two-Layer RAG

Layer 5: Connector Layer (MCP Gateway)

Layer 6: Legacy Systems of Record (Unchanged)

Side: AI Provider Plane (Interchangeable)

Cross-Cutting: Identity + Governance

The Two-Layer RAG, in Detail

Layer 1: Org / Skills / Process (Slow, Curated)

Layer 2: Live Case State (Fast, Derived)

The Join at Query Time

Vendor Independence, in Practice

Where Microsoft, Copilot Studio, and Foundry Actually Fit

What This Does Not Do

Cost Shape (Illustrative)

When This Breaks at Month 6

CIO Checklist

The 24-36 Month Window for AI Over Legacy Systems

Read Next

The Six Agentic Adoption Patterns: A Practitioner Decode of Microsoft's New Playbook (2026)

The Assist to Execute Shift

Six Adoption Patterns, Not Stages

The 5x5 Maturity Model

The Top 5 Scale-Breakers

The CoE Framework: Three Structures, Matched to Pattern

Risk-Tiered Governance

The 90-Day Play

Where the Playbook Will Land for Different Enterprise Types

The Line Buried on Page 52

Read Next

The Scale-Breaker Microsoft Doesn't Name: Why Your AI Program Stalls Where the Playbook Doesn't Look (2026)

The Five Named Drivers

The Sixth Driver: Political Maturity

Where Political Maturity Bites

Why the Framework Does Not Name It

The Sixth-Driver Test

What to Do When Political Maturity Is Low

The Honest Read for the Steering Committee

Read Next

Risk-Tiered Agent Governance: Microsoft's Tier 1/2/3 Model Annotated for Real Deployments (2026)

The Playbook's Three Tiers (Source Frame)

Tier 1 (Low Risk): Productivity Agents

Concrete controls

Escalation triggers (when Tier 1 becomes Tier 2)

Tier 2 (Medium Risk): Expert and Internal Service Agents

Concrete controls

Escalation triggers (when Tier 2 becomes Tier 3)

Tier 3 (High Risk): Business-Critical and External-Facing

Concrete controls

Three Tier 3 controls I would add beyond the playbook

Tier 0: The Tier the Playbook Does Not Name

What Tier 0 includes

Why Tier 0 is the highest-priority governance work

Controls for Tier 0: discovery before governance

Operationalising the Tier Classification

The Honest Read for the Steering Committee

Read Next

The Pilot Trap: Why Most Agent Initiatives Never Become Portfolio (2026)

Why Pilots Stall