The new editor: rich-formatted instructions on the left, everything else stacked on the right

For a while now, building an agent in Copilot Studio meant bouncing between tabs — one for Tools, another for Knowledge, another for the rest. The new editor collapses all of that into a single page. And the best part: it doesn’t replace the classic experience, it sits right next to it.

Flip one toggle to try it

The new editor is gated behind a New experience toggle in the top-right of Copilot Studio. Turn it on and you land in the redesigned builder; turn it off and you’re back in the classic agent editor you already know. The two modes coexist, so you can experiment without committing your whole team to it.

The New experience toggle lives in the top-right — flip it on or off any time

Everything on one page

The biggest change is layout. Instead of separate tabs, the new editor keeps your instructions front and center, with a single right-hand pane that stacks everything else:

• Model — pick the model that powers the agent (Claude Sonnet 4.6 was front and center in the preview).
• Microsoft IQ — the grounding layer that brings in your organizational context.
• Skills — attach SKILL.md files as reusable playbooks.
• Tools — add and configure actions inline.
• Knowledge — point the agent at your sources.
• Connected agents — call other agents.

You stop hunting through tabs and start seeing your whole agent at a glance.

Instructions you can actually format

The instructions field now supports rich formatting — bold, numbered lists, code blocks, and links. This isn’t just cosmetic. Well-structured instructions are easier for you to maintain, and they help the model parse the rules and guidelines more reliably. Bold the hard constraints, number the steps it should follow in order, and drop a code block in when you need an exact format. Both the human and the AI benefit.

Skills: a new primitive that runs Python

The headline addition is Skills — a new primitive that replaces the old topics-and-child-agents model with something far more composable. You attach SKILL.md files straight into the agent, including skills you authored elsewhere — in Codex, Claude Code, or another AI tool — and you can add more than one. There’s also a search so you can find skills to wire in.

The kicker: Skills can execute real Python, right inside your agent. Each agent runs in its own container, so file generation and analysis just work — produce a report, run a data transformation, hand the user back a polished artifact — without bolting on a flow to do it. It’s a clean way to give your agent focused, reusable playbooks instead of cramming everything into the instructions block.

It’s a rebuilt runtime, not a reskin

This is the part that’s easy to miss: the new editor isn’t a coat of paint over the old engine. The orchestration and authoring layers were rebuilt on a proper agentic harness — a loop that calls the model, dispatches tool calls (including MCP servers), feeds the results back, and keeps going until the task is done. If you used Enhanced Task Completion in the classic UI, this is the same backend, now with a home that matches its capabilities.

Knowledge, memory, and guardrails are first-class in this runtime — native to how it executes, not workarounds layered on top. Combined with Python Skills and containerized execution, it’s a meaningfully different product than what existed six months ago.

Configure tools inline

Tools are now set up on the same page, not in a separate detour. When you add a tool, you see all of its inputs laid out — including which ones are required — and configure inputs and outputs right there. Fewer clicks, less context switching.

Preview exactly what the end user sees

The new editor adds an End user preview toggle that mirrors precisely what the person chatting with your agent will experience. It’s a small thing that saves a lot of “wait, why does it look different for them?” moments before you publish. The agent list, meanwhile, now shows Status (Draft / Published) and Channel columns so you can see at a glance where each agent stands. Evaluate and Monitor work the same as before.

A balanced take

It’s a genuinely nicer way to build — but it’s worth knowing the trade-offs people are flagging:

• Preview only, Early Release required. You can’t just flip a switch in any tenant — you need an Early Release environment to access the new editor. Keep it off production.
• Classic agents aren’t going away. Topics, broader channel deployment, and full analytics still live on the mainline orchestrator. Pick the right tool: classic for those scenarios, the new editor for new builds that want true agentic behavior.
• The activity map isn’t in the test panel. If you relied on watching the orchestration path while testing, that view isn’t surfaced in the new editor’s test experience yet.
• Single-page vs. tabs is a preference. Some builders liked the old tabbed layout for keeping a complex agent organized. Everything-on-one-page is faster for small and medium agents, but a very large agent can feel dense.

Why it matters

This is arguably the moment Copilot Studio stops being “low-code with an LLM bolted on” and starts being a proper agentic platform. Skills + Python + MCP + a containerized runtime add up to something genuinely new. The toggle means there’s low risk in trying it in an Early Release environment — build something, and flip back to classic if you need topics or broader channels. Given how quickly it’s moving through preview, getting familiar now means you won’t be caught off guard when it becomes the default.

#CopilotStudio #AgentBuilder #PowerPlatform #MCP #AIAgents

On one side, an open ecosystem is forming around Agent Skills — small SKILL.md files published on GitHub that teach an agent how to do something specific. Anyone can write one. Anyone can fork one. It’s the README, but for behavior.

On the other side, enterprises are standing up governed skill layers inside platforms like Microsoft Dataverse — “business skills” that live behind identity, policy, and admin approval, and that any connected agent can pick up at runtime.

Both sides are growing fast. Neither side talks to the other. The open community ships skills daily that never make it past the firewall. The enterprise side hand-authors skills from scratch that someone, somewhere, has already written better.

That gap is what I wanted to close. So I built SkillWright — a Copilot Studio agent whose entire job is to source, vet, and install skills for other agents.

Repo (open source, swagger + agent assets included): 👉 https://github.com/dvsRCalejo/SkillWright

What it is

SkillWright is not a chatbot. Think of it as a procurement function — but for behavior, not software.

Give it a topic. It goes out to public GitHub, finds candidate skills, reads them, judges whether each one is actually useful, and — for the ones I approve — installs them as business skills in Dataverse. From that moment on, every agent connected to the Dataverse MCP server can discover and use them. No rebuild. No redeploy. Update the skill once, and every agent that picks it up next gets the new version.

