Capstone: build a real declarative agent and a one-page rollout note

What this capstone is for

Everything in this level taught a piece. This lesson asks you to assemble them into something real and defensible: a working declarative agent that a colleague could really use, and a one-page note that would let a manager decide whether to roll it out. The deliverable is not "I built an agent and it answered a question." It's "I built an agent grounded on this real document set, I tested that it's accurate and that it refuses to guess, I've thought through who can see the sources, and here, on one page, is what it's for, what it saves, and what governance it needs."

That second half is what makes this a power user capstone rather than a walkthrough. Anyone can make an agent respond. The skill that matters at work is making it safe to share and being able to explain it briefly to someone who controls the rollout. A brilliant agent nobody trusts enough to deploy has changed nothing.

Licence note: building and sharing a declarative agent uses Agent Builder inside Microsoft 365 Copilot and generally needs a Microsoft 365 Copilot licence. If you don't have one, you can still complete most of this capstone as a design exercise: write the full agent specification (name, instructions, sources), design the two-part test, and write the rollout note. The thinking is the assessable skill; the clicks are the easy part.

The project brief

The one-page rollout note

Copy this and fill it in. Keep it to one page; a power user communicates a build briefly and honestly.

Rollout note

• Agent name and purpose: one line: what it is and who it's for
• Grounded on: the exact document set / SharePoint site used as knowledge
• What it does well: the questions it answers reliably; be specific
• What it deliberately doesn't do: its scope limits; that it refuses to answer beyond its sources
• Accuracy test result: how many source-covered questions it got right, checked against the source
• Refusal test result: did it decline to answer the uncovered questions? evidence it doesn't guess
• Who can see the sources: the permission picture on the grounding content, the key governance fact
• Governance to confirm with IT: permissions review, sensitivity labels / DLP, external-content restrictions
• Value if rolled out: the saving or improvement, e.g. "staff self-serve policy questions instead of emailing HR"; rough, honest figures welcome
• Where a human still checks: the load-bearing step you'd keep with a person
• Recommendation: roll out to whom, after what checks, or not yet, and why

Suggested approach

Build small and test hard. The temptation is to ground the agent on everything and show off its range; resist it. A tightly-scoped agent on a clean source set is both more useful and far easier to trust than a sprawling one. Get one clear job right.

Spend most of your effort on step 3, the two-part test, because it's what separates a demo from a deployable tool. The accuracy test proves the agent is useful; the refusal test proves it's safe, that it won't confidently fabricate an entitlement or a deadline when a real employee asks something the documents don't cover. An agent that answers well but also invents when cornered is more dangerous than no agent, because people will believe it. Showing you tested both is the single strongest thing in this capstone.

When you write the rollout note, write it for the manager, not for yourself. They don't need the build steps; they need to know what it's for, whether it's trustworthy, who could see the underlying content, and what it would take to roll out safely. The governance line, who can already see the sources, is the one a good manager will ask about first, so lead with it having an answer ready.

Self-assessment rubric

Score yourself honestly against each level, and be able to point to evidence for your score.

• Basic. You built an agent grounded on a real document set and it answers questions from the sources. You can describe what it does, but you tested only that it works, not that it refuses to guess, and the rollout note is thin on governance or value.
• Good. Your agent is well-scoped with firm instructions. You ran both tests: it answered source-covered questions accurately (checked against the source) and refused to invent answers to uncovered ones. Your one-page note covers purpose, both test results, the permission picture on the sources, and a clear recommendation.
• Excellent. All of "good", plus: your instructions make the agent cite its sources; your refusal test was truly adversarial (you tried hard to make it guess and it held); your governance section names specific permissions, labels/DLP and external-content checks to confirm with IT; you quantified the value with honest working; you named where a human still checks; and your rollout note is something a manager could act on without asking you a single follow-up question.

The gap between "good" and "excellent" is almost entirely governance and communication, not a cleverer agent. A power user is trusted with rollouts precisely because they think about who can see what and can explain it on one page.

Evidence note

Common mistakes

• Testing only that it works. An agent that answers its source questions well has passed half the test. The half that matters for a rollout is whether it refuses to guess when a question falls outside its sources. Skip the refusal test and you're shipping a confident fabricator.
• Over-grounding. Piling in every document you can find makes answers noisier and trust harder. One clean, well-chosen source set beats an everything-agent.
• Ignoring the permission picture. Because the agent respects existing permissions, the safety of a wider rollout depends entirely on who can already see the sources. A rollout note with no answer to "who can see this?" isn't finished.
• Writing the note for yourself, not the manager. Build steps and prompt wording don't belong in a rollout note. Purpose, trustworthiness, governance and value do. If a manager would have to ask you a question to decide, the note needs another pass.
• Over-trusting your own agent in the write-up. The most subtle trap: you built it, it impressed you, so you present it as more reliable than your testing supports. Let the evidence set the claim. If it got four of five accuracy questions right and needed two rounds to stop guessing, say so. Honest limits are what make the rest of the note credible.

Keeping current

The capstone method of build small, test for both accuracy and refusal, govern the permissions and communicate on one page, is durable and will outlast the specific interface you built in. Agent Builder itself changes quickly, so re-check its current knowledge-source options and sharing controls against Microsoft's Agent Builder in Microsoft 365 Copilot when you revisit this. Accurate as of 13 July 2026.