How to Build a Copilot Agent: The Right Flow, Step by Step

Before you touch the builder (Microsoft Copilot Agent Builder, as of September 2026) at all: define who this agent is for, what it does, and what it never does under any circumstance. Boundaries and risk come before capability, not after.

When an agent stalls mid-build, it's usually because someone tried to solve too many problems at once. A narrow assistant, something like a "contract summarizer" that only summarizes contracts, beats a broad one, and you expand only once its behavior is stable.

A concrete example that works: an agent that answers only employee questions about vacation days and attendance policy, and never touches pay, complaints or hiring. An example that almost always fails: an agent called "Employee Services" that's supposed to answer everything. You can test the first one in a single workday. Nobody can really test the second, because nobody actually knows what it's supposed to know.

And a use case that's too broad wrecks the whole process, well beyond this step: without a clear boundary, the instructions in the next step come out vague too, and the examples in step 3 start contradicting each other. Anyone asking how to build a Copilot agent properly needs to start exactly here, not inside the builder itself.

Another common mistake: picking a use case based on what looks most impressive to leadership, not what's easiest to test. Those don't always overlap, and when you have to choose, always choose testable.

(By the way, the first use case for your Copilot agent doesn't need to be impressive. It needs to work).

You write instructions for a Copilot agent exactly the way you'd brief a new hire on day one: the role, who it's talking to, the tone, the answer structure, and what it's not allowed to do. Direct phrasing works best ("You are…", "Always…", "Never…"), not vague general language.

This is the step most people skip, and they're wrong to. Thin instructions produce an agent that starts strong and falls apart after 5 questions. Write both what to do and what not to do, explicitly.

(A small example: it's not enough to write "answer briefly". Write "answer in 3 to 5 lines, no preamble, and flag when you're not sure").

A classic mistake: organizations write instructions that describe what the agent is supposed to be ("a friendly, professional assistant") instead of what it's supposed to do. That sounds similar, but it's an instruction you can't actually test: a "friendly" agent can behave a dozen different ways and still fit that description. An agent that answers "in 3 to 5 lines, no preamble, and flags when it's unsure" can only be read one way.

And without instructions that clear, your agent guesses how to behave in every single conversation. Sometimes it guesses right, sometimes it doesn't. That's exactly why it looks "off" in the first demo, even when it was built more or less correctly.

And when instructions get too detailed in the wrong direction, trying to cover every edge case imaginable, the opposite happens: the agent turns hesitant, and hedges even on simple questions. Same fix either way: concrete and focused, not exhaustive.

Want a ready template you can paste in without the explanations? We already built one, in Hebrew and English both: grab the copy-paste instructions template.

Three to five ideal question-and-answer examples improve an agent's behavior more than any written description of the style you want. Instead of writing "answer like an expert", paste a real question-and-answer pair and show it what that looks like.

(The irony: the step people skip most is exactly the step that improves results the most).

An example of a pair that works well: the question "What's our refund policy for a private customer?", and the answer in exactly the format, tone and length you want the agent to repeat every time. An agent that sees one good example like that learns more from it than from a whole paragraph explaining "answer in a professional, focused tone". 3 to 5 examples like this, across a range of question types, are usually enough for the agent to settle into a consistent style.

This is also where most teams discover their step 2 instructions weren't as clear as they thought: the moment you try to write a real sample answer that follows the instructions, every gap the written instruction didn't cover shows up.

Grounding means requiring your Copilot agent to answer only from the source material it was given, and to cite the file name or section in every factual answer. It cuts hallucinations and lets you check every answer against a specific document, instead of trusting the model's "general knowledge".

Add an explicit instruction for when there isn't enough information: "If unsure or missing info, say you don't have enough information and ask for clarification or an upload." Without that line, the agent will simply invent a confident-sounding answer.

This is the step most large organizations skip, because it sounds "obvious". Then they're surprised when the agent gives confident, wrong answers. Grounding is what makes an agent something employees can actually rely on, instead of something you have to fact-check every time.

Without grounding, the agent never really "doesn't know" anything. It will always find something to say, because that's how language models work: they complete plausible text, even when they don't have the information. With an explicit grounding instruction, "I don't know" becomes a legitimate, correct answer, not a failure of the agent.

In the EY lecture, I asked the room who would trust an agent's answer without checking it against the source. Almost nobody raised a hand, and that's exactly the point: grounding is what turns "almost nobody" into "most people".

(Grounding sounds like a technical detail. In practice it's what turns an agent from "another cute chatbot" into something you can check and rely on).

Don't upload "everything you have". Choose precise documents, playbooks, FAQs and decks, with clear file names and version control. A small, maintained knowledge base outperforms an overloaded one, and it's easier to maintain too: you swap one file instead of rebuilding the agent.

The natural temptation is to upload a whole folder "just in case". Don't. The knowledge sources feeding your agent need to be focused, not comprehensive.

A knowledge base that starts organized usually stays organized. One that starts with "upload everything, sort it out later" almost never reaches the sorting-out stage. The problem isn't only performance. An overloaded knowledge base makes the agent find contradictions between old and new documents, and answer from the wrong one, with no way to know that happened.

A real example: an FAQ file that's been replaced 3 times in the past year, but both old versions are still sitting somewhere in the shared folder. If all 3 get uploaded to the agent, it might confidently quote the policy that was true a year ago.

A rule of thumb I give in training: if you're not sure whether a document belongs in the knowledge base, it probably doesn't. Upload it only after it's been reviewed and approved as current.

(A clear file name and tidy version control sound like a boring technical detail, right up until you try to maintain an agent 6 months later without them).

Yes, and I recommend it: use Copilot itself (in the Work or Web interface) to draft the instructions document, instead of hand-writing prompt engineering from a blank page. In the EY lecture, I demonstrated this with a prompt along the lines of:

"Please write me instructions for a Copilot agent that will keep my kids busy after school instead of me. The agent needs to…"

(Note: this is roughly what was actually said on stage, unpolished, and I'm leaving it exactly like that because it makes the point perfectly: you can ask Copilot for something completely everyday, and it knows how to turn that into a proper instructions document).

The idea: Copilot already knows what good instructions look like. Instead of starting from a blank screen, ask it for a first draft, then update that draft based on what actually happens in testing (step 7 below).

The reason this works well is that a good instructions document is really a description of a familiar human process: a role, an audience, a tone, an answer structure and boundaries. Copilot has already "seen" thousands of documents like that, so its first draft is almost always close to what you actually need, even if it's not perfect.

In practice, it looks like this: ask for a draft, test it against 3 or 4 real questions, and ask Copilot to fix one specific paragraph based on what you saw. That's a cycle of minutes, not meetings.

A common mistake: asking Copilot to write instructions without giving it any context about your organization or the actual use case. The draft you get back will be too generic. Give it real context (who it's for, what questions it will get, what it must never answer), and the draft comes out much closer to the finished product.

Build a fixed set of 5 to 10 test questions and rerun them every time you change a setting or the knowledge base. That loop is what keeps an agent improving after launch day, instead of quietly going stale.

Keep a fixed set: 5 to 10 real prompts that represent what your users will actually ask. Testing a Copilot agent doesn't need to be complicated, just consistent: every time you change the instructions, add an example, or swap a knowledge file, rerun the whole set and check what changed.

Honestly, the worst agent I ever saw wasn't one that was badly built. It was one that was built well, and then nobody touched it for 6 months, while the policy it kept quoting had already gone stale. A test loop checks more than whether the agent "works". It checks whether it's still right.

A good test set includes ordinary questions ("what's the policy on X") and edge questions too: something the agent isn't supposed to answer at all, to confirm it knows how to decline politely instead of guessing.

If you don't have a fixed set yet, start today with just 5 questions. You can expand later. What matters most is that the set actually runs every time, not that it's perfect from day one.

(Without a test loop, you build an agent once and hope for the best. With a test loop, you build an agent that gets better every week. Knowing how to build a good Copilot agent really means knowing how to keep it good after launch).