It’s authored entirely in Copilot Studio, source-controlled with the skills-for-copilot-studio VS Code tooling, and shipped as a normal solution. No custom hosting, no glue code.

What it needs to run

I want to be honest about the platform floor here, because SkillWright leans on it:

• A Managed Environment in Power Platform (for governance and policy).
• Dataverse Intelligence enabled — this is what unlocks business skills as a first-class concept.
• Dataverse MCP Server (preview) available in the environment.
• A GitHub custom connector (the one in the repo, defined by a Swagger file), authenticated with a fine-grained PAT scoped to read public repo contents.

If any of those are missing, the agent will still load, but creation calls will fail — and rightly so. The governance layer is the point.

How it works

There are three moving parts, and I deliberately kept each one boring.

Discovery is a custom GitHub connector with a small, surgical set of operations: search code, search repos, get a repo, get a tree, get a blob. The agent’s go-to query is filename:SKILL.md — every result whose path ends in /SKILL.md is, by convention, one skill. For folder-based skills it walks the tree recursively and pulls each file as a base64 blob.

Vetting is where the agent earns its keep. It fetches the candidate SKILL.md, decodes it, parses the name and description (which can live in YAML frontmatter or a markdown table — both are out there in the wild), and judges it against the bar I care about for business skills: clear trigger phrases, numbered step-by-step instructions, concrete examples, troubleshooting notes. Skills that turn out to be developer tasks in disguise — a scripts/ folder, a tool wrapper, something that only makes sense if you also have a shell and three CLIs installed — get flagged with a reason before I commit.

Install is one call to the Dataverse MCP server, which creates the approved skill as a business skill — name, description, instructions, and any references/ files attached as Resources. No custom storage layer, no bespoke schema, no form to fill in. Honestly, it’s easier for the agent to create a well-formed business skill than it is for me to do it by hand in the maker portal — it already has the parsed content in front of it, knows the shape Dataverse expects, and just submits it. And critically: nothing is installed without an explicit confirmation from me.

The bit I find genuinely interesting

Here’s the insight that made the whole thing click: Agent Skills and Dataverse business skills use the same format. Same shape. Same semantics. Same SKILL.md.

That sounds like a small technical detail. It isn’t. It means the open skill ecosystem on GitHub and the governed enterprise skill layer in Dataverse aren’t two different worlds that need translation between them — they’re the same world with a border crossing in the middle. SkillWright is the border crossing.

There’s a second, weirder consequence — and this is the one I keep coming back to. The Dataverse MCP server doesn’t just write business skills; it also reads them. So the moment SkillWright finishes installing one, any other Copilot Studio agent connected to that same MCP server can see it, pick it up, and act on it on its next turn. No re-publish. No “add a skill to this agent” step. No coordination between maker and consumer. One agent installs, every other agent benefits — automatically.

That includes SkillWright itself. The very same agent that just installed a skill can immediately turn around and use it. The first time I watched it install a skill and then, in the next turn, behave according to that skill, I felt like I’d quietly crossed a line.

Why I think this matters

Reuse. Most of the skills any given business needs have already been written by someone on the internet. Hand-authoring them again is wasteful. Sourcing them — with judgment — is not.

Governance without lock-in. The enterprise gets approval, audit, identity, and a single place to manage what agents are allowed to know. The community gets the open SKILL.md format, no proprietary fork. Nobody has to give anything up.

Runtime discovery beats redeployment. Once a skill lives in Dataverse, every connected agent finds it on its own — no code change, no release, no per-agent wiring. That’s a very different operating model from “ship a new agent.”

Where this goes next

I’m now thinking less about SkillWright itself and more about what changes when skill curation becomes a job an agent can do. If sourcing skills is cheap and governed, the constraint on agent capability stops being “what did we build” and starts being “what did we choose to admit.” That’s a much more interesting constraint.

If you want to poke at it, fork it, or break it — the repo is here: https://github.com/dvsRCalejo/SkillWright

Which makes me wonder — and this is the real question I’d love your take on:

If your agents could quietly pick up new skills from the public internet, vetted but not authored by you, would you let them? And where exactly would you draw the line?

#CopilotStudio #PowerPlatform #Dataverse #MCP #AgentSkills

Most institutional knowledge lives in three places: a Word doc nobody opens, a flow somebody built two years ago, and the heads of the two senior employees who actually know how things work. The moment you point an AI agent at it, you start re-implementing that knowledge inside the agent — and again in the next agent — and again the next time the process changes.

Business skills, now in public preview in Dataverse, fix that.

What a business skill actually is

A business skill is a record stored centrally in Dataverse that captures one of your organization’s processes, policies, or pieces of domain expertise as natural-language instructions — the steps, the information required, and the business rules that apply.

Think of it as a runbook the agent reads and follows:

• “How do we qualify an inbound lead?”
• “How do we approve a discount over 15%?”
• “How do we run an onsite HVAC inspection — what questions to ask, by equipment class?”
• “How do we onboard a new vendor — accounts, documents, approvals, due-diligence checks?”

You write the steps once, in plain language. Agents do the rest.

How agents pick them up: the Dataverse MCP server

Business skills are surfaced through the Dataverse MCP server. Any agent connected to that server discovers relevant skills automatically at runtime and uses them to complete tasks against your Dataverse data — according to your organization’s standards.

Because they live in Dataverse and ride on MCP, the same skill works across every MCP-compatible client:

• Microsoft Copilot Studio
• GitHub Copilot
• Visual Studio Code
• Azure AI Foundry
• Any other MCP client your team uses

Define a skill once, and every agent that should follow it does — without you porting logic between platforms.

