Three files in a SharePoint library keep answering the same launch questions. A SharePoint agent can make those documents available as a Q&A experience in the place where colleagues already work. The build is the easy part. Before sharing, you need to know which sources it uses, how it handles missing or conflicting information, and whether another user sees the same behaviour.
Start from one of the documented SharePoint paths
SharePoint has three verified creation paths, each with a different starting point:
Verify something different on each path. From the homepage, inspect the knowledge shown before saving. From the command bar, check which content the creation experience displays. From a file's context menu, confirm that the selected file appears in source review. The file path is documented. A folder context-menu path isn't, so don't base your process on selecting a folder.
SharePoint stores the created agent as an .agent file in the site's Site Assets/Copilots location. That entry point doesn't define the final knowledge boundary. Starting in a library doesn't prove the whole library is attached. Inspect what the creation experience shows, then test the saved agent. You may also encounter a preview experience called AI in SharePoint, formerly Knowledge Agent. It is separate from these custom-agent creation paths.
Keep a short lifecycle record with the agent's purpose, creation path, sources, instructions, intended audience, and test results. The source documents carry the facts. The .agent file represents the agent. Your record explains the expected behaviour. When a source, instruction, or audience changes, run the tests again.
Trustworthy answers name their sources
The same grounding discipline from Agent Builder applies here, with one addition worth insisting on: filenames. Classify each answer as supported (it appears in an identified source), synthesized (it correctly combines sources), missing (the sources don't contain it), or conflicting (two sources disagree). "Missing" and "conflicting" are valid, useful results. A confident answer with no source behind it is not.
Write instructions that make the agent name its evidence and surface disagreement. If one document says the launch date is August 18 and another says August 20, the answer should report both files and both values. When no file names the security-review owner, the agent should say that the selected sources could not verify one. Filenames make an unsupported, plausible-sounding name easy to spot.
A quick way to pressure-test grounding is a two-column answer format: value and source document. When every row must carry a filename or an explicit "not found in selected sources", the agent has nowhere to hide an unsupported claim, and you can audit a whole response at a glance.
Why test with a second user?
An agent working perfectly for you proves nothing about how it behaves for a colleague. Sharing and source access are separate checks. When you add a pilot user, test two questions independently: can the intended tester open the agent, and what grounded, missing, or conflicting answers do they receive? A successful share does not guarantee that every source-access path resolves the same way it does for you.
Treat the second user's results as evidence for that user and configuration. Record four things separately: whether they could open the agent, the exact answer to each prompt, the filenames named, and any difference from your own results. Access and answer quality can diverge. A successful share does not show that the source-access path worked correctly for that person.
One unexplained or unsafe answer is a reason to pause the pilot and involve the site owner, then return the agent to a smaller audience while you investigate. Expanding an audience on the strength of your own results is how an undetected problem reaches a whole team.
Employee Self-Service depends on the handoff
When an agent becomes the front door to HR and IT, the stakes rise. The Employee Self-Service (ESS) agent is a Microsoft-provided, IT-admin-deployed agent that lets employees get information or start approved support processes, integrating with systems such as ServiceNow (both HR and IT service management), Workday, and SAP SuccessFactors. The connected systems remain authoritative. ESS is the conversational entrance to them. Picture an interaction as five stages: the employee expresses an intent, ESS decides whether it's supported, ESS answers or invokes a handoff, the receiving system processes it, and the employee sees a confirmation, limitation, or failure. A fluent response at stage three proves nothing about stage four.
This is the handoff failure to test. A confident "I transferred you to HR" is not proof a transfer happened. A handoff is a testable contract: if ESS claims a request was submitted, the acceptance test must find correlated evidence in the receiving system, matched by identity, scenario, and time. No receipt means the test fails: the employee-facing message must say completion wasn't confirmed and offer the approved route, and a configuration with an unresolved critical failure must not be promoted to production. ESS follows a proper release process: build and test the configuration in a sandbox, then promote it. That gate catches a false success message before real employees encounter it.
Be just as precise about other systems. Unless a provider-specific operation has been verified and configured, ESS must not claim it "updated your Workday record" or changed a SAP SuccessFactors field. The correct response states the limitation and points to the approved HR process. Keep the HR and IT paths as separate contracts, too: they can have different owners, required information, and definitions of success, so a passing IT ticket says nothing about whether an HR escalation actually landed.
It helps to see an ESS deployment as four separable parts: the employee experience (what the person sees and does next), the ESS configuration (which intents are supported and how handoffs trigger), the system handoff (whether the receiving system holds correlated evidence), and the administration and lifecycle process (how a tested configuration is promoted and re-checked). Better wording in one part can't repair a broken connection in another, and a working connection can't repair an unsafe message. Test each part on its own before deciding whether the whole thing is ready for people.
