Creating a Copilot agent for Teams works best when you treat it as a team assistant with a narrow job, not as a general chatbot. The goal is to give a channel, project group, or recurring meeting workflow a reliable helper that answers from approved content and tells users when the source does not cover the request.
This walkthrough uses Microsoft 365 Copilot Agent Builder as the starting point, then shows how to prepare the agent for Teams users. If your tenant uses Copilot Studio for formal publishing, the same planning, knowledge, and testing checks still apply.
Decide what the Teams agent should do
Before you open Agent Builder, choose one workflow that happens often in Teams. Good first agents answer onboarding questions, explain project operating rules, find meeting decisions, or point users to the right file or owner.
Avoid a first agent that tries to answer every question about the department. A broad agent is harder to test, easier to overshare, and more likely to disappoint users. If the real need is help inside live meetings, compare this build with a meeting-agent setup path before you create a reusable channel assistant.
Write the scope in one sentence:
- Audience: who should use the agent.
- Knowledge: which chats, meetings, files, or sites it can use.
- Boundary: what it should refuse or redirect.
- Owner: who maintains the sources and instructions.
Create the agent in Microsoft 365 Copilot
Open Microsoft 365 Copilot and select the option to create a new agent. Agent Builder lets you start by describing what you want, configure the agent manually, or use a template. For a Teams-focused tutorial, the natural-language path is usually the fastest first draft.
Step 1: Describe the agent clearly
Use a direct prompt instead of a vague name. For example:
- Create an agent for the Customer Success team.
- It should answer from selected Teams chats, meeting notes, and approved onboarding files.
- It should explain where an answer came from when possible.
- It should say when the source does not include the answer.
- It should avoid guessing deadlines, customer commitments, or policy exceptions.
After Agent Builder creates the draft, review the name and description. The name should tell users what the agent is for, such as “Customer onboarding helper” or “Project handoff assistant.”
Step 2: Tighten the instructions
Open the Configure tab and edit the instructions. This is where you make the agent safer and more useful for Teams users.
Use instructions like these:
- Answer only from the connected team knowledge sources when the question is about the project.
- If the answer is missing, say that the source does not include it.
- For decisions, cite the meeting note, file, or chat context when available.
- Do not invent approval dates, owners, prices, or commitments.
- Suggest the responsible channel or owner when a human decision is needed.
Short, specific instructions beat long policy paragraphs. The agent needs rules it can apply during a normal Teams conversation.
Add Teams knowledge sources
In the Knowledge section, add only the sources needed for the workflow. Microsoft documents support for Microsoft 365 knowledge sources such as SharePoint and OneDrive content, and Agent Builder can also use Teams chat and meeting data where your tenant allows it.
Step 3: Choose the right source type
Use this quick decision table before adding content:
| Source | Use it when | Check before adding |
|---|---|---|
| Teams chats or meetings | The answer lives in recent team discussion or meeting context | The chat or meeting is relevant and not full of unrelated side topics |
| SharePoint or OneDrive files | The team already has approved process documents or templates | The file is current, permissioned correctly, and not a draft |
| Website knowledge | The agent needs a public reference source | The source is authoritative and stable |
If the agent is mostly about documents, a file-first workflow may be better than a chat-first workflow. In that case, a file-scoped agent example can help you decide whether Teams is the right place to expose the agent.
Step 4: Keep knowledge narrow
Do not attach every channel, meeting, and folder just because the agent is for a team. Select the smallest set of sources that can answer the expected questions. This makes results easier to explain and simplifies troubleshooting when the agent gives a weak answer.
If a Teams chat includes confidential side discussion, old decisions, or mixed projects, avoid using it as a source. Create a cleaner SharePoint page or meeting decision log first, then connect that approved source.
Test before sharing in Teams
Use the Try it tab before you send the agent to anyone else. Test the agent like a user would, not like the person who built it.
Step 5: Run a practical test set
Ask at least ten questions:
- Three questions that should be answered from the connected sources.
- Two questions that are related but out of scope.
- Two messy user questions with incomplete wording.
- One question that asks for a deadline or owner.
- One question from a normal user account with typical permissions.
- One question after changing or replacing a source file.
The answer should be useful, bounded, and honest about missing information. If the agent guesses, tighten the instructions. If it answers too narrowly, add or clean the knowledge source rather than making the instructions vague.
Share the agent with Teams users
Once the agent passes testing, share it with the people who should review it first. Microsoft supports sharing agents with specific users, groups, and teams, depending on the agent state and tenant controls.
Step 6: Start with a pilot group
Share with two or three realistic users before a full rollout. Ask them to try real Teams questions from their weekly work. Capture only practical feedback:
- Which answer was missing?
- Which answer used the wrong source?
- Which prompt did users naturally type?
- Which source needs cleanup before launch?
After the pilot, update the instructions, starter prompts, and knowledge. If your organization requires a Teams app package or admin review, follow the approved publishing path before broad deployment.
Troubleshoot common setup problems
If the agent does not appear in Teams, confirm that it was shared or published through the correct route and that the user is in the allowed audience. If the agent appears but cannot answer, check whether the user has access to the connected content.
If the agent answers from the wrong context, remove broad sources and replace them with cleaner files, pages, or meeting notes. If users expect the agent to perform actions, confirm that actions or tools were configured. A knowledge-only agent can answer questions, but it will not complete business processes unless those actions are added and approved.
Common questions
Can I create the agent directly from Teams?
Your visible starting point depends on tenant rollout, licenses, and admin policy. The stable workflow is to create and configure the agent in Microsoft 365 Copilot Agent Builder, then share or publish it for Teams users. Some organizations may route formal Teams deployment through Copilot Studio or an app package.
Can the agent read every Teams chat?
No. Treat Teams chat and meeting knowledge as a scoped source, not unlimited access. The agent should use the sources you connect and the permissions available to the user. Test with a normal user account so you see what the audience will actually receive.
What should I use for starter prompts?
Use prompts that match the agent’s actual job. Good prompts are specific, such as “What changed in the last handoff meeting?” or “Which onboarding file should I read first?” Avoid generic prompts like “What can you do?” because they do not teach users the right workflow.
When should I use Copilot Studio instead?
Use Copilot Studio when the agent needs formal lifecycle management, richer channel publishing, custom actions, admin approval, or broader organizational availability. Use Agent Builder when you need a focused Microsoft 365 Copilot agent for a small team workflow.
Before you hand it over
A good Teams Copilot agent has one job, clean knowledge, clear refusal rules, and a tested sharing path. Build it in that order. Users will trust the agent faster when it gives direct answers, admits missing context, and stays inside the team sources you approved.