Why “central in Dataverse” is the magic word

This is the bit makers usually miss. Storing a skill once in Dataverse instead of once per agent changes the operating model:

No republishing. No tracking down individual agent configurations. Update the source of truth and the change applies everywhere.

Create, share, and govern from Power Apps

Business skills live in Dataverse, but you author and manage them in Power Apps. From make.powerapps.com you can:

• Create a skill by writing the process in natural language, or upload existing documentation (an SOP, a runbook, a process Word doc) and let it become the skill.
• Share with specific people, teams, or security roles using the standard Dataverse sharing model.
• Govern with built-in visibility controls — who can see it, who can edit it.
• Deploy across environments by adding the skill to a Power Platform solution and shipping it through your existing ALM pipelines.

Prefer to work conversationally? You can create and update skills by asking an agent, through the Dataverse MCP server itself.

A real customer example

Velrada built Inspection Agent to help worksite supervisors and field workers track equipment maintenance. The agent uses business skills to drive the inspection itself: for an onsite HVAC check, it invokes a skill that determines the right questions for that equipment class, looks up the last inspection outcomes, and pulls in historic issues — producing a consolidated, conversational report and follow-up guidance.

Update the inspection process for HVAC units, and every Inspection Agent in the field follows the new steps the next time it runs. No app updates. No re-deployments.

Who this is for

Business skills are aimed at three audiences:

• Makers who want to codify how their team actually operates instead of re-explaining it to every agent.
• Agent builders who need agents to follow real, organization-specific processes — not generic LLM instructions.
• Admins who need governance over how business knowledge is shared, versioned, and deployed across environments.

Get started

To switch this on today (public preview):

1. Enable Dataverse intelligence in the Power Platform admin center for the target environment.
2. Open Power Apps and go to the Business skills page from the left navigation.
3. Create your first skill — write it in natural language or upload an existing process document.
4. Connect an agent to the Dataverse MCP server and watch it discover and follow the skill.

Want a head start? Microsoft ships a sample business skills repository on GitHub with production-ready examples you can install directly into your environment.

If you’re already building agents, business skills are the missing layer between what the agent knows and what your organization actually does. Start small: pick one process that’s currently re-implemented in two or more agents, write it as a business skill, and rip the duplicates out. The first time the process changes and you only edit it in one place, you’ll feel the difference.

Learn more

• What is Dataverse intelligence?
• Business skills overview
• Create and use business skills
• Sample business skills on GitHub
• Announcement: Introducing business skills — Teach agents how your organization works

Most teams stop at Solution Checker. Solution Checker is great for platform-level safety (deprecated APIs, security smells, supportability), but it doesn’t grade craftsmanship: control naming, formula complexity, delegation issues, topic design in agents, trigger phrase quality, and the dozens of other things that separate a healthy solution from one that will haunt you in production.

The good news: you can wire Solution checker enforcement (at the environment) + Power CAT Tools Code Review (for craftsmanship) + Copilot Studio Kit (for agent governance) + Power Platform Pipelines gated extensions (the glue) into a single multi-dimensional quality gate. None of these are new tools — they’re just rarely combined.

Layer 1 — Solution Checker, enforced at the Managed Environment

This is the foundation. Solution Checker enforcement is configured per Managed Environment, not per pipeline. When set to Block, any solution with critical issues is rejected at import time — before anything changes in the environment — regardless of whether it arrived through a pipeline, a manual import, or DevOps.

Set this once on each target environment (or, even better, on an environment group so every member environment inherits it — pair this with the Default Deployment Pipeline rule and you get governance-by-default for every new environment).

But Solution Checker won’t tell you that a canvas app has 800 controls on one screen, or that a Copilot Studio topic has only one trigger phrase. That’s where layer 2 comes in.

Layer 2 — Power CAT Tools: real code review for makers

The Power CAT Tools suite ships a Power Platform Code Review tool that analyzes solutions against a customizable checklist of patterns. Some patterns are evaluated automatically (control counts, media size, network traces, formulas), others are marked pass/fail by a reviewer with comments and links back to specific code locations.

What it covers today:

• Canvas apps — control limits, embedded media, slow network requests, formula breakdowns, App Checker integration.
• Power Automate — flow patterns from POWERAUTOMATE_PATTERNS.md.
• Copilot Studio agents — the Copilot Studio Agent patterns: trigger phrase count, single-word phrases, long phrases, condition count, flow count, SharePoint auth mode, unused topics, synonyms quality, duplicate regex entities, end-of-conversation usage.

A review produces a summary dashboard (passed / failed / pending patterns) plus detailed insights — all stored in Dataverse tables in the governance environment. That’s the key: the results are queryable.

Layer 3 — Copilot Studio Kit for agent governance

For Copilot Studio agent solutions, the Copilot Studio Kit adds the behavioral dimension that even Power CAT can’t see: conversation analytics, escalation rates, topic coverage, session quality. If your pipeline is shipping an agent, the agent’s runtime data is part of the review, not just its design.

Layer 4 — Power Platform Pipelines gated extensions

This is what turns the above from “tools we have” into “gate every deployment must pass.” Power Platform Pipelines exposes three gated extensions — custom steps you can insert into a deployment and signal complete or reject:

• Pre-export Step Required — fires OnDeploymentRequested. Runs before the solution is exported from the dev environment. Only enabled on the first stage (e.g., Dev → UAT). This is where you put the code-review gate.
• Is Delegated Deployment — for service-principal-based approvals.
• Pre-deployment Step Required — fires OnPreDeploymentStarted after approval, before the deployment runs in the next environment.

Each gated step stays pending until your custom logic calls back with the right action:

