Perform basic administrative tasks for Copilot and agents
Building and Testing Agents
Follow a Fundamentals-level build-test-edit lifecycle and choose Agent Builder, SharePoint agent creation, or Copilot Studio according to scope and complexity.
What you need to know
- Begin by defining the problem the agent should solve, the owner who will maintain it, the audience who needs it, and measurable success/retirement criteria. A vague “answer anything” goal produces weak instructions and uncontrolled scope.
- Choose the smallest approved knowledge set that can answer the purpose. Knowledge can include selected SharePoint sites, libraries, folders, or files and other supported sources. Agent access never replaces each user’s permission to those sources.
- Instructions define role, task boundaries, tone, source priorities, refusal/escalation behavior, and output expectations. Suggested prompts help users understand supported tasks but do not expand capability or permission.
- Add connectors or actions only when the agent must retrieve external data or perform work. Each connection adds authentication, authorization, data-flow, failure, and approval considerations; least privilege is a design requirement.
- Agent Builder in Microsoft 365 Copilot is suited to fast, lightweight agents for an individual or small team, grounded in Microsoft 365 or web knowledge. A maker can describe the agent in natural language, refine instructions/knowledge, and test before sharing.
- A SharePoint agent is created from selected site/library/folder/file knowledge and represented as an agent file with its own access. Users still receive answers based on their permission to every knowledge source.
- Copilot Studio is the better choice for broader audiences, multi-step logic, advanced actions/connectors, custom integrations, structured environments, telemetry, or application lifecycle management. An Agent Builder agent can be copied to Copilot Studio when it outgrows the lightweight experience.
- Testing should include representative happy paths, unclear questions, unsupported requests, stale/conflicting sources, users with different permissions, sensitive data, and action failures. The maker then corrects instructions, knowledge, prompts, or actions and retests before sharing or submission.
How it works
- Lifecycle: define purpose and owner → choose audience and least-privileged knowledge → write instructions → add only necessary actions → build in the appropriate experience → test representative scenarios → edit/correct → share or submit/publish under governance.
- The test experience runs the current draft against configured knowledge and capabilities. A poor answer can come from missing/contradictory knowledge, unclear instructions, unavailable permission, or a failing action; the correction depends on the cause.
- Sharing grants access to use the agent within supported controls. Publication makes it discoverable to an organizational audience after the required review. Neither operation changes source permission.
Compare and distinguish
- Agent Builder vs Copilot Studio: quick lightweight Microsoft 365 knowledge agent vs richer low-code integration, workflow, environments, and lifecycle control.
- SharePoint agent vs Agent Builder agent: creation grounded directly in selected SharePoint content vs broader lightweight authoring in the Copilot experience; both honor user source permission.
- Knowledge vs instructions: facts/sources the agent may ground on vs behavior and task rules that tell it how to respond.
- Connector vs action: connection/data access mechanism vs operation the agent can invoke through configured capability.
- Testing vs approval: maker validation of behavior vs administrator governance decision about organizational availability.
- Creation vs sharing vs publication: draft exists vs selected people can use it vs approved organizational catalog/audience availability.
Objects and administrative surfaces
- Purpose, description, instructions, knowledge, suggested prompts, test pane, sharing — Agent Builder in Microsoft 365 Copilot.
- Selected content, .agent file, file permissions, source permissions, sharing — SharePoint sites and libraries.
- Topics/instructions, knowledge, connectors, actions, test chat, environments, versions, publication — Microsoft Copilot Studio.
- Publication requests and organizational audience — Microsoft 365 admin center Agent Registry/Agent 365 registry.
Scenario examples
- Scenario: HR wants a small-team frequently asked questions assistant grounded in approved policy files — reasoning: Agent Builder can provide the lightweight experience; test permissions and policy questions before sharing.
- Scenario: A project library needs a focused Q&A agent — reasoning: create a SharePoint agent from the selected content and manage the agent file and source access separately.
- Scenario: Support needs an agent that creates tickets in an external system — reasoning: Copilot Studio is appropriate because the action/connector and broader lifecycle need richer control.
- Scenario: A draft answers a manager’s test but exposes a source to no ordinary employee — reasoning: test with representative identities and permissions; owner success alone does not validate audience behavior.
- Scenario: A maker shares an agent with five colleagues — reasoning: sharing is not tenant-wide publication or administrative approval.
When to use it
- Use Agent Builder for a focused individual/small-team Q&A agent based on approved content.
- Use SharePoint agent creation when the desired knowledge is a selected SharePoint site, library, folder, or file set.
- Use Copilot Studio when the agent needs broader deployment, complex logic, external systems/actions, or structured development/test/production governance.
Security and governance implications
- Use least-privileged knowledge, connectors, and actions; name an owner and backup owner; define review and retirement criteria before broad use.
- Test prompt injection, unsafe actions, sensitive data, permission differences, unsupported requests, and escalation paths at a proportional Fundamentals level.
- Store authoritative knowledge in managed sources and update or retire the agent when those sources or business processes change.
Troubleshooting signals
- Wrong answer: verify source quality/currentness, retrieval, conflicting knowledge, instructions, and prompt clarity. Missing answer: verify selected source and the test user’s access.
- Failed action: inspect connector authentication, permission, environment/data policy, input, and downstream service—not the text knowledge first.
- Cannot share/publish: check maker policy, agent ownership, licensing/metering, audience, publication request status, and admin governance controls.
- Retest after every material change using the same representative scenarios plus a regression case for the defect.
Exam traps
- Adding more knowledge or connectors does not automatically improve an agent; it can increase ambiguity and risk.
- Agent Builder and Copilot Studio overlap, but they target different complexity, audience, integration, and lifecycle needs.
- Testing as the owner does not prove that intended users have source or action access.
- Creating, sharing, submitting, approving, and publishing are separate states and decisions.
Key takeaways
- Purpose + owner + audience + knowledge + instructions + least privilege come before building.
- Build with the simplest suitable tool; test representative users and failures; edit and retest.
- Share is not publish, publish is not source permission, and approval is not permanent correctness.
Related objectives
- D3.3.b