Agent 365 Is an Inventory Problem Wearing a Dashboard

Microsoft's Agent 365 (opens in a new tab) is a control plane for AI agents, and the framing is right. Agents need the same treatment as any other managed object in an estate: an owner, an identity, a scope, a lifecycle.

The part worth arguing about is not the dashboard. It is the registry underneath it.

Every governance capability in Agent 365 depends on one assumption: that the inventory is complete. If an agent is not in the registry, no policy applies to it, no access rule constrains it, and no report mentions it. That is not a feature gap. It is the whole risk.

What the product actually does

Agent 365 is a management layer for agents across Microsoft 365, Azure and partner clouds. Five capabilities carry the weight:

A registry that inventories agents, including ones with an Entra agent ID and ones published through the Teams store.
Access control that gives each agent a unique identity and limits it to the resources it needs, with policy templates for who may create and manage agents.
Visualization of the connections among agents, users and resources.
Interoperability across Microsoft platforms, open-source frameworks and partner clouds.
Security controls applied to agent activity.

Microsoft pairs it with Foundry Control Plane for development teams, which adds observability, behavioral guardrails and lifecycle management.

That is a coherent product. It also describes a governance model that only works inside its own boundary.

You cannot govern what you cannot enumerate

Ask a large organization how many AI agents run in its estate. The honest answer is a range, and the low end is wrong.

Agents are cheap to create. A business analyst can build one in an afternoon with a low-code tool and a document store. It authenticates with a credential someone issued for a different purpose, reads a folder nobody classified, and writes to a channel nobody monitors. It is not malicious. It is just unregistered.

The registry is Microsoft's answer, and it is the right answer. The question is completeness. A registry built from agents that register themselves has a selection bias: it holds the agents whose owners follow process. The agents that worry you are the ones whose owners did not know there was a process.

A governance control plane is only as good as the fraction of the estate it can see.

Three things make the fraction smaller than the sales deck implies. Agents built outside the Microsoft ecosystem. Agents built before the registry existed. And agents that were never agents in anyone's inventory, because the team calls it a script.

The federal version of the problem

For a federal program, the registry is necessary and insufficient.

An authorization package needs to show what the system does, under what configuration, with what data. An agent registry gives you the first part for agents it can see. It does not give you the control baseline, the boundary, or the evidence that a specific action was approved. Those come from your own record, and the control plane's console is not your record. It is a vendor's view of your estate, on a vendor's retention schedule, behind a vendor's export.

That distinction matters at the exact moment someone asks why an agent sent a document to an external address. The answer has to come from a log you control, in a format you can produce years later. I have made that argument in more detail in the case for an agent chain of custody.

There is a second federal issue, and it is procurement rather than technology. Government cloud services arrive on their own schedule, and a control plane is only useful in the environment where your data lives. Before you architect around any management layer, confirm which clouds and which impact levels it currently serves. That is a document check, not a roadmap conversation, and it should happen before the design review rather than after it.

What the control plane does not decide

Agent 365 will enforce a policy. It will not write one, and it will not tell you that the policy is wrong.

That sounds like a trivial distinction. It is the difference between a program that can pass an audit and one that has a very good console. The hard questions are still yours:

Which actions may an agent take without a person approving them?
What is the agent allowed to read, and who decided that classification?
When the agent is wrong, whose name goes on the finding?
How long do you keep the evidence, and can you read it without the vendor's tool?

A control plane gives you a place to answer those questions consistently. It does not answer them, and no product can. The organizations that get value from Agent 365 will be the ones that already had answers and needed a mechanism to enforce them at scale. The organizations that buy it expecting the tool to supply the governance will get an expensive inventory of a partial estate.

What to do this quarter

Three steps that cost nothing and make any control plane more useful when it arrives.

Count the agents you have. Not the ones in the vendor console. The ones with a credential and a data source. Start with the service accounts nobody can explain.
Write down the action classes. Read, draft, internal write, outbound send, spend, permission change. Decide which need a human gate. This is the policy the control plane will enforce, and it has to exist first.
Decide where the record lives. If the answer is "in the management console," you have not decided. Pick a store you control and a format you can read in five years.

Agent 365 is a serious product aimed at a real problem, and the registry is the right primitive. The mistake would be treating registration as compliance. Registration is the beginning of an inventory, and an inventory is only useful if it is true.