• UpdatePreExportStepStatus (or UpdatePreDeploymentStepStatus) with status 20 = complete, deployment continues.
• Same action with status 30 = reject, deployment fails. You can include both maker-facing comments (“Your canvas app has 412 controls on screen BrowseGallery1 — please refactor before resubmitting”) and admin-facing comments.

Putting it together: the gate flow

In your pipelines host environment, build a cloud flow that:

1. Triggers on OnDeploymentRequested (Dataverse → When an action is performed → category Power Platform Pipelines) — optionally filtered by pipeline name with a trigger condition like @equals(triggerOutputs()?['body/OutputParameters/DeploymentPipelineName'], 'Contoso Pipeline').
2. Identifies the solution being deployed from the trigger output parameters.
3. Queries the governance environment (Power CAT Tools Dataverse tables) for the most recent Code Review record for that solution. Decision logic, for example:
   • Reject if no review exists in the last N days.
   • Reject if any critical pattern is marked Failed.
   • Reject if the pass rate is below your threshold.
4. For Copilot Studio agent solutions, additionally query Copilot Studio Kit data for the agent’s quality scores.
5. Calls UpdatePreExportStepStatus (Dataverse → Perform an unbound action) with status 20 and a confirmation comment, or status 30 with a reject comment listing exactly what failed.

The maker sees the result inline in the pipeline run history — including your comments — and either fixes the issues and resubmits, or proceeds. The solution isn’t even exported until the gate clears.

Microsoft ships a PipelinesExtensibilitySamples managed solution with starter flows for all three gated extensions — start there and replace the placeholder logic with your Power CAT / Copilot Studio Kit lookups.

Why this combo is the magic, not just one of them

Each layer covers what the others don’t:

Run all four and your pipeline stops being a deployment mechanism — it becomes a maker enablement loop. Every deployment teaches the maker something concrete and gives them a self-service path to fix it. No manual code reviews, no admin tickets, no “we’ll check it later in production.”

A note on staging the rollout

Don’t enable rejection on day one — you’ll create a riot. The recommended ramp:

1. Sprint 1–2: Build the gate in observe-only mode — always call UpdatePreExportStepStatus with status 20 (complete) but log what would have been rejected.
2. Sprint 3–4: Switch to warn mode — complete the step but post the would-have-been-rejected comments to the maker so they see what’s coming.
3. Sprint 5+: Flip to block — start rejecting on the patterns the team has agreed are non-negotiable. Keep the rest as warnings.

Same staging works for the Solution Checker enforcement on Managed Environments (Off → Warn → Block).

This is one of those quiet-but-powerful combinations that the platform fully supports today — almost nobody connects all the pieces. If you already have pipelines and Managed Environments, you’re three configuration steps and one cloud flow away from automated, multi-dimensional code review on every deployment.

The trick lives inside the Execute Agent action. Most people only fill in Body/message and miss the attachments array hidden under Advanced parameters. That array is what lets your agent actually receive the document and reason over it.

The pattern in one picture

The recipe is just two actions:

1. Get file content (SharePoint) — fetch the bytes of the file.
2. Execute Agent — call your Copilot Studio agent and attach the file.

Here’s what those two actions look like in the designer, with the attachment array expanded inside Execute Agent:

Step 1 — Get file content from SharePoint

Add the SharePoint → Get file content action and configure:

• Site Address: the site that hosts the document.
• File Identifier: the path to the file, for example /Shared Documents/Zava Launch Demo - Get Started Guide.pdf.
• Infer Content Type: Yes (so the connector returns the right MIME type).

This step gives you a $content token that holds the file as base64-encoded bytes — exactly what the agent needs.

Step 2 — Add the Execute Agent action

Add Execute Agent and pick the agent you want to call. Then expand Advanced parameters → Show all and turn on A list of attachments.

Add one item to the attachments array and fill it in like this:

Then set Body/message to whatever you want the agent to do with the file, for example:

Please summarize this

That’s it. When the flow runs, the agent receives the file as an attachment and can read, summarize, extract, classify, or route it.

Why the data URL matters

The Contenturl field is not a SharePoint link. It’s a data URL that inlines the file bytes into the request:

data:<mimetype>;base64,<base64-bytes>

Concretely, you build it as:

data:application/pdf;base64,@{outputs('Get_file_content')?['body']}

The $content placeholder shown in the designer is just a friendly handle for that body output. The agent runtime decodes the base64 and treats it as a real attachment, the same way it would if a user dragged the file into chat.

Common MIME types you’ll use

Match the extension in Name to the MIME type — agents (and downstream model calls) use both signals to pick the right parser.

Where this pattern shines

• Document intake: a SharePoint library trigger fires, the flow pushes the new file to an agent that classifies, extracts fields, or routes for approval.
• Email attachments: replace step 1 with “Get attachment (V2)” from Outlook and forward the attachment straight to the agent.
• Form uploads: a Power Apps or Forms upload lands in OneDrive/SharePoint, then an agent flow summarizes it back to the user.
• Bulk processing: loop over a folder, send each file to the agent, and store the structured response in Dataverse or a list.

Things to watch out for

• Size limits: Execute Agent attachments inherit the agent’s file size limits. Very large PDFs may need to be split or pre-processed.
• Don’t double-encode: Get file content already returns base64 in its body. Just prefix with data:<mime>;base64, — don’t run it through base64() again.
• One attachment per item: each file is one entry in the array. Use Add new item for multi-file calls instead of stuffing several files into one entry.
• Pick the right MIME type: if you set application/pdf but pass a Word file, the agent will struggle to parse it.

Why this is a big deal for agent flows

Agents become dramatically more useful when they can act on real documents instead of just text. Once you’ve wired this two-action pattern, you can chain it with classification, generative answers, Dataverse writes, or approvals — all from the same flow that picked the file up.

