Phase 2 · Microsoft Copilot · Level 3 · Power User
Build your own declarative agent with Agent Builder
By the end, you'll be able to…
- Explain what a declarative agent is and when a reusable agent beats a one-off prompt
- Build a working no-code agent in Agent Builder, grounded on files or a SharePoint site
- Write clear agent instructions and test that the agent answers only from its sources
Why it matters
Everything so far has been you prompting Copilot fresh each time. A declarative agent lets you package a role, a set of instructions and a fixed set of sources into a reusable assistant your whole team can open by name, like 'the onboarding agent' or 'the returns-policy agent'. Agent Builder makes one with no code, in the Copilot chat you already use. This is the first real 'power user' skill in the phase, and it turns a good prompt into shared infrastructure.
From prompting to building
Up to now you have been a user of Copilot: you type a prompt, read the answer, refine it. That works, but it has a ceiling. Every time you or a colleague needs the same kind of help, answering questions about the returns policy or drafting in the house style, someone has to remember the right prompt and paste in the right context all over again. Nothing is saved. Nothing is shared.
A declarative agent removes that repetition. It is a lightweight, custom version of Microsoft 365 Copilot that you configure once: you give it a name, a set of instructions describing how it should behave, and, this is the important part, a fixed set of knowledge sources it should answer from. From then on, anyone you share it with can open it by name and ask questions, and it responds in character, grounded on the material you chose. "Declarative" simply means you describe what it should do and know, rather than writing any code to make it work.
The tool for building one, with no code at all, is Agent Builder, and it lives right inside the Copilot chat you already use. This lesson walks you through building one end to end.
Licence note first, as ever in this level: Agent Builder and declarative agents are part of Microsoft 365 Copilot, so building and using them generally needs a paid Microsoft 365 Copilot licence, usually bought by your employer. If you do not have one, read for the concept and use the Fernway fallback in the activity to rehearse the design of an agent, which is the transferable skill.
What Agent Builder gives you
When you open Agent Builder (from the Copilot chat, choose to create a new agent), you get a simple two-sided screen. On one side you describe the agent; on the other you can test it live as you go. There are two ways to fill it in:
- Describe it in natural language and let Copilot draft the configuration for you: the name, the description and a starting set of instructions. This is the recommended, fastest route.
- Configure it manually on the Configure tab, where you type each piece (name, description, instructions, sample starter prompts) and add your knowledge sources by hand.
Most people start with the natural-language route to get a rough agent, then switch to the Configure tab to tighten the instructions and pin down the exact sources. The two work together.
The three things every good agent needs
- A clear role and description. One or two lines saying what this agent is for. "Answers staff questions about Fernway's remote-working policy." This shapes tone and scope.
- Instructions. The behaviour rules. How should it answer? What must it never do? This is where you say "answer only from the policy document; if the answer isn't there, say so rather than guessing."
- Knowledge sources. The material it is grounded on. You can point an agent at specific files (a Word doc, a PDF, an Excel sheet) or at a whole SharePoint site. When configured this way, the agent searches that content, and only content the user already has permission to see, for its answers. That permission boundary is not optional and not something you can widen from inside Agent Builder; it is covered properly in this level's governance lesson.
A fully worked example
Let's build the "Remote-working policy agent" for Fernway, grounded on a single policy document, so staff can ask plain-English questions instead of scrolling a PDF.
First, the natural-language description you give Agent Builder to seed the agent:
Create an agent called "Remote-Working Policy Assistant" that answers Fernway staff questions about our remote-working policy. It should draw only on the remote-working policy document I add as a knowledge source, answer in plain, friendly UK English, and always point the person to the exact section its answer came from.
Why this works: It names the role, the audience and the single source in one breath, so Agent Builder drafts a sensibly-scoped agent you then only need to refine, far faster than filling every field by hand.
Agent Builder drafts the name, description and a first pass at the instructions. Now you switch to the Configure tab and add the remote-working policy document as the knowledge source, and replace the drafted instructions with something tighter and more explicit:
You are Fernway's Remote-Working Policy Assistant. Answer staff questions using only the remote-working policy document provided as your knowledge source. For every answer, name the section or heading it came from. If the policy does not cover the question, say clearly "The policy doesn't cover that. Please check with your manager or HR," and do not guess. Keep answers short, plain and friendly. Never invent figures, dates or entitlements that aren't written in the policy.
Why this works: Explicit 'answer only from the source' and 'say when you don't know' rules are what stop a grounded agent from quietly filling gaps with general knowledge, the single most important instruction for a trustworthy internal agent.
Now test it in the live pane. Ask it the sort of question a real employee would:
How many days a week can I work from home, and do I need my manager's sign-off first?
Why this works: Testing with a real, slightly awkward question whose answer sits in the source is how you confirm the agent both finds the right passage and obeys the 'cite the section' instruction before you share it.
A well-grounded agent answers with the actual entitlement from the document and names the section it read. For example, "Under 'Eligibility and approval', staff may work remotely up to three days a week with manager agreement." Then do the crucial second test: ask something the policy doesn't mention ("Can I work from abroad for a month?"). A good agent says it isn't covered rather than inventing a plausible-sounding rule. If it invents one, your instructions aren't firm enough. Tighten the "do not guess" line and test again. That loop of ask, check against the source, tighten, is the whole craft of building a reliable agent.
Files or a SharePoint site?
Two grounding choices, and the right one depends on how much material there is and how often it changes:
- Specific files suit a small, stable set: one policy, one brief, a handful of FAQs. You know exactly what's in scope.
- A whole SharePoint site suits a larger, living body of content, like a team's document library that people keep updating. The agent stays current as the site does, because it searches the live site rather than a snapshot you uploaded.
For structured reference material a team maintains, hosting the documents on a SharePoint site and pointing the agent at the site is often the more durable choice. For a tight, well-defined answer set, a few named files keep the scope crisp and easy to reason about.
Try it now
Common mistakes
- Vague instructions that let it wander. "Be helpful about the policy" invites the agent to blend the document with general knowledge. Say explicitly: answer only from the sources, and say so when the answer isn't there.
- Grounding on the wrong scope. Point it at a huge, mixed site and answers get noisy and hard to trust; point it at one clean, relevant source and they sharpen. Match the sources to the job.
- Forgetting the permission boundary. An agent can't show a user anything that user couldn't already open. If colleagues get thin answers, it may be that the source sits behind permissions they lack, not that the agent is broken.
- Over-trusting a grounded agent because it "only uses our documents". Grounding makes an agent more reliable, not infallible: it can still pull the wrong passage, miss a caveat, or misread a table. Treat its answers on anything load-bearing, such as entitlements, deadlines or figures, as a strong pointer to the source, then read the cited section yourself before acting. The citation exists so you can check, not so you can skip checking.
Keeping current
Agent Builder's interface and the exact knowledge-source options move quickly, and new grounding types appear regularly. Treat the specifics here as a July 2026 snapshot. For the current detail, see Microsoft's Agent Builder in Microsoft 365 Copilot and Add knowledge sources to your declarative agent. Accurate as of 13 July 2026.