If you run a business, you have probably already seen the first version of this. Someone on the team uses ChatGPT to draft a customer email. Someone else builds a little helper in Teams that files IT tickets. A third person has a saved prompt for pulling last quarter's numbers. None of that was on the roadmap. All of it is now part of how work gets done.

Vendors call those tools agents: small AI programs that can look things up, write something, or take an action in a company system. One or two of them can be useful. A few dozen, built by different people, with no shared rules, is a different story. That pile-up is what people mean by agent sprawl. It is not a future problem. It is already happening inside large companies, and the pattern shows up in smaller ones too — just with fewer tools and less visibility.

what microsoft had to admit this week

On August 19, Microsoft described how it is using a product called Agent 365 to take inventory of its own internal agents. Not a handful. Hundreds of thousands, built in Copilot, SharePoint, Teams, and other tools. The company is looking for agents with no owner, agents nobody uses anymore, and agents that do the same job twice. One new agent, named Cowork, reached 58,000 active users in a matter of weeks. That is not a pilot. That is an internal product that launched itself.

Microsoft's first move is a directory: the agent's name, who owns it, where it lives, whether it is still in use. That is sensible. You cannot manage what you cannot see. The more useful finding is what their own team said once the directory existed. Garima Tiwari, who runs the internal trial, put it this way: she thought the hard part would be the technology. It turned out to be getting IT, security, identity, product, and the business teams to look at the same picture every week and actually decide something together.

A list of agents is a start. A weekly habit of deciding which ones employees should use — and which ones should be shut off — is the work. That second part is not an IT problem. It is a product problem. It is about whether the tools your people open every day make sense, have an owner, and fail in a way a human can recover from.

why a directory is not the same as a product

Think about the last internal tool your company rolled out that nobody liked and everyone used anyway. A clunky dashboard. An old SharePoint site. A form with twelve fields that only three people understand. Employee-facing AI is that category again, except this time the tools can appear without a launch. Someone builds an agent. A colleague copies it. Six months later you have three versions of the same idea, two of them broken, and no one named to fix them.

From the employee's point of view, the experience is confusing in a very ordinary way. There is no clear list of what any of them can actually do. Two of them answer the same question and disagree. The unofficial one is better, so people use it until it breaks — and then it stays broken, because it never had an owner. The official one is an empty text box that says "ask anything," then fails the first real request. People go back to a personal ChatGPT tab. IT writes another policy. The work does not get easier. It just gets harder to see.

A directory tells you what exists. It does not tell a person at the end of a long day which one to trust, what it is allowed to touch, or what to do when the answer is wrong. If the answer is a messy paragraph, that is annoying. If it updates a customer record or a payroll file, that is a business problem. UX is the work of designing how people actually use a thing. Here that means deciding what it is for, who it is for, and what happens when it cannot help.

An agent with no job, no owner, and no plan for when it is wrong is not a tool. It is leftover software.

three decisions to make before you buy another dashboard

You do not need a Microsoft-sized stack to act on this. You need three decisions, written down, for every agent employees are expected to use.

Write a job description, not a nickname. Who is this for? What task does it finish? Which systems is it allowed to open? What must it never do? If you cannot answer those four questions in a short paragraph, it is not ready to sit in front of staff. This is the same scoping you would do before you shipped a feature to customers. The only difference is the "users" are your own people.

Plan for "I don't know" and "I might be wrong." AI will be confidently incorrect sometimes. That is not a theory; it is how the tools behave. For internal use, the interface should say where the answer came from, how sure it is, who to ask instead, and how to undo a bad action. If nobody owns those four things, it will fail quietly. Quiet failures are how small mistakes become expensive ones.

Put the right one where the work already is. People will not open a wiki of AI tools. They will use whatever appears in the ticket, the chat channel, or the form they already live in. So the prompt should be specific: "This kind of request usually goes to the IT agent. Here is what it will do. Here is who to call if it stalls." Microsoft's useful lesson was not the software. It was the weekly meeting where the groups who care about risk and the groups who care about getting work done looked at the same facts. That meeting is the management system. The in-the-moment prompt is the interface.

you already have this product. you might as well run it

IT should keep counting agents, shutting down the unused ones, and watching permissions. Sprawl is real, and leftover access on a forgotten agent is a genuine risk. Counting is not the same as making the remaining ones usable. A complete list of confusing tools is still a list of confusing tools. The companies that get value here will keep fewer of them, give each one a job and an owner, and design the moment an employee actually has to rely on it.

If you are the owner, or you have a UX person on staff, start with one unofficial agent people already trust. Write its job description. Note where it sits in the real workflow — not the org chart, the actual clicks. Decide what happens when it is wrong. Then take that to whoever is building the company directory and treat it as the standard: we do not add an agent to the list until it has a job, an owner, and a failure plan. The count is their job. Whether people can use the thing is yours.