Two actions. One hidden Advanced parameter. A real document in your agent’s hands.

If your organization is already running Copilot Studio agents, custom agents, or third-party agents, this launch is the moment to stop treating agents as individual projects and start managing them like a workforce.

Agent 365 positions AI agents as a governable, securable workforce at enterprise scale.

What Agent 365 is (and is not)

Agent 365 is not another agent builder. It is the governance, security, and observability layer that sits over every agent in your environment, regardless of where it was built.

At GA, the value is centered on five pillars:

• Registry - centralized inventory of every agent, including shadow agents
• Access control - using Microsoft Entra Agent ID for least-privilege identity
• Visualization - dashboards for performance, connections, and business impact
• Interoperability - works with agents from Microsoft, open-source frameworks, and third-party platforms
• Security - integrated with Microsoft Defender, Microsoft Entra, and Microsoft Purview

Agent 365 surfaces agent inventory and key analytics inside the Microsoft 365 admin center.

The reality check: agents are scaling faster than governance

Organizations are already seeing the classic pattern:

• Business teams ship Copilot Studio agents quickly
• Pro-code teams build custom agents with Agent Framework
• Vendors introduce third-party agents into Teams and Microsoft 365
• Nobody has a single, trustworthy view of all agents running in the tenant

Agent 365 is Microsoft’s answer to agent sprawl. But the product cannot fix the absence of ownership, policies, or identity hygiene - only your program can.

Build the house from the ground

Treat Agent 365 like the walls and roof of your AI program. Walls only work on a solid foundation. If you skip the foundation, you end up with governance that looks nice in a slide but cracks under real usage.

Foundation layers to put in place before GA:

1. Ownership Define who owns AI agent lifecycle, who owns security, and who owns compliance. Typically this is a joint model between IT, security, data, and platform CoE.

2. Identity Microsoft Entra Agent ID is the access-control anchor. Agents should have identities, not shared credentials, and should follow least-privilege principles.

3. Classification Classify agents by risk - internal productivity, customer-facing, data-modifying, regulated-data. Governance intensity should match risk tier.

4. Data boundaries Use Microsoft Purview for sensitivity, data loss prevention, and auditability. Agents that consume enterprise data must respect information protection policies.

5. Threat protection Use Microsoft Defender for runtime protection and incident response. Agents add new attack surfaces like prompt injection, tool abuse, and data exfiltration via tools.

6. Observability Decide what you will monitor - agent usage, success rate, tool invocations, failures, cost, and drift. Agent 365 provides dashboards, but you must know what “healthy” looks like per agent type.

A simple 30/60/90 plan to be ready

First 30 days

• Produce an agent inventory across Copilot Studio, custom agents, and third-party agents.
• Identify shadow agents that were not registered through IT.
• Assign owners per agent (business owner + technical owner).

Days 30 to 60

• Enable Microsoft Entra Agent ID readiness for production agents.
• Expand Microsoft Purview scope to cover agent data flows.
• Stand up a risk tiering model and map each agent into a tier.

Days 60 to 90

• Enable Agent 365 on the environments that matter most.
• Establish weekly governance reviews of usage, risk, and incidents.
• Publish the AI agent operating model internally - makers need to know the rules.

Why this matters for enterprise leaders

AI agents are starting to act like a digital workforce. That means you need:

• An HR-style lifecycle for agents (onboarding, access, deprecation)
• A security model for non-human identities
• A financial model for cost attribution
• A compliance model for auditability

Agent 365 gives you the product surface to do this consistently. But the operating model has to be owned by you, not by the tool.

Common mistakes to avoid in the GA window

• Treating Agent 365 as a license purchase only - it is an operating model change, not just a SKU
• Starting with tooling before ownership - without accountable owners, dashboards are ignored
• Ignoring shadow agents - unregistered agents represent the biggest real risk
• Skipping risk tiering - if every agent has the same controls, high-risk ones are under-governed and low-risk ones are over-governed
• Relying on one-time reviews - agent behavior, prompts, and tools change constantly; governance must be continuous

What to do this week

• Nominate an Agent 365 program owner
• Start the agent inventory
• Align IT, security, and data teams on a shared AI governance baseline
• Put a May 1 readiness checkpoint on the calendar

The organizations that will benefit most from Agent 365 on day one are not the ones with the most agents. They are the ones with the clearest foundation. Build the house from the ground - identity, classification, data, threat, observability, ownership - so Agent 365 becomes the control plane you already needed, not a dashboard nobody trusts.

Learn more

• Microsoft Agent 365 announcement
• Microsoft Ignite 2025 Copilot and agents recap
• 6 core capabilities to scale agent adoption in 2026

If your team still discovers reliability issues from user tickets, this release is a big deal. GA means the capability has reached Microsoft reliability and maturity standards for production use, not just experimentation.

The alerts-centric Monitor overview gives you instant visibility into active alert conditions.

What is now GA, exactly?

Power Platform Monitor alerts let tenant and environment admins define threshold-based alert rules on operational health metrics and get notified when conditions are breached.

At GA, you get two layers of value:

• Predefined alerts from Microsoft enabled by default at tenant scope
• Custom alert rules you create for environment-wide or resource-level monitoring

This combination is strong: predefined alerts help you spot obvious risk immediately, while custom rules let you tune thresholds to your own SLAs.

The biggest GA upgrade: predefined alerts

Predefined alerts are the fastest way to get signal without setup. Microsoft now provides built-in alert definitions for high-use resources with degraded health.

Examples include high-use resources dropping under baseline thresholds like:

• Canvas app availability under 90%
• Model-driven app availability under 90%
• Cloud flow success rate under 90%
• Desktop flow success rate under 90%
• Agent success rate under 90%

