The next agent problem is not intelligence. It is inventory.
That sounds almost too plain for a market that wants to talk about autonomy, reasoning, tool use, and artificial general intelligence. But production work has a way of humiliating abstractions. Before an organization can govern an agent, secure it, measure it, improve it, or trust it, the organization has to know the agent exists.
That is the signal in Microsoft's latest agent-security push. Help Net Security reported on June 3 that Agent 365 is gaining an Agent Registry to help organizations discover and manage AI agents operating inside their environments. The same coverage points to visibility into agent activity, relationships between agents and other systems, Purview controls for agent data access, runtime data loss prevention for prompts, and isolated execution environments.
The industry is quietly admitting something operators already feel: once agents leave the demo, they become a management problem.
Invisible workers are not harmless
Most companies will not get agent sprawl from one grand enterprise rollout. They will get it from helpful little exceptions.
A sales manager connects a prospecting assistant to the CRM. A developer runs a coding agent with access to repositories and issue trackers. An operations lead builds a workflow that lets a model summarize tickets and draft responses. A founder gives an agent access to Google Drive so it can prepare weekly briefs. A finance person tries a tool that reads invoices and suggests follow-ups. None of these feels like a formal workforce decision at the moment it happens.
That is exactly why the roster matters.
An agent does not have to be malicious to become dangerous. It only has to be unlisted, unowned, over-permissioned, or forgotten. The first failure may not look like a breach. It may look like duplicate CRM records, a stale SOP being used for live work, a customer email drafted from the wrong policy, an approval request stuck in Slack, or a tool call nobody can reconstruct two weeks later.
The agent can be useful and unmanaged at the same time. That combination is the real risk. Useless agents disappear. Useful unmanaged agents get woven into work before anyone has placed a boundary around them.
Registry is not bureaucracy
A registry can sound like enterprise paperwork. In practice, it is closer to an org chart for delegated work.
The question is not simply, “Which agents exist?” The useful roster answers a tighter set of operating questions. What is this agent's job? Who owns it? What product does it produce? Which systems can it read? Which systems can it change? Which tools can it call? What evidence does it leave behind? What requires approval? Where does the work go when the normal route breaks?
Those answers turn an agent from software into a managed worker.
This is the same move Stephen keeps making with clients: define the product of the work before worshipping the tool. A human role without a product becomes vibes and meetings. An agent role without a product becomes prompt drift and mystery output. The roster forces the role into shape. It gives the organization a noun it can inspect: this agent produces qualified lead packets, not “sales help”; this agent drafts invoice exception reports, not “finance automation”; this agent prepares sourced research briefs, not “AI assistant work.”
Once the product is named, authority can be sized to the product. The lead-packet agent may read CRM records but not update deal stages. The invoice agent may flag exceptions but not send payment instructions. The research agent may search and summarize but not email external partners. The support agent may draft responses but only publish after review for certain categories. The point is not to make every agent timid. The point is to make authority visible enough that expansion is a decision, not drift.
MCP made the boundary concrete
The Model Context Protocol accelerated a useful realization: tool access is not a developer detail. It is an operating boundary.
WorkOS put the issue plainly in a June 2 article on MCP security risks: an MCP server exposes tools that agents can invoke, and it sits between the model and production systems. That sentence is doing a lot of work. The model is no longer just answering a question. It is standing near the business machinery. When the exposed tools include records, messages, files, code, payments, or customer data, the agent's tool list becomes part of the company's control surface.
That control surface is easy to underestimate because it does not look dramatic in the interface. A chat box feels harmless. A tool call is not harmless. It is an action path.
WorkOS names five risks around MCP servers: unauthenticated tool access, prompt injection via tool results, excessive agent permissions, persistent token exposure, and missing audit trails. The roster does not solve all of those by itself, but it makes them governable. You cannot scope permissions for an agent nobody has named. You cannot audit tool calls for a worker nobody owns. You cannot revoke access cleanly when nobody knows which workflow depends on the credential.
This is why “agent registry” and “MCP security” belong in the same conversation. Registry is the management layer above the tool boundary. MCP gives agents reach. The roster gives that reach a name, owner, and limit.
Approval is a route, not a vibe
Public operator language is getting sharper here too. Indexed Reddit snippets from AI-agent communities keep circling the same seam: approval is not hard because a model cannot ask permission. Approval is hard because real humans are messy. People are out of office. Requests get stuck in Slack or email. Context is missing. Last-minute escalations appear. Nobody knows whether silence means rejection, delay, or “I never saw it.”
That is why “human in the loop” is now too blunt a phrase.
A human can be nominally in the loop and still be operationally useless. If the approval request appears in the wrong channel, without the evidence needed to decide, with no timeout, no backup approver, no queue owner, and no log, the human is not a control point. The human is a bottleneck the agent occasionally throws work at.
The roster should therefore include the approval route. Not the sentiment that humans matter. The route.
Which actions require approval? Who approves them? What must the agent attach? Where does the request live? What happens after two hours? What happens if the approver rejects it? What changes if the same rejection happens five times? Which approvals are pre-action gates, which are post-action samples, and which are exception-only escalations?
Those questions are not legal padding. They are the difference between controlled delegation and hidden manual cleanup.
The small-business version is simpler
A small business does not need Microsoft's full stack to learn the lesson. It needs the right-sized version of the same shape.
Start with a simple table. Agent name. Owner. Work product. Trigger. Systems read. Systems changed. External actions allowed. Approval required. Evidence logged. Exception owner. Last reviewed.
That table will feel boring for about ten minutes. Then it will expose the business.
One agent will have no owner. Another will have access to a system it does not need. A third will be producing a useful output, but nobody will know where corrections are stored. A fourth will depend on a human approval that currently lives in a DM. A fifth will have quietly become business-critical without anyone deciding what happens if it fails.
That is not a documentation problem. It is an operating diagnosis.
Once the roster exists, the next move is not to write a giant AI policy. The next move is to fix the most obvious control defects. Narrow a tool grant. Add a reviewer. Move approval into a ticket. Add a required evidence packet. Create an exception queue. Remove an external send permission. Assign an owner. Decide that one agent is a toy and another is now part of the operating system.
The roster turns vague unease into specific work.
What this changes about selling AI work
This matters for AI transformation because the buyer's worry has matured.
Two years ago, the question was whether AI could do anything useful. Now the buyer has seen enough demos to believe the capability exists. Their worry is whether it can survive inside their business without creating a mess they cannot see until too late.
That means the better offer is not “we will bring you agents.” It is “we will make agent work legible, bounded, and useful.”
The first deliverable should often be an Agent Roster and Authority Map. It is small enough to start, concrete enough to sell, and useful even if the company decides not to expand automation yet. It also creates the right conversation. Instead of debating abstract AI risk, the client is looking at named workers, real tools, real approval routes, and real ownership gaps.
That is where Stephen's operating frame is strongest. AI agents that actually work are not just clever prompts connected to tools. They are delegated work loops with products, routes, control points, and owners. The roster is the first place those pieces become visible in one view.
The bottom line
Agent autonomy gets attention. Agent legibility creates trust.
A company can only delegate safely to work it can name. The roster is not the final control layer, but it is the first one that makes the rest possible. Without it, governance becomes theater, security becomes guesswork, and improvement becomes archaeology. With it, the organization can see what it has actually built.
That is the management move hiding inside the technical shift. Before the next agent gets more authority, put it on the roster.
Stephen Nickerson.
Built for operators who need AI agents they can test, trust, and improve.