Most Copilot agents I see built in demos look impressive for about five minutes. Then someone asks a real question, gets a vague non-answer or something pulled from the wrong document, and the whole thing gets quietly shelved. The problem usually isn’t the platform. Copilot Studio is somewhat decent. The problem is that the agent was never set up to succeed in the first place… and the maker had no clue their decisions made it that way.
Building one that actually works comes down to three things:
- instructions that are specific enough to control behavior,
- a knowledge source that’s scoped tightly enough to be trustworthy,
- and a couple of settings that are wrong by default.
Get those three things right and you end up with an agent that HR teams will actually rely on. Get them wrong and you’ve got an expensive magic 8-ball… or worse, a failed demo in front of a LOT of people 🤣.
This post walks through how I build an HR policy agent in Copilot Studio from scratch. I’ll cover the mechanics, but more importantly I’ll explain the decisions behind them, because that’s the part most tutorials skip.
Why HR Is a Great First Use Case
If you’re trying to make the case for Copilot agents inside your organization, HR is one of the best places to start. The problem is well-defined, the pain is real, and the ROI is easy to explain to leadership.
HR teams spend a ton of time answering the same questions over and over – vacation accrual, PTO carryover, what counts as a qualifying life event for benefits enrollment, how the new hire onboarding process works. These aren’t hard questions by any stretch of the imagination. They’re just frequent ones. Every one of those questions takes up valuable time for an HR professional who could (and should) be doing something that actually requires their judgment and expertise.
That’s a fair statement to make, right?
An agent that can answer those questions instantly, accurately, and at 2am on a Sunday is a genuinely useful thing. It’s not a toy demo. And because it’s pulling from your official policy documents rather than someone’s memory or interpretation… the answers are consistent in a way that a shared inbox or a “just ask so-and-so” culture never really is. Plus, you don’t risk annoying HR with questions they already answered 20 times that day.
Getting Started: The Part You Can Move Through Quickly
The initial setup in Copilot Studio is straightforward. Create a blank agent, give it a name, write a short description that explains what it’s for. The description matters more than it seems – it’s what shows up in the Teams app store and the Copilot agent catalog, so employees need to be able to tell at a glance whether this is the right agent for their question.
One thing worth doing that people often skip: upload a custom icon. It just needs to be a PNG under 30KB, ideally your company logo or something in a square format. It’s a small thing, but an agent with a real icon feels like part of the organization’s toolkit. An agent with a default robot icon feels like a test someone forgot to clean up.
Pick your model. If you have options available and you’re not sure where to start, just accept the default. You can experiment with models later – getting the rest of the configuration right matters a lot more than model selection at this stage.
Instructions: Don’t Treat This Like a Form Field
Here’s where most people rush, and where most agents fall apart.
Copilot Studio gives you 8,000 characters for your agent’s instructions. That’s not a description box – it’s the place where you actually define how this thing behaves. If M365 Copilot already seems to “know how to act,” it’s because Microsoft wrote a very detailed set of instructions for it. When you’re building a custom agent, that job is yours.
Your instructions need to cover a few things clearly. First, define the role – not just what the agent does, but what it is. Tell it it’s an internal policy assistant for employees of your organization. Tell it its job is to explain what policies say, who they apply to, and what someone should do next. Second, give it knowledge guardrails. Be explicit: answer based on the provided knowledge source, don’t speculate beyond what the documents say, and if something isn’t covered, say so. Third, tell it how to format responses. Markdown formatting – bullet points, headings, bold text – makes answers readable. Plain text walls don’t.
The language you use in instructions matters. Intentional, specific phrasing produces predictable behavior. Vague phrasing produces variable behavior, and variable behavior is what erodes trust in the agent. Spend real time here. It’s worth it.
Here’s the basic version I used in the video above. If you want the hardened production version, it’s in my finished version in The Agent Collection.
# Role
You are an internal HR Policy Assistant for employees of the organization.
Your role is to:
- Answer employee questions about HR policies and procedures
- Explain policies clearly and neutrally
- Help employees understand what the policy says, who it applies to, and what to do next
You are not an HR decision-maker and do not provide legal advice.
# Knowledge Usage
- Use only the provided HR policy grounding sources as your source of truth.
- Do not speculate, guess, or infer policies that are not explicitly documented.
- If multiple documents mention the same topic, reconcile them carefully and note exceptions.
- If a policy is unclear, missing, or contradictory, say so explicitly.
If the grounding content does not clearly answer the question:
- State that the information is not available in the current policies
- Recommend contacting HR for clarification
# Response Formatting
Use clear, structured Markdown in every response.
When answering a policy question, follow this structure when applicable:
## ✅ Short Answer
A brief, plain-English summary (1–3 sentences).
## 📄 Policy Details
Bullet points or short paragraphs explaining:
- What the policy says
- Any conditions, limits, or exceptions
- Who the policy applies to
🔒 Sponsored by Afi — Smarter Cloud Backup & Recovery
Cloud platforms like Microsoft 365, Google Workspace, Azure, AWS, and Kubernetes are powerful — but they don’t always protect your data the way you think. Accidental deletions, ransomware, and compliance gaps can still cause serious disruptions.
That’s why I’ve partnered with Afi, a modern backup and recovery solution built for today’s multi-cloud environments. Afi offers full-fidelity restores, encrypted full-text search, version history, and even self-service recovery — so users can get their data back without waiting on IT.
Its AI-powered ransomware detection automatically triggers backups before damage is done, giving you peace of mind and keeping your business running smoothly.
Over 10,000 organizations trust Afi to protect their cloud data.
Learn more at afi.ai.
The Knowledge Source Decision That Most People Get Wrong
Once instructions are in place, it’s time to connect the agent to your documents. In SharePoint, you likely have an HR site with a dedicated Policies library. Things like the vacation policy, remote work policy, benefits guide, onboarding documentation, etc… all of it in one place. HOPEFULLY 🤣
Otherwise, you have a different problem to tackle first, right?
Here’s the decision point that matters… you can add the entire SharePoint site as a knowledge source, or you can add just the Policies library. Adding the whole site feels easier and more comprehensive. It’s actually neither. When you give the agent the entire site, you’re telling it to search everything… meeting notes, project plans, old announcements, that newsletter from 2022 that nobody reads. The agent will try to use all of it, and your answer quality will suffer for it. And your users will complain that “CoPiLoT sUcKs” or something like that. At least that’s how it plays out in my head 🤣.
Give the agent only what it needs. In this case, that’s the Policies library and nothing else. The narrower the knowledge source, the more accurate and trustworthy the answers will be.
Your agent is like a race horse. Keep the blinders on it.
When you add the knowledge source, also update the description field – something like “This knowledge source contains HR policies and procedures.” The agent uses those descriptions to understand what each source contains. Don’t leave them blank.
Two Settings That Are Wrong by Default
This is the part that people always forget… and it’s buried in the settings screen. Well at least one of them is, but they can both be found side by side to make it an easy thing to configure together.
After adding your knowledge source, go to Settings → Generative AI → Knowledge and look for two things. First: web grounding. It’s on by default. Turn it off. You don’t want this agent searching the internet for HR policy answers. You told it exactly where your policies are – let it use those and nothing else.
Second: Allow Ungrounded Responses. Also on by default. This setting lets the agent draw from its own built-in training knowledge to fill gaps when your documents don’t cover something. That sounds helpful until you realize it means your HR agent might answer a question about FMLA based on general internet knowledge rather than your company’s specific policy. Turn it off. Immediately.
You don’t want to recreate ChatGPT. You want an agent that only knows how your business operates.
With both of these disabled, the agent’s only source of information is your company’s documents. That’s the entire point. That’s how you get answers you can actually stand behind.
Add Suggested Prompts – They Matter More Than You Think
Before publishing and testing it out, add a few suggested prompts. These show up as clickable conversation starters in the chat interface – things like “What is the vacation policy?” or “How does the onboarding process work?” – and they do something important: they show employees what the agent can do before they’ve even typed anything.
A lot of people are still figuring out how to interact with AI tools. They’re not sure what to ask, how specific to be, or whether the agent can actually help with their question. Suggested prompts make it easy to understand how to use this agent… immediately. Someone sees “What is the parental leave policy?” as a button, clicks it, and gets a good answer. Now they understand what this thing is for. Now they’ll use it again.
Test Before You Ship
Copilot Studio has a test panel built right into the builder, and the feedback loop it creates is genuinely fast. Ask your agent a question you know should be answerable from your documents, watch it search the knowledge source, and look at the response. Check which documents it referenced. Ask a question you know isn’t in your documents and see how it handles the gap.
This is where having tight instructions pays off. An agent with vague instructions will hallucinate its way through uncertain territory. An agent with specific instructions will tell the user it doesn’t have that information and suggest they contact HR directly. That second behavior is what makes an agent trustworthy in a production environment.
Publishing and Getting It Into Employees’ Hands
Once you’re happy with how the agent is performing, publish it and head to Channels. For an internal HR agent, you’ll want to deploy to Teams and the M365 Copilot app – that’s where employees will expect to find it. You can also drop it directly on a SharePoint page through the SharePoint channel, which works especially well if you already have an HR intranet site employees visit regularly.
To make it available org-wide, go to Availability Options under the Teams channel. You can either download the app package and send it to your Teams admin, or submit it directly to your org’s app catalog for admin approval. Either way, plan for that approval step in your timeline – it won’t go live the same day you submit it.
What You’ve Built – And What Comes Next
What this build gives you is a solid, demo-ready HR policy agent. It’s grounded in your company’s documents, it has controlled behavior, and it’ll impress anyone you show it to in a leadership demo.
What it isn’t yet… is production-hardened. Real users will find edge cases your instructions didn’t anticipate. They’ll ask questions in ways you didn’t expect. They’ll try to get the agent to do things outside its defined role. A production-ready agent needs more comprehensive instructions, tighter guardrails, and a few additional configurations that go beyond what a demo build requires.
I’ve got a fully hardened version of this agent available inside my agent collection membership – built out for real business use, not just a demo. If you’re ready to take this further, get the agent today.
Want this configured for your business in a done-for-you fashion? Contact me below!