These predefined alerts are:

• Turned on by default
• Tenant-wide
• Not editable
• Visible in Monitor (they do not send email notifications)

Predefined alerts surface high-use resources with degraded health, even before you create custom rules.

What custom alerts give you in GA

Custom alerts are where operations teams create real monitoring ownership.

You can configure:

• Product and resource type (Power Apps, Power Automate, Copilot Studio)
• Scope (environment or specific resource)
• Metric, operator, and threshold
• Severity (Low, Medium, High)
• Email notifications to you and up to four additional recipients

Custom alert rules let you monitor what matters to your organization, not only Microsoft defaults.

You can also manage rules centrally from the alert rules list.

Manage, enable, disable, edit, and review your custom alert rules from one place.

Important GA realities admins should know

• Alerts are evaluated on a 24-hour cadence, based on aggregated metrics.
• Custom alert rules currently require Managed Environments.
• Tenant administrators and environment administrators can create/manage alerts.
• A tenant can have up to 50 alert rules turned on at one time.
• Predefined alerts are view-only and currently cannot be disabled.
• Predefined alerts do not send email; custom alerts can.

This means you should treat Monitor alerts as proactive daily health signals, not real-time incident paging.

Recommended rollout pattern

Use a phased rollout so your team gets value fast without creating alert noise.

1. Start with predefined alerts Review Monitor overview and identify which high-use resources are already showing degradation.

2. Create 3-5 high-value custom rules Prioritize production environments and business-critical apps/flows.

3. Standardize naming Use names like Prod - Cloud flows - Success rate under 95.

4. Set triage ownership Define who checks alerts daily, who contacts makers, and who tracks remediation.

5. Tune thresholds monthly Avoid stale thresholds as usage and load patterns change.

What is supported now

Based on GA guidance and current documentation, alerting supports:

• Code apps
• Canvas apps
• Model-driven apps
• Cloud flows
• Desktop flows
• Agents

Work queue alerts are also available, but remain public preview.

Why this matters for enterprise governance

Monitor alerts close a real operational gap in many Power Platform programs:

• Governance teams get measurable health visibility
• Makers get earlier feedback before users complain
• Operations teams can prioritize by severity and usage impact
• Leadership gets a path from reactive support to proactive reliability

If your platform strategy includes scale, this GA feature should be part of your standard operating model now.

Learn more

• GA announcement: https://www.microsoft.com/en-us/power-platform/blog/power-apps/power-platform-monitor-alerts-are-now-generally-available/
• Official alerts documentation: https://learn.microsoft.com/en-us/power-platform/admin/monitoring/alerts

If your cloud flow calls APIs, databases, or line-of-business systems, those credentials have to live somewhere. Storing them in plain text variables, desktop flow steps, or copied notes turns every export, run history, and ownership change into a security event waiting to happen.

Azure Key Vault gives you centralized secret storage, rotation, and auditability. When you combine it with connection references and environment variables inside solutions, you get a deployment model that is secure and ALM-friendly.

Why Key Vault matters for cloud and desktop flows

• Centralized secret management: Credentials and API keys live in one controlled location, not scattered across flows.
• Rotation without flow redesign: Update the secret in Key Vault and keep the same secret name/version strategy so flows continue working.
• Audit and control: Access to secrets is monitored and governed in Azure.
• Cleaner ALM: Solutions move between environments without embedding environment-specific credentials.

For desktop automation specifically, this is critical. Desktop flows often need sensitive values (system credentials, API tokens, file encryption keys). The secure pattern is to retrieve secrets in the cloud flow at runtime, then pass them into desktop flow inputs as late as possible.

Target architecture (what “good” looks like)

Azure side

• One Key Vault per environment (kv-contoso-dev, kv-contoso-test, kv-contoso-prod)
• Same logical secret names across environments (for example, erp-api-key)
• Least-privilege access for the identity behind your Power Automate Key Vault connection

Power Platform side

• One solution containing cloud flows, desktop flows, connection references, and environment variables
• Environment variables for vault-specific settings (vault name, secret name, endpoint if needed)
• Azure Key Vault connection reference reused by flows
• Cloud flow retrieves secret, then invokes desktop flow

ALM side

• Unmanaged solution in Dev
• Managed solution in Test and Prod
• Connection references remapped per environment during import
• Environment variable values set per environment

Step-by-step implementation

Step 1: Create Key Vaults per environment

In Azure, create separate vaults for Dev, Test, and Prod. Do not share one vault across all environments.

Use a naming standard such as:

• kv-contoso-dev
• kv-contoso-test
• kv-contoso-prod

Create secrets with the same logical names in each vault:

• erp-api-key
• pad-runtime-password
• legacy-system-client-secret

The values differ by environment, but the names stay consistent. This simplifies flow design and ALM mapping.

Register the Power Platform resource provider and baseline Key Vault setup in Azure.

Step 2: Grant least-privilege access to secrets

Give the identity used by the Power Automate Azure Key Vault connection only the permissions it needs (typically secret read operations).

Good practice:

• Scope access at vault level for the specific environment
• Avoid broad contributor/owner roles when only secret read is needed
• Use dedicated service principals/identities per environment when possible

This prevents Dev automations from accidentally reading Prod credentials.

Grant least-privilege access with Key Vault Secrets User for users and service principals that need secret retrieval.

Step 3: Build a solution-first design in Power Platform

In your solution, create:

• Cloud flow(s)
• Desktop flow(s)
• Azure Key Vault connection reference
• Environment variables

Recommended environment variables:

• KV_VaultName
• KV_SecretName_ErpApiKey
• KV_SecretName_PadPassword

