A small agent can be ready to try before lunch. Give it a name, connect one document, and ask a question in the test pane on the right. That speed is useful, but it says nothing yet about reliability. Copilot Studio can produce fluent answers before those answers are dependable, and a result in the editor doesn't tell you what a colleague will receive in Teams.
This lesson has two jobs. You'll build a focused, one-source agent. You'll also keep track of four different kinds of evidence: a saved draft, a test result, a published version, and a response observed by a real user. Each supports a different claim.
A first agent has four parts
Microsoft describes Copilot Studio as a graphical, low-code tool for building agents and agent flows. The editor brings together instructions, knowledge sources, topics, tools, and triggers. For this first build, pay attention to four parts:
- Purpose names the audience and the job. "Explain introductory Copilot Studio concepts to first-time makers, using one approved source" is specific enough to test. "Help with stuff" isn't.
- Instructions tell the agent how to use the source, how to format its answers, and what to do when information is missing.
- Knowledge is the approved material behind its factual claims.
- Published version is the particular version available through a deployment surface your organization has approved.
Begin with one purpose and one source. In that setup, you can still trace an answer back to the material that supports it. Add five sources and three tools at once, and a wrong answer has many more places to hide. Expand after the small version behaves reliably and you know how to diagnose it.
Are you in Classic or the new experience?
Before you touch a control, find out which of two authoring experiences you are in: they are different products wearing one name. The classic experience organizes an agent around topics, triggers, nodes, entities, and variables in separate areas. The new agent experience is instruction-based and lays everything out under four tabs: Build, Preview, Evaluate, and Monitor. Microsoft documents the new experience as a production-ready preview as of mid-2026.
You can tell them apart on sight, and you should, because the agent's name tells you nothing about which one made it:
Reach for classic when you need deterministic, scripted conversation paths or a feature only classic exposes. Start in the new experience for an instruction-led agent that reasons over Microsoft 365 organizational context. Build in one and you can't convert it to the other later.
Keep the agent inside its source
Grounding means giving the agent specific material to compose answers from. A connected source doesn't make every generated sentence true: the agent can still blend in general knowledge or fill a gap with something plausible. Your instructions close that gap, and two rules do most of the work. Tell the agent to answer product facts only from the configured source, and give it an exact sentence to say when the source doesn't cover the question. Skip that second rule and "I don't know" turns into an invented answer.
Then test both sides of the boundary in fresh conversations. Ask one question the source clearly answers, and one it clearly does not. The supported question checks that real facts survive. The unsupported question checks that the agent refuses to invent. Grade the supported answer sentence by sentence: every factual claim must map to a passage in the source. One fluent sentence with no supporting passage fails the whole response, no matter how good the rest looks. Run this check before you trust any other part of the build.
Saved, tested, published, deployed: four different claims
Treating any single step as proof of the whole chain turns a good build into an embarrassing one. Copilot Studio produces four distinct kinds of evidence, and each one licenses only a narrow conclusion.
The test pane is an authoring-time inspection surface inside the editor. You can reset the conversation and try again there. Publishing makes a version available through associated channels, and practitioners have reported cases where a published Teams agent answered differently than the same agent in the test pane. That is why the only evidence an agent works where people use it is a fresh conversation in the actual deployment surface, run after publishing. Earlier steps support narrower claims about saving, testing, or publishing. You will run that real-host verification in Autonomous Agents, Testing, and Publishing. For now, keep "it saved," "it passed the test," and "it works" as separate claims.
A first agent is done only with evidence
A first agent is finished when its evidence can be reviewed. Concretely: the supported question returns only source-backed claims, the unsupported question returns your missing-information sentence, and (if you have somewhere to publish) the same two questions pass again in a fresh conversation in the real host. Write down the prompt, the full response, the matching source passage, your verdict, and any correction for each run. The log turns a general impression into evidence a reviewer can check.
If you are in the new experience, its four tabs give you this loop by design: Build to configure, Preview to try realistic prompts, Evaluate for whatever repeatable checks your tenant exposes, and Monitor for whatever runtime views it surfaces. Move through them in that order and you will rarely ship an answer you haven't inspected. The next lesson, Knowledge Grounding and Conversation Design, makes the grounding half of this more reliable.
Everything in this module comes back to evidence: what you configured, what you tested, what got published, and what a person actually received. You just practiced separating those for a one-source agent. Conversation design, tools and flows, autonomy, and publishing apply the same separation to a larger surface, not a different one.
