The Week in Agents, 15 to 21 June 2026

You are not short on agents anymore. You are short on lifecycle control. This week the signal I care about is not another agent launch, but the admin muscle around ownerless agents, node-level evaluation, environment rules, and Dataverse cleanup.

TL;DR: The fresh thread is lifecycle governance: agent registry and ownerless-agent controls in Microsoft 365 admin center, node-level evaluations coming to Copilot Studio workflows (watching), Environment Group Rules Gallery in Power Platform admin center (watching), Dataverse bulk deletion becoming ALM-aware (watching), and Copilot Cowork showing how MCP tools and Agent Skills can be packaged together. Catch up on last week’s edition (8 to 14 June 2026) if you missed it. Last updated June 2026.

1. The problem is no longer agent creation. It is agent ownership.

Rafsan Huseynov’s question in my feed was the sharpest one this week: what happens to an AI agent when the person responsible for it leaves the company or moves to a new role? Most organizations do not yet have a satisfying answer. The agent keeps running, the access remains, and nobody is clearly accountable.

`r`n

The Microsoft 365 admin center docs now make that problem explicit. The Agent Registry gives admins a centralized view of agents in the tenant and includes summary counts for agents without owners and unmanaged agents. That is the phrase to underline. Ownerless agents are no longer a vague governance concern. They are a thing Microsoft expects admins to find, filter, export, and act on.

The broader Agent 365 overview says the quiet part clearly: organizations need to identify and retire low-value or ownerless agents before they create risk or cost. It also points to rules-based agent management for automatically enforcing lifecycle policies, including flagging ownerless agents or blocking risky agents. For Power Platform and Microsoft 365 admins, that means agent governance needs the same hygiene loop as apps, flows, and service principals: owner review, access review, lifecycle state, and retirement.

Read more: Manage agent registry in Microsoft 365 admin center and Agent management in Microsoft 365 admin center.

2. Evaluations are moving from agent-level confidence to workflow-node confidence

Carsten Groth flagged a June 30 item I am tracking: agent-node-level evaluations in Copilot Studio workflows. I could not find a Microsoft Learn page or formal release note for that exact feature yet, so I am treating the date as a watch item, not verified news. But the direction matches what Microsoft is already saying publicly about evaluations.

Copilot Studio Evaluations are the test harness for agent quality. Instead of testing an agent by chatting with it a few times and deciding it “feels right,” you define test cases, expected behaviors, and success criteria, then run those tests repeatedly as the agent changes. Evaluations help you catch regressions in instructions, grounding, tool use, and response quality before users find them. For enterprise agents, this is the difference between a demo that works once and an agent you can safely improve over time.

The Copilot Studio evaluation team published the more important principle this month: the quality question is not only “did the agent get better?” It is also “can we trust the evaluation signal?” That matters more once agents are embedded inside deterministic workflows. A workflow can be mostly predictable, but one agent node can still introduce judgment, tool use, and regression risk. Evaluating the whole agent is useful. Evaluating the exact node that made the decision is much more operational.

If this lands the way Carsten describes, it changes the testing model for Power Platform developers. You will not just run an end-to-end workflow and hope the AI step behaved. You will evaluate the specific agent node, track whether quality regressed after a prompt or skill change, and catch failures before the workflow is in production. That is the right level of granularity for enterprise agents.

Read more: Who evaluates the evaluators? The data science behind agent evals.

3. Power Platform admin center is becoming the policy workbench

Carsten also flagged the Environment Group Rules Gallery, reportedly rolling out to public preview on June 22. I could not find a Microsoft Learn page yet, so this is another watch item. Still, it fits the pattern from Advanced Connector Policies: Microsoft is pushing more governance into environment groups so admins can apply policy once and let it follow the environment.

The reason I care: Power Platform governance is moving from “hunt for the one setting in PPAC” to a gallery of reusable rules. If environment groups become the packaging unit for policies, admins get a more scalable model for developer environments, maker sandboxes, production apps, and agent workspaces. That is especially important now that agents, MCP servers, model providers, and credentials all need policy, not just connectors.

What I would do now: list the rules you already apply manually to every environment. DLP or ACP policy, maker limits, sharing boundaries, managed environment settings, region rules, connector exceptions. That list becomes your first candidate rule gallery when the feature appears in your tenant.

4. Dataverse cleanup is becoming ALM, not aftercare

`r`n

The Dataverse item I would not ignore is bulk deletion becoming solution-aware, with run-time diagnostics and a permanent-delete option, as flagged by Carsten Groth. I could not locate the primary Microsoft documentation yet, so I am treating it as a strong Dataverse watch item. But the direction is right: data hygiene needs to become part of the lifecycle, not a manual cleanup ritual after go-live.

If bulk deletion jobs can move with solutions, developers can package cleanup behavior with the tables, flows, and apps that need it. That matters for test data, audit retention, import staging tables, demo data, and integration fallout. It also matters for compliance. A permanent-delete option makes this a governance feature, not just a convenience button. The question for admins is no longer “who will clean this up later?” It is “which cleanup policies ship with the solution?”

I will follow up when the primary source lands. For now, if you own Dataverse environments, start identifying the recurring cleanup jobs that should be lifecycle-managed rather than recreated by hand.

5. Copilot Cowork points to packaged tools plus skills

Graham Hosking posted something I want to keep watching: Copilot Cowork can bundle custom MCP tools with correlated Agent Skills in a single manifest. I could not verify the exact manifest format from a Microsoft primary source yet, so I am not treating this as a release note. But the design pattern is important.

The pattern is: tool access plus instructions travel together. A custom MCP tool connects to a system. The correlated Agent Skill tells the agent how to use that tool in a business process. That is much better than giving an agent a tool and hoping its prompt has enough context to use it safely. For developers, the package becomes a unit of reuse. For admins, the package becomes a unit of review.

This connects directly to the Dataverse Business Skills story from last week. Business process knowledge is becoming portable, governable, and callable across agent surfaces. The next governance question is not “does this agent have a tool?” It is “what process did we package with the tool, who approved it, and where else is it being reused?”

What every Power Platform developer and admin should action this week

1. Admins: export the Agent Registry and look for ownerless agents. Treat ownerless agents like ownerless apps or service principals: assign an owner, restrict access, or retire them.
2. Developers: define evaluation at the agent-node level. For any workflow with an AI decision step, write the evaluation question for that exact node before you change the prompt or skill.
3. Admins: write your environment group rule inventory. Before the Rules Gallery appears, list the settings you manually apply to every dev, test, and prod environment.
4. Developers: package cleanup with your Dataverse solution. Identify bulk deletion jobs that should move with the solution instead of being recreated manually after deployment.
5. Developers and admins: review MCP tools as tool-plus-process packages. The tool is only half the risk. The skill or instruction paired with it is the other half.