Do not hardcode vault names or secret names in flow actions when ALM matters.

Step 4: Configure the Azure Key Vault connection reference

Inside the solution:

1. Create a connection reference for Azure Key Vault.
2. Bind it to the appropriate environment identity/account.
3. Use this connection reference in all Key Vault actions.

Connection references are what make solution imports manageable. They let you rebind to environment-specific connections at deployment time.

Use Dataverse secret retrieval in your cloud flow so values come from Key Vault at runtime, not from hardcoded steps.

Step 5: Build the cloud flow secret retrieval pattern

In your cloud flow:

1. Trigger (manual/scheduled/event-driven).
2. Read KV_VaultName and secret-name environment variables.
3. Use Azure Key Vault action (Get secret) with those values.
4. Immediately pass the secret to where it is needed (HTTP action, connector call, or Run desktop flow input).
5. Avoid persisting secret values in Dataverse rows, compose outputs, or logs.

Security hardening in the flow:

• Enable Secure Inputs and Secure Outputs on all actions touching secret content.
• Avoid unnecessary Compose/Append variable steps that duplicate sensitive data.
• Keep secret handling to the smallest possible action chain.

Turn on Secure Inputs and Secure Outputs for every action that handles secret values.

Step 6: Pass secrets to desktop flows safely

For Power Automate Desktop orchestration:

1. Define desktop flow input variables for sensitive values.
2. In the cloud flow, map Key Vault secret output to those inputs.
3. In the desktop flow, consume the input only where required and avoid writing it to logs/files.
4. Keep machine/runtime account permissions minimal and scoped to workload needs.

Important: The desktop flow should not become a second secret store. Treat inbound credentials as transient runtime values.

Tip: For desktop scenarios that must authenticate with Key Vault-backed credentials, use the official Power Automate for desktop setup guide: https://learn.microsoft.com/power-automate/desktop-flows/create-azurekeyvault-credential

Why this matters in ALM:

• It standardizes how machine/runtime credentials are created instead of relying on ad hoc local setup.
• It reduces deployment drift between Dev, Test, and Prod machines.
• It complements this pattern by keeping secret retrieval centralized while desktop credentials remain governed and repeatable.

Add the desktop flow action in your cloud flow and map sensitive input variables from secure outputs.

Validate input variable mapping so cloud-to-desktop secret handoff works consistently.

Step 7: Package for ALM with managed solutions

Use this deployment model:

1. Build in Dev using an unmanaged solution.
2. Export managed solution for Test/Prod.
3. Import managed solution into target environment.
4. During import, remap connection references to target environment connections.
5. Set environment variable values (KV_VaultName, secret names) for the target environment.

What changes per environment:

• Connection bindings
• Environment variable values
• Key Vault secret values in Azure

What should not change per environment:

• Flow logic
• Secret naming convention
• Input/output contract between cloud and desktop flows

Step 8: Validate deployment and runtime behavior

After each import:

1. Run a controlled test flow execution.
2. Verify secrets are resolved from the target environment vault.
3. Confirm run history does not expose secret values.
4. Confirm desktop flow executes successfully using injected runtime inputs.
5. Validate rollback plan (previous solution version and prior secret version if needed).

Run history validation confirms the flow works end-to-end after deployment and remapping.

Step 9: Operate with rotation and governance in mind

Adopt an operating model, not just a setup:

• Rotate secrets on a defined schedule.
• Keep secret names stable while rotating values/versions.
• Monitor failed runs for auth-related regressions after rotation.
• Document ownership: who rotates secrets, who updates connection bindings, who approves production deployments.

This is where ALM and security meet: secure changes with predictable releases.

Common mistakes to avoid

• Hardcoding credentials in cloud or desktop flows
• Using one Key Vault for all environments
• Not using connection references inside solutions
• Skipping secure inputs/outputs on sensitive actions
• Exporting/importing without a checklist for environment variable and connection remapping

How this should work in enterprise ALM solutions

A mature pattern looks like this:

• Dev: Makers build with environment variables and connection references, never raw credentials.
• Test: Managed solution import validates that security mapping and secret retrieval work before production.
• Prod: Deploy approvals include both solution artifacts and secret governance checks.
• Operations: Secret rotation is coordinated with release windows and monitored through run telemetry.

When this is in place, your flows become portable, auditable, and resilient. You reduce credential sprawl, cut deployment risk, and avoid rework every time environments or owners change.

That is exactly why integrating Azure Key Vault with cloud and desktop flows is not just a security best practice. It is an ALM best-practice.

Visual concept: modular AI architecture and orchestration

When you start building agents, putting everything in one agent feels natural. A few tools, a couple of knowledge sources, some instructions — it works fine. But as the agent grows to handle more scenarios, things start to degrade: the orchestrator struggles to pick the right tool, responses become less precise, and the instructions turn into a wall of text that’s hard to maintain.

Child agents fix this by letting you decompose your agent into smaller, purpose-built units.

What child agents actually give you

A child agent is a lightweight agent that lives inside your main agent. It has its own:

• Instructions — focused on a single task or domain
• Tools — only the tools relevant to that task
• Knowledge sources — scoped to what the child agent needs to answer
• Inputs and outputs — structured data exchange with the parent agent

When the parent agent receives a user query, the orchestrator decides which child agent (or tool, or topic) should handle it — based on the child agent’s name and description. The child agent runs with its own orchestration, uses its own tools and knowledge, and returns results back to the parent.

Why this matters more than you think

Tool limits stop being a problem

Copilot Studio agents have limits on how many tools they can effectively use. When your agent has 30+ tools all competing for the orchestrator’s attention, accuracy drops. Child agents have their own separate tool limits, so you can logically group tools across multiple child agents without hitting the ceiling on the parent.

