Copilot in SharePoint is built to get work done in your sites, lists and libraries. Zach Rosenfield, who has spent close to 20 years on Microsoft’s SharePoint and OneDrive product team and the last year focused on AI for content, describes it as “an agentic service built on top of your document repository”.
I asked Zach to talk it through because, in the client work I’m doing, Copilot in SharePoint is landing with people more than Copilot Chat, and most of them still don’t know what it can do. Everything attributed to Zach below is his view as he gave it in our conversation in August 2026.
Is Copilot in SharePoint an assistant or an agent?
Zach’s answer is an agent. He said the original framing came from coding agents, which sit on top of a code repository, and the team saw close parallels with a document repository. The internal shorthand he shared is that Copilot Chat is more of a talker, while “we like to think of ourselves more as a doer”.
He also called it “an untrained agent”, like a new employee on day one. It has access to the tools SharePoint has built up over 25 years, such as workflows, process automation and sending mail, and you give it the job, the knowledge and where your corporate information lives. His comparison was a handyman who turns up with every tool but doesn’t know yet whether today’s job is plumbing, electrical or painting. He said that unlike a Copilot Studio agent, it isn’t grounded in a fixed set of information.
The thing I’d add is context awareness. Copilot in SharePoint knows which site, list, library or page you’re on, so you don’t have to explain where you are before asking it to do something. My walkthrough of every new Copilot in SharePoint feature shows what that looks like across files, folders and approvals.
When should you use Copilot in SharePoint instead of Copilot Cowork?
I’ve seen tasks people were running in Copilot Cowork start moving into Copilot in SharePoint, so I asked Zach about the overlap, and he pointed to a technical difference. Copilot in SharePoint runs in your browser and uses the browser cache, which he said is part of why some commands are so efficient. Cowork is a hosted instance in the cloud, so a job he started from his phone keeps running after he closes his laptop.
The trade-off, in Zach’s words, is that Copilot in SharePoint can’t do browser work. It stays inside the repository. He said Cowork is “far, far superior” for some jobs, but for working through a library, his example being 10,000 contracts, having the SharePoint agent drive is very efficient. He’s happy for people to use Cowork to drive SharePoint skills too. If you’re weighing up Cowork, which models Copilot Cowork uses covers how it works.
Where should skills live?
Zach’s position is that “the business logic should live where the documents are”. Rather than every person making sure their own Cowork setup has the right skills to generate an NDA or file a service ticket, the skill sits on the site with the content, managed by whoever runs that process. For me, the big unlock is scale: a site skill written once is there for everyone on the team who uses that site.
Zach explains skills two ways, depending on where someone is with AI. If you’re starting out, he likes the standard operating procedure comparison: write down the rules the way you would for a new employee. Then, he said, go on a journey to “delete as much from your skill as you possibly can”. His advanced view is that a skill should only teach the model what it can’t know about your business, like the order your company approves RFPs in. He pointed to Anthropic’s design skill as an example that tells the model how to approach a problem without ever telling it which font to use.
Zach also said Copilot in SharePoint follows the skill format as Anthropic originally defined it, so a skill can reference other files. It won’t run code you put in a skill, which he put down to SharePoint taking the most secure stance it can, though the model can write code on your behalf while doing the work. He prefers skills to long prompts saved in files for shared use because they’re version tracked, logged and visible when they load, and you can control who edits the skills library separately from other folders. I compare skills with agents in Claude skills vs Copilot agents.
What goes in a SharePoint.md file?
Zach called the SharePoint.md file “really the site memory”. Skills only load when a prompt matches them, while SharePoint.md goes into the context of every conversation on the site. His test is whether every response needs to know it. His examples were always using US dollars, Microsoft’s fiscal year ending in June, where his team saves reports and his team’s rule against creating new folders.
Anything that only applies to one kind of task, such as branding rules for generated HTML, he’d keep in a skill so SharePoint.md doesn’t bloat. He also suggested a skill that summarises a conversation and saves it to group memory. I use SharePoint.md for a save rule on generated content, explained in building live dashboards from a Microsoft List.
Does AI make SharePoint metadata less important?
I get this question all the time, so I put it to Zach. He said Microsoft’s studies keep showing that time spent on information architecture improves the quality of answers, and that brute-forcing every request costs far more tokens. His example: if you want to know which of 10,000 contracts have a force majeure clause, search only finds specific wording, so Copilot would have to read every document to be sure. If that clause is already stored as metadata, he said, a filter can answer it in a few hundred AI credits.
He added that processing documents ahead of time shifts the load away from the moment you need the answer, which is part of why Microsoft has made autofill columns easier to set up. His summary was that “getting AI to do the metadata for you is definitely the secret”. I walk through setting those up in SharePoint autofill columns.
What I’m taking from the conversation
- Design the library before you write the skill. Zach’s contract example is the clearest case I’ve heard for metadata in an AI context. Fill a column once, with autofill doing the work, and Copilot filters on it instead of rereading the same documents every time someone asks. I’d start with the questions people actually ask of a library and build the columns from those. The free Copilot-ready library checklist is how I’d begin.
- Put each rule in one place. Site-wide facts go in SharePoint.md, task rules go in a skill, and the documents carry the metadata. If the same rule sits in a skill and in SharePoint.md, sooner or later someone updates one and not the other, and Copilot gets two answers.
- Treat skills as part of the process, owned by the process owner. If the business logic lives with the documents, whoever owns the process should own the skill and decide who can edit it. The default skill permissions, and how I lock them down, are in every new Copilot in SharePoint feature tested.
- Start skills long and trim them. A step-by-step SOP is the easiest way in for a team writing its first skill. Once it works, go back after each model update and cut whatever the model now does on its own.
For the foundations underneath all of this, see why your SharePoint needs an information architecture before AI.
Frequently asked questions
Who is Zach Rosenfield? He helped build SharePoint Online and is still on Microsoft’s SharePoint and OneDrive product team. He shares tips on YouTube and LinkedIn as zrosenfield and tries to post the day a feature reaches production.
Can SharePoint HTML pages pull live data from other files? Zach explained that HTML pages hosted in SharePoint can’t make outbound calls, but SharePoint can inject data from linked files on the server. At the time we spoke, that worked for Excel files, CSV files and lists, with more planned.
Where does Zach see Copilot in SharePoint heading? Towards agents you give a goal and success criteria rather than a fixed workflow, with agentic and group memory so a team can run a process together. He sees the biggest current use in business processes for teams too small to justify buying a dedicated system, naming finance, sales and RFPs, marketing and legal.
Was Copilot in SharePoint in preview when this was recorded? Yes. In August 2026 Zach described it as still technically in preview, with general availability the team’s next milestone. General availability began rolling out from 30 September 2026, with some capabilities moving to usage-based billing through Copilot Credits.