You already have one. On every site.
Most organisations spend months debating whether to build an internal knowledge bot. Meanwhile every SharePoint site in their tenant already has one, switched on, scoped to that site's content, answering strictly within whatever permissions the asker already has. Knowing the difference between that ready-made agent and a custom-built one is most of the skill here.
01 Two agents, one site
| Ready-made agent | Custom-built agent | |
|---|---|---|
| Where it comes from | Every SharePoint site ships with one | You create it, with site edit permissions |
| Scope | Automatically the content on that site | Sites, pages and files you choose — including other sites |
| Name | Named after the site, or “Copilot” if the site is in the Copilot in SharePoint public preview | Whatever you brand it |
| Editable | No | Yes — scope, identity, behaviour, custom prompts |
| Shareable | No | Yes — via the ellipsis, then Share, then Copy Link |
| Has an .agent file | No | Yes |
02 The permission model is the whole product
Microsoft's phrasing is precise and worth repeating: agents in SharePoint answer questions about content on any site or document library that the asker has permissions with. The agent doesn't widen access. It reads what the person asking could already have opened themselves — it just reads all of it, instantly.
That's genuinely reassuring and genuinely dangerous at the same time. It means a SharePoint agent will never leak a document someone couldn't already open. It also means that if your permissions are sloppy — the “everyone in the company” library that was supposed to be temporary in 2021 — the agent will find that content and surface it fluently, in seconds, to anyone who asks the right question. Oversharing that used to be theoretical becomes practical.
Before you promote SharePoint agents internally, run the permissions audit you have been postponing. See Copilot security hygiene — the failure mode isn't the agent, it's what the agent can reach.
03 What you need
04 Building one that earns its keep
A custom agent is worth building when the ready-made one has the wrong scope or the wrong manners. Three levers:
- Scope. Point it at multiple sites. Microsoft's own example is a sales manager combining their team site with the R&D site and a product site, so one agent can compare two product generations.
- Purpose and branding. Give it a name and a job so people know what it's for — “HR Policy Answers” gets used, “Site Assistant” doesn't.
- Customised prompts tailored to that scope, so the first thing a new user sees is a question worth asking.
The output goes well beyond retrieval. Microsoft's worked example asks a custom agent to write a competitive pitch script comparing two products, drawing on the R&D evidence for one of them — that's synthesis across sites, not a search box.
Open the SharePoint site your team complains about most. Ask its ready-made agent the question new starters always ask — the one that currently gets answered by someone senior in a DM. If the answer is good, you just found a custom agent worth building. If it's bad, you found a documentation problem the agent has helpfully surfaced.
05 Where this sits against the others
SharePoint agents are the right answer when the knowledge is in documents. When the knowledge is in conversation, that's Channel Agent. When the work is execution rather than recall, that's Planner Agent. And when you need process logic, connectors and approvals rather than grounded answers, you've crossed into Copilot Studio.