The orchestrator gets smarter, not dumber

With fewer choices at each level, the orchestrator makes better decisions. Instead of choosing between 40 tools, the parent agent chooses between 5 child agents — and each child agent chooses between its own small set of tools. Two precise decisions beat one confused one.

Instructions stay manageable

Instead of one massive instruction block that tries to cover every scenario, each child agent gets focused instructions for its specific domain. An “IT Support” child agent has instructions about ticket creation and status checks. An “HR FAQ” child agent has instructions about leave policies and benefits. Neither clutters the other.

Testing becomes targeted

When something breaks, you know exactly where to look. Test each child agent in isolation with queries specific to its domain. If the “Order Lookup” child agent returns wrong results, you fix it there — without touching the rest of the agent.

A practical pattern

For a customer service agent, instead of building one agent with every tool and knowledge source:

1. Parent agent — minimal instructions, handles greetings and routing
2. Order Management child agent — tools for order lookup, tracking, returns
3. Billing child agent — tools for invoice retrieval, payment status, refund requests
4. Product Support child agent — knowledge sources from product documentation, FAQ articles

Each child agent is focused, testable, and maintainable independently. The parent agent’s job is simply to understand intent and delegate.

Child agents vs. connected agents

Child agents live inside your main agent — same solution, same deployment, same environment. They’re ideal when one team manages the whole agent and you don’t need independent ALM.

Connected agents are separate, independent agents that your main agent calls externally. Use those when different teams own different agents, or when you need independent publishing, authentication, or model configuration.

You can mix both in the same solution — use child agents for tightly coupled functionality and connected agents for independently managed capabilities.

What to watch for

• Name and description matter — the orchestrator routes based on these. A child agent called “Helper” with the description “Helps with things” will get misrouted constantly. Be specific.
• Latency adds up — each child agent adds an orchestration hop. Don’t create child agents for trivial single-tool operations where the parent could handle it directly.
• Performance degrades around 30-40 choices — if your parent agent plus all its child agents, topics, and tools exceeds this threshold, you may need to split into connected agents instead.

Child agents are the difference between an agent that works at demo scale and one that works at production scale. Start using them early — restructuring a monolithic agent later is always harder than designing modular from the start.

Normally, when you set up pipelines in Power Platform, you need to manually associate each development environment with a pipeline. That’s manageable with a few environments, but it doesn’t scale when you have dozens or hundreds of maker environments — especially if they’re being created dynamically through environment routing.

The Default deployment pipeline rule solves this. You configure it once on an environment group, point it to a pipeline, publish the rule, and from that point on, every environment that joins the group is automatically registered as a development environment in that pipeline. No manual linking. No admin intervention per environment.

How it works

1. Create an environment group in Power Platform admin center (or use an existing one).
2. Go to the Rules tab for that group.
3. Configure the Default deployment pipeline rule — select the pipeline you want environments in this group to use.
4. Publish the rules.

From now on, any Managed Environment added to this group — whether manually or through environment routing — is automatically linked to the specified pipeline as a development environment. Makers in those environments see the pipeline immediately and can start deploying solutions through it.

Why this matters

Without this rule, scaling pipelines means one of two things:

• Manual work: An admin links each new environment to a pipeline in the Deployment Pipeline Configuration app. This is fine for a handful of environments but becomes a bottleneck at scale.
• Personal pipelines: Makers create their own pipelines via the platform host. This works but gives less centralized visibility and control — personal pipelines can’t be shared or extended.

The Default deployment pipeline rule gives you the best of both worlds: centralized governance with zero per-environment effort. The admin defines the pipeline once, and the environment group enforces it automatically across every member environment.

Combine with environment routing for full automation

This rule becomes especially powerful when paired with environment routing:

1. Enable environment routing — new makers automatically get their own developer environment.
2. Point environment routing to an environment group — newly created environments land in the group and inherit its rules.
3. Configure the Default deployment pipeline rule on that group — every new environment is immediately linked to the pipeline.

The result: a maker opens Power Apps or Power Automate for the first time, gets their own developer environment, and already has a governed pipeline ready to deploy their solutions to QA or production. No tickets, no waiting for an admin to configure anything.

Why this is critical for Copilot Studio champions

This feature becomes even more important in organizations running Copilot Studio champions programs. In these scenarios, you typically have multiple business users across departments building agents in their own environments — and the number of environments grows fast as champions are onboarded.

Without the Default deployment pipeline rule, every time a new champion gets an environment, an admin has to manually link it to a pipeline before that champion can deploy their agent to a shared or production environment. That creates a bottleneck that slows down the very people you’re trying to empower.

With this rule configured on the champions’ environment group, each new champion environment is immediately pipeline-ready. The champion can build an agent in Copilot Studio, and when it’s ready, deploy it through the governed pipeline to a shared environment — without filing a ticket or waiting for IT. The admin still controls where solutions land (the target environments), but the champion gets a self-service path from day one.

This is especially valuable because Copilot Studio agents often iterate quickly. Champions need to test, refine, and redeploy frequently. If the pipeline isn’t there from the start, they’ll either skip ALM entirely (exporting and importing solutions manually) or wait on admin turnaround — both of which defeat the purpose of a champions program.

What to keep in mind

• The rule is currently in preview.
• It links environments as development environments in the pipeline — the target environments (QA, production) still need to be configured in the pipeline itself.
• Only Managed Environments can be members of environment groups, so this rule naturally enforces that requirement.
• If an environment is removed from the group, it retains its last configuration but becomes unlocked for local admin changes.

This is one of those features that quietly removes a scaling bottleneck. If you’re using pipelines and environment groups, configure this rule — it turns pipeline enrollment from a manual admin task into something that just happens.