# What Is a Copilot Agent Registry? An Agent of Agents Grounded in SharePoint

> A Copilot agent registry is one agent grounded in a SharePoint library that documents every agent you have, so people ask it which agent to use and get a link.

- URL: https://www.danielanderson.io/articles/copilot-agent-registry/
- Author: Daniel Anderson, Microsoft MVP (https://www.danielanderson.io/)
- Published: 2026-01-15
- Updated: 2026-10-25
- Video: https://www.youtube.com/watch?v=9wSjfBWuPQ4

## Key takeaways

- A Copilot agent registry is one agent grounded in a SharePoint library that holds a structured document for every agent in the organisation, so people can ask it what agents exist and which to use.
- Each agent's document follows the same template: name, description, primary use cases, who it's recommended for, example questions, data sources, owner, access link, status and last reviewed date.
- In my demo the registry agent grouped the agents by primary function and gave example prompts for the HR policy assistant, organised by topic.
- Agent Builder instructions are capped at 8,000 characters, so I used Claude to rewrite a longer draft to just under the limit.
- Microsoft's Agent 365 registry is an admin inventory in the Microsoft 365 admin center. An agent registry built this way is for the people choosing which agent to use.

A Copilot agent registry is one agent, grounded in a SharePoint library that documents every other agent your organisation has, that people can ask "what agents do we have?" or "which one helps with this?" and get an answer with a link. I call it the agent of agents.

People are building agents faster than anyone can find them, and most of the organisation doesn't know half of them exist. The usual fix is a SharePoint page or a spreadsheet listing every agent, which only works if people know it's there and go looking. A registry agent sits in Copilot, where they're already asking questions, and answers the ones they actually have: what agents do we have, which one is good for this job, and what data can it see.

## What goes in each agent's document?

The registry is only as good as the library behind it, and the library works because every document has the same structure. Each agent gets one document, created when the agent is, with these fields:

| Field | What it tells the registry agent |
| --- | --- |
| Agent name | What to call it in an answer |
| Description | What it does, in a sentence or two |
| Primary use cases | Which questions it should be recommended for |
| Recommended for | Which roles or teams it suits |
| Example questions | Prompts to hand someone so they get value on the first try |
| Data sources | What the agent is grounded in, so people know what it can and can't see |
| Owner or team | Who to contact when it's wrong |
| Access link | Where to open it |
| Status | Whether it's live, in testing or on its way out |
| Last reviewed | How current the entry is |

For the video I had Claude Code generate the documents for a set of example agents, and the access links are placeholders, so the answers below show the structure working over example agents.

## How does the registry agent work?

It's a normal Copilot agent with two pieces: instructions that tell it to act as a guide to the organisation's agents, and the registry library as its knowledge. I wrote my instructions in markdown with sections for purpose ("You are the Agent Registry Copilot, a master agent designed to help users discover and navigate the organisation's catalogue of specialised Copilot agents"), core responsibilities, the knowledge base, interaction guidelines and a response structure.

I built it from **Create agent** in Copilot, in the builder that was called Copilot Studio Lite when I recorded and is now Agent Builder. Instructions there are capped at 8,000 characters, and my draft was well over. I dictated the problem to Claude and pasted the instructions in. Its first rewrite came back at about 2,100 characters, which threw away detail I had room for, so I asked it to use as much of the 8,000 as it could without going over. The second version landed just under the limit and pasted into the agent with characters to spare. When you ask an AI to shorten instructions, give it the limit as a target as well as a ceiling.

For knowledge I selected the agent documents in the library. I left out a working folder in the same library, and in a real deployment I'd ground it on the whole library so new documents are picked up without editing the agent.

## What does it answer?

Asked "Can you tell me what agents we have?", the agent listed every agent in the library grouped by primary function, with headings such as business operations, customer-facing agents, and legal and compliance. Asked to tell me more about the HR policy assistant and give some example prompts, it gave a breakdown of what the assistant does and who should use it, then example prompts organised by topic, starting with leave and time off and benefits. I hadn't asked for the grouping in either question.

## Agent registry vs Microsoft's Agent 365 registry vs the Agent Store

Microsoft uses the word registry too, for something else.

| | Agent registry (this pattern) | Agent 365 agent registry | Agent Store |
| --- | --- | --- | --- |
| Who it's for | Everyone choosing an agent | Admins | Everyone |
| Where it lives | A Copilot agent over a SharePoint library | Microsoft 365 admin center, under Agent 365 | Inside Microsoft 365 Copilot and Teams |
| What it holds | Your own write-up of each agent: use cases, example prompts, owner, status | An inventory of agents with publisher, deployment status, permissions and governance policies | Agent listings with descriptions, from Microsoft, partners and your organisation |
| Main job | Answering "which agent should I use for this?" | Visibility, monitoring and governance actions such as block or delete | Browsing and installing agents |

The admin registry is built for IT to see what exists and govern it, and the Agent Store is a catalogue to browse and install from. Neither will answer, in your own words, which agent fits a particular job, with your example prompts and the name of the person who looks after it.

## The registry is a content job before it's an agent

Building the agent took me one short video, and keeping it accurate is an information management job that never finishes. Every new agent needs its document in the library, and every retired agent needs its status changed. I'd tie the document to the publishing step itself, so an agent isn't announced until its registry entry exists and has an owner, and I'd use the last reviewed date to chase owners whose entries go stale and the status field to mark anything being retired, so the registry stops recommending it.

I'd also keep the library readable by everyone the registry agent is shared with. The agent only answers from content the person asking can open, so if the registry library is locked to IT, everyone else gets an empty answer. And an access link in a document doesn't give anyone access to the agent behind it. If the HR assistant is only shared with HR, the registry should say so in the recommended-for field, so nobody's told to use an agent they can't open.

Plan for size as well. Agent Builder caps SharePoint knowledge at 100 files per agent, so one document per agent tops out at about 100 agents. Past that, I'd move the registry to a single list with one row per agent. If you're still deciding whether some of those agents need to exist at all, [Copilot agent vs Copilot in Word](https://www.danielanderson.io/articles/copilot-agent-vs-copilot-in-word/) covers the questions I ask before building one. To build the individual agents from their own libraries, see [how to build a Copilot agent grounded in a SharePoint library](https://www.danielanderson.io/articles/build-copilot-agent-sharepoint/).

## Frequently asked questions

**Can I ground the registry agent in a Microsoft List instead of documents?**
Agent Builder supports one SharePoint list per agent, up to 20,000 rows and 50 MB of text, and the Attachments column isn't used. A list with a column per template field works, though I used documents in the demo, so test the answers before you switch.

**How quickly does the registry pick up a new agent's document?**
New files in a SharePoint knowledge source can show a **Preparing** status for up to several minutes in Agent Builder before the agent uses them. Renamed or deleted sources are picked up automatically, and there's a refresh button in the Knowledge section.

**Will the registry agent work if Restricted SharePoint Search is on?**
No. With Restricted SharePoint Search enabled, you can't use SharePoint as a knowledge source in Agent Builder, so the registry library can't be connected.