Understanding Agents in Microsoft Copilot Studio
Introduction
Agents are one of the fundamental building blocks of Microsoft Copilot Studio.
An Agent is more than a traditional chatbot. It can receive a user request, interpret context, follow instructions, use organizational knowledge, select available tools, and perform actions.
In the current Microsoft Copilot Studio architecture, it is also important to understand that not every Agent operates in exactly the same way. Microsoft provides different harnesses, and the selected harness influences how the Agent reasons and executes work.
This article focuses primarily on Agents powered by the GitHub Copilot harness, while also explaining where the standard harness differs.
What Is an Agent?
A useful conceptual definition is:
An Agent is an AI-powered component designed to understand requests and work toward a defined objective using the capabilities made available to it.
In Copilot Studio, an Agent can be configured with several components, including:
- Instructions
- Knowledge
- Tools
- Skills
- Connected agents
- Models
- Memory
These components give the Agent context and capabilities.
A simplified architecture is:
User
↓
Agent
↓
Instructions + Context
↓
Knowledge / Tools / Skills / Connected Agents
↓
Reasoning
↓
Response or Action
This is significantly different from thinking of the Agent as a collection of predefined questions and answers.
The Agent Has a Purpose
The first architectural decision should not be which Tool, Flow, Connector, or API to add.
The first question should be:
What is this Agent responsible for?
For example, consider an Agent named:
SharePoint Policy Assistant
Its responsibility might be:
Help employees find information from approved corporate policy documents stored in SharePoint.
That is intentionally narrow.
It does not need to create requests, send emails, update SharePoint lists, call Microsoft Graph, or perform approvals yet.
This follows an important learning and architecture principle:
Start with an atomic Agent.
Give the Agent one clear responsibility before expanding its capabilities.
Creating an Agent
In the current Copilot Studio experience for the GitHub Copilot harness, Microsoft documents a straightforward creation process.
From the Copilot Studio Home page, you can select the Agent tile.
Alternatively:
Agents → New agent
The Agent then opens in the Agent designer.
At this stage, some fundamental properties can be configured, including:
- Name
- Primary language
- Solution
- Schema name
- Instructions
The Agent can then be saved and progressively expanded.
Name
The Agent’s name should communicate its responsibility.
For example:
SharePoint Policy Assistant
is preferable to something generic such as:
Corporate AI
The first name used before saving is also important technically. Microsoft documents that the last Agent name entered before the first save determines its schema name.
After that, the schema name becomes read-only.
This is particularly relevant when thinking about Solutions and ALM.
Instructions
Instructions describe how the Agent should behave.
They can define elements such as:
- role;
- behavior;
- tone;
- rules;
- restrictions;
- expected approach.
For example:
Answer questions about corporate policies using the knowledge available to you. Keep responses concise and do not invent policy information.
Instructions should describe behavior rather than contain the entire enterprise knowledge base.
A useful conceptual distinction is:
Instructions = How the Agent should behave
while:
Knowledge = Information the Agent can use
We will study Instructions separately because they are important enough to deserve their own topic.
Knowledge
Knowledge provides information the Agent can access when answering questions.
For our SharePoint-focused scenario, this becomes particularly important.
Conceptually:
SharePoint
↓
Corporate Documents
↓
Knowledge Source
↓
Agent
↓
Grounded Answer
Knowledge can eventually include corporate policies, technical documentation, training material, procedures, and other organizational information.
But Knowledge is not the Agent itself.
It is one of the resources available to the Agent.
Tools
Tools give the Agent external capabilities that it can invoke.
This introduces one of the most important distinctions in our entire Copilot Studio learning path.
Consider:
What is our vacation policy?
The Agent needs Knowledge.
Now consider:
Create my vacation request.
The Agent needs to do something.
That requires some form of Tool or Action.
Therefore:
Knowledge = know something
Tool = do something
Microsoft currently describes Tools as external capabilities an Agent can invoke during a conversation.
Later, Tools can connect our Agents with business operations and enterprise systems.
Skills
Agents powered by the GitHub Copilot harness can also use Skills.
Microsoft describes Skills as reusable capabilities that extend what an Agent can do.
This introduces another architectural building block beyond Knowledge and Tools.
We do not need Skills for our first Agent.
The important point at this stage is simply understanding that Copilot Studio Agents can progressively gain additional capabilities.
Connected Agents
Another important capability is Connected agents.
An Agent can invoke another Agent during a conversation.
Conceptually:
Primary Agent
↓
Specialized Agent A
or
Specialized Agent B
This enables modular architectures where responsibilities can be distributed among specialized Agents.
This aligns very well with our concept of atomic Agents.
Instead of immediately building one enormous Agent responsible for everything in the organization, specialized Agents can potentially collaborate.
We will not introduce this complexity into our initial labs, but it is an important architectural capability to remember.
Model
Copilot Studio also allows the model used by an Agent to be configured.
The model is an important part of the Agent’s reasoning capability, but the model alone does not define the Agent.
A useful mental model is:
Agent ≠ LLM
Instead:
Agent = Model + Instructions + Context + Capabilities + Orchestration
The language model provides reasoning and language capabilities, while the Agent architecture determines what information and capabilities are available to that reasoning process.
Memory
Microsoft’s current GitHub Copilot harness experience also provides configuration for Memory.
Memory can allow information to persist and influence subsequent interactions where appropriate.
However, Memory introduces additional considerations around:
- user context;
- privacy;
- data handling;
- security;
- expected behavior.
For that reason, Memory should not simply be enabled without understanding its implications.
We will study it separately later.
Agent Reasoning
The most important conceptual change from traditional chatbot development is reasoning.
Traditional conversational systems frequently follow explicitly designed paths:
Question
↓
Intent
↓
Predefined conversation
↓
Response
Modern Agents can operate differently.
With a reasoning-oriented Agent, the architecture becomes closer to:
User Goal
↓
Agent interprets the request
↓
Agent considers Instructions and context
↓
Agent determines which available capability is appropriate
↓
Agent executes steps
↓
Agent produces an outcome
This makes Agents more flexible, but also creates new architectural responsibilities.
We need to carefully control:
- available Knowledge;
- Instructions;
- Tools;
- permissions;
- data access;
- evaluation;
- security.
Greater autonomy requires stronger governance.
GitHub Copilot Harness vs Standard Harness
This distinction is now essential when learning Copilot Studio.
Agents powered by the GitHub Copilot harness use natural-language Instructions, Knowledge, Tools, and other components to reason over context and take action.
The standard harness supports a more structured model and includes capabilities such as Topics and the established Copilot Studio conversational architecture.
Therefore, documentation must always be read with the harness in mind.
An article describing the GitHub Copilot harness should not automatically be assumed to describe the standard harness, and vice versa.
This is especially important because the user interfaces and available capabilities can differ.
Agent Lifecycle
Creating an Agent is only the beginning.
A simplified Agent lifecycle is:
Create
↓
Configure Instructions
↓
Add Knowledge
↓
Add capabilities when required
↓
Test
↓
Evaluate
↓
Share / Publish
↓
Monitor
↓
Improve
Microsoft’s current documentation explicitly points makers from Agent creation toward testing, evaluation, sharing, publishing, and monitoring.
This matters for enterprise architecture.
A production Agent is not finished simply because it produces a correct answer in the test pane.
Agents and SharePoint
For our learning journey, SharePoint Online will be the primary enterprise scenario.
Our first architecture can remain extremely small:
Employee
↓
SharePoint Policy Assistant
↓
Instructions
↓
SharePoint Knowledge
↓
Answer
Notice what is deliberately absent:
- Power Automate
- Microsoft Graph
- Dataverse
- Custom APIs
- Custom Connectors
- Complex Actions
We do not need them yet.
Our initial goal is understanding the Agent itself.
Later: Adding Actions
After we understand Knowledge-based Agents, we can extend the architecture.
For example:
Employee
↓
Agent
↓
Knowledge
↓
Reasoning
↓
Tool
↓
Flow
↓
SharePoint List
Now the Agent is no longer only answering questions.
It can participate in a business process.
For example:
Create an IT support request for me.
The Agent could collect the required information and invoke a Tool that creates the request.
This is where Agent architecture starts becoming particularly powerful for Microsoft 365 business solutions.
Security
Security must be considered from the beginning.
Adding a data source or Tool to an Agent does not mean that every user should automatically have access to everything behind that capability.
For every capability we add, we should ask:
Who is the user?
What can the user access?
What can the Agent access?
Which identity executes an Action?
Which permissions are used?
Could this expose information the user should not see?
These questions become increasingly important as we move from Knowledge-only Agents toward Actions and external integrations.
When Not to Use an Agent
Agents are not automatically the best solution for every business requirement.
If a requirement is deterministic, simple, and already solved effectively by technologies such as:
- SharePoint;
- Power Automate;
- Power Apps;
- SPFx;
- traditional applications;
adding an Agent might introduce unnecessary complexity, cost, and unpredictability.
The architectural question should therefore never be:
How can I solve this with an Agent?
It should be:
Is an Agent appropriate for this problem?
That distinction will remain important throughout our learning journey.
Our Current Mental Model
At this stage, we can simplify everything to:
Agent
= an AI-powered component with a defined purpose
- Instructions that guide its behavior
- Knowledge that provides information
- Tools that provide capabilities
- other optional components such as Skills, Connected Agents, Models, and Memory
The Agent reasons over the available context and capabilities to help achieve its objective.
We do not need to master all these components simultaneously.
We will isolate them and learn them one at a time.
Recommended Next Step
Now that we understand the basic concept of an Agent, the next component to isolate is:
Instructions
Before giving our Agent SharePoint Knowledge or Actions, we should understand how Instructions influence its behavior.
Our progression therefore becomes:
Agent
→ Instructions
→ Knowledge
→ Grounding and Retrieval
→ Testing
→ Tools
→ Actions / Flows
→ SharePoint business processes
This gives us a controlled path from a simple Agent toward a real enterprise solution.
Official Microsoft Learn Resources
Create a new agent — GitHub Copilot harness
Microsoft Copilot Studio documentation
Quickstart: Create and deploy an agent with the standard harness
Write agent instructions
edvaldo b. guimarães filho 