Daniel Anderson | Microsoft MVP

Ethan Mollick has a name for people who've worked out how to use AI at work and kept it to themselves. He calls them secret cyborgs. There are a lot of them. Workday surveyed nearly 6,000 workers in September, and 41% of the people using AI at work said they hide it. Leaders were 2.5x more likely than their staff to say they understand agents. So the agent conversation is happening at the top, while plenty of people further down aren't sure they're allowed to use Copilot in the file they've got open. That's why I don't start with an agent. A lot of the "build me an agent" requests I get are a Copilot in Word job. Point it at the workbook and it fills in the report while you watch. Nothing to build, nothing to look after. Before anyone builds one, I'd ask four questions: 1. Is the work in a file you already have open? 2. Is the data in a file you can point Copilot at? 3. Does it need to run without you, or for lots of people? 4. Will it happen often enough to look after? The video runs 12 requests through those questions. Watch where they land.

a Copilot skill can carry the code for part of the job. if you're calculating a total, checking dates or applying the same rule across a file, you can put that work in a Python script. SKILL.md explains the method and when to use it. the agent can then explain the results in the context of your request. you still need to test the script. packaging code in a skill doesn't make it correct. it gives you a repeatable piece of the process that you can check against a known result.

Copilot Code built me a CRM on SharePoint for under $55 in credits. Before it built a single screen, it showed me the plan: 13 lists, 3 libraries and what to build first. That plan is the cheapest place to change your mind. Read it like a solution design before you hit build.

Ask Copilot to check every file in a SharePoint library against a rule, twice, and you'll get two slightly different answers. So split the job. A script inside the skill does the counting, the same way every run. Copilot reads the results and decides what to fix first. Let the model judge. Let code count.

Copilot in SharePoint used the Apify plugin to turn my account list into the starting point for research. it brought in information about the company, worked through it alongside the service offerings and stakeholder information already in SharePoint, then produced an intelligence brief and updated the list. that gives you something useful before the call: possible opportunities, discovery questions and a conversation opener grounded in what you actually sell. have a look at a list you use every week. when you add a row, what research or preparation do you go off and do by hand? that's a process worth looking at. watch the full Apify and SharePoint walkthrough here: youtu.be/3d8KBoCZ0TM

your Copilot skill is the SOP you would hand a new starter. write down how you want the job done, including what a good result looks like.

If you paste the same Copilot prompt every week, make it a skill. Do the work with prompts first. Ask Copilot to write it as a SKILL.md. Run it again in a fresh chat. Lock down who can edit it. Same steps, same output, every time. danielanderson.io/skillsmast…

Building a SharePoint knowledge base leaves you with decisions about access, sources, ownership and updates. I've pulled together what I'd plan around from two builds, including the preview limits and credits. The full guide: linkedin.com/pulse/sharepoin…

Start your SharePoint knowledge base pilot with a few questions one team asks regularly. Choose approved sources, agree the audience and name the owner. Then review the structure Copilot proposes. You'll have a clear purpose for every page you build.

A SharePoint knowledge base health check doesn't verify accuracy. It can find broken links, pages missing from navigation and incomplete source references. You still need someone to compare the guidance with its sources. Include that review before sharing it.

For each SharePoint knowledge base page, I'd plan: - A useful description - Consistent tags - Source references - An owner - A review date Decide those properties early. Retrofitting them across a few hundred pages is slow work.

Review your SharePoint knowledge base after a Copilot update, especially pages you've edited manually. During preview, AI updates can reverse those edits or recreate deleted pages. Include that review in the update process before people rely on the guidance.

Keep the source document visible from your SharePoint knowledge base guidance. In my HR build, page properties linked back to the original Word documents. When someone queries a policy, the reviewer has a source to check and an owner to follow up with.

Before importing content into a SharePoint knowledge base, check for drafts, duplicates and old guidance. An import copies what's there. I'd rather resolve conflicting versions in the source folder than leave readers to work out which KB page to trust.

Your SharePoint knowledge base needs someone responsible for requesting updates. In my build, I changed the employee handbook, then asked Copilot to refresh the pages. During preview, source changes don't update KB pages automatically. Give that request an owner.