Understanding the Main Microsoft Agent Development Models
Copilot Studio, Declarative Agents, SharePoint Copilot Apps, SPFx and SharePoint Agents
Introduction
The Microsoft Copilot ecosystem can initially appear confusing because the word Agent is used in several products and development models. Two solutions can both be called Agents while being created with completely different tools, using different runtimes and being published through different mechanisms.
For a Microsoft 365 developer, particularly someone already familiar with SharePoint Framework, Power Platform and SharePoint Online, the most important question is therefore not simply:
“How do I create an Agent?”
A better question is:
“What type of Agent am I creating, where is it authored, what runtime executes it, what capabilities does it provide, and how is it published?”
This article establishes a mental model for the Agent types we are currently studying.
1. Microsoft 365 Copilot Is the Platform Experience
Before discussing Agents, it is useful to separate Microsoft 365 Copilot from the Agents that extend it.
Microsoft 365 Copilot provides the Microsoft 365 AI and conversational experience. Agents can then specialize or extend that experience.
Conceptually:
Microsoft 365 │ ▼Microsoft 365 Copilot │ ├── Microsoft-provided capabilities │ └── Agents
An Agent can therefore be understood as a specialized capability with a defined purpose, instructions, knowledge and potentially actions.
However, Microsoft provides different development models for creating those Agents.
That is where the distinction becomes important.
2. Copilot Studio Agent — Standard Harness
The first model is the one we have already explored extensively in our Copilot Studio laboratories.
We open:
Microsoft Copilot Studio
and create an Agent.
The Agent can progressively contain capabilities such as:
Instructions → Knowledge → Topics → Tools → Agent flows → Connectors → Triggers → Actions
The architecture is approximately:
User │ ▼Copilot Studio Agent │ ▼Standard harness │ ├── Instructions ├── Knowledge ├── Topics ├── Tools ├── Agent flows ├── Connectors └── Triggers
The Standard harness is therefore associated with the Copilot Studio Agent development/runtime model.
It is particularly appropriate when we want a substantial Agent platform with conversational orchestration, Knowledge, Tools and business-process integration.
For example, we could build a:
Corporate Training Agent
The Agent could answer:
“What is our certification reimbursement policy?”
using SharePoint Knowledge.
Later the same Agent could receive:
“Create a training request for me.”
and invoke a Tool or Agent flow that creates an item in a SharePoint list.
This demonstrates one of our fundamental distinctions:
Knowledge provides information.
Actions/Tools perform operations.
Copilot Studio provides an environment in which both can coexist.
Microsoft documentation:
Microsoft Learn — Copilot Studio harnesses
3. Publishing a Copilot Studio Agent
A Copilot Studio Agent is developed and tested inside Copilot Studio and then published.
Conceptually:
Copilot Studio │ ▼Standard harness Agent │ ▼Test │ ▼Publish │ ▼Channels
Depending on the Agent, licensing and supported configuration, channels allow the Agent experience to be exposed in Microsoft environments such as Microsoft 365 Copilot, Teams or SharePoint.
An important distinction is that publishing a Copilot Studio Agent to SharePoint does not transform the Agent into an SPFx Web Part.
The Agent continues to be a Copilot Studio Agent.
SharePoint is a delivery surface/channel.
Conceptually:
Copilot Studio │ ▼Standard Agent │ ▼Publish │ ▼SharePoint │ ▼User interacts with Agent
Microsoft documentation:
Microsoft Learn — Publish Copilot Studio agents to SharePoint
4. Declarative Agent
The second important model is the Declarative Agent.
This belongs primarily to the Microsoft 365 Copilot extensibility model.
Instead of building an Agent entirely through the visual Copilot Studio authoring environment, we can declaratively describe how Microsoft 365 Copilot should specialize itself for a particular scenario.
A Declarative Agent can define concepts such as:
- purpose;
- Instructions;
- Knowledge;
- conversation starters;
- capabilities;
- Actions.
The fundamental idea is:
Microsoft 365 Copilot +Declarative configuration =Specialized Copilot experience
The Agent uses Microsoft 365 Copilot as its underlying experience while defining a specialized purpose and capabilities.
This is why it is called declarative: we primarily describe what specialization and capabilities the Agent should have rather than implementing an entirely independent AI runtime.
Microsoft documentation:
Microsoft Learn — Declarative Agents for Microsoft 365 Copilot
5. SharePoint Copilot Apps and SPFx
This brings us directly to our current laboratory.
We created an SPFx project in Visual Studio Code.
The project contains files such as:
copilot/ declarativeAgent.json instruction.txt ai-plugin.json manifest.json
and also something similar to:
src/ copilotComponents/ myCopilotApp/ MyCopilotAppCopilotComponent.ts
This is extremely important because our solution combines two architectural elements.
The first is the:
Declarative Agent
The second is the:
SPFx Copilot Component
Conceptually:
Microsoft 365 Copilot │ ▼Declarative Agent │ ├── Instructions ├── Knowledge ├── Actions └── Capabilities │ ▼ Tool │ ▼ SPFx Copilot Component │ ▼ Custom interactive UI
Therefore, what we are currently building can be summarized as:
SPFx + Declarative Agent + Copilot Component = SharePoint Copilot App
Microsoft documentation:
Microsoft Learn — SharePoint Copilot Apps with SPFx
6. SPFx Has a New Role Here
Traditional SPFx development normally follows this mental model:
SharePoint Page │ ▼SPFx Web Part │ ▼React / TypeScript │ ▼Custom UI
With SharePoint Copilot Apps, we are exploring another model:
Microsoft 365 Copilot │ ▼Declarative Agent │ ▼Tool │ ▼SPFx Copilot Component │ ▼Custom UI
That is an important change in how we should think about SPFx.
SPFx is no longer only something that produces Web Parts and Extensions for traditional SharePoint experiences.
It can participate in the Microsoft 365 Copilot extensibility model by providing interactive Copilot Components.
This is precisely the technology we are currently testing.
7. The Copilot Component Workbench
During development we opened the Copilot Component Workbench.
This can initially cause confusion because the Workbench is not equivalent to having a complete conversation with the final Microsoft 365 Copilot Agent.
Its purpose is to allow us to test the Copilot Component during development.
Our current experiment looks approximately like:
Developer │ ▼Copilot Component Workbench │ ▼Tool parameters │ ▼SPFx Copilot Component │ ▼Render UI
For example, we entered:
message = weather
and fired a turn.
That did not mean:
“Ask the AI about the weather.”
We supplied a value to the message property of the component.
Our TypeScript code determines what happens with that property.
This distinction will become important when we start changing the component.
8. SharePoint Agent
There is also a simpler model: the SharePoint Agent.
This is primarily oriented toward creating an Agent grounded in SharePoint content.
Conceptually:
SharePoint │ ▼Site / Library / Documents │ ▼SharePoint Agent │ ▼User asks questions
This can be extremely useful when the problem is essentially:
“I want users to converse with this collection of SharePoint information.”
For example:
HR SharePoint Site │ ├── Vacation Policy ├── Benefits ├── Travel Policy └── Employee Handbook │ ▼ SharePoint Agent
We do not necessarily need SPFx or a sophisticated Copilot Studio architecture for this scenario.
This reinforces another important architectural lesson:
Do not use a more complex Agent architecture when a simpler one satisfies the requirement.
9. A SharePoint Agent Is Not an SPFx Agent
This distinction deserves emphasis.
A SharePoint Agent can use SharePoint content without requiring us to create:
SPFx projectTypeScriptReact.sppkgCopilot Component
The SharePoint content is central to the Agent.
Conversely, our current SharePoint Copilot App laboratory is a development project involving SPFx and a Declarative Agent.
The names are similar, but the development models are different.
10. The Three Models We Need to Remember
For now, we can ignore many other Microsoft AI architectures.
The three most important models for our learning journey are:
| Scenario | Agent | Authoring |
|---|---|---|
| Rich Agent platform | Copilot Studio Standard Agent | Copilot Studio |
| Microsoft 365 Copilot specialization + custom component | Declarative Agent / SharePoint Copilot App | VS Code + SPFx |
| Simple SharePoint-centered Agent | SharePoint Agent | SharePoint |
This gives us a much simpler decision tree.
11. When I Want Copilot Studio
Suppose the requirement is:
“Build an IT support Agent that answers documentation questions, collects information from users, executes troubleshooting workflows, calls APIs, creates SharePoint tickets and potentially triggers business processes.”
Copilot Studio becomes very interesting.
Copilot Studio │ ▼Standard Agent │ ├── Knowledge ├── Topics ├── Variables ├── Tools ├── Agent flows ├── APIs └── Connectors
This is an Agent platform.
12. When I Want a SharePoint Agent
Suppose the requirement is:
“Employees need to ask questions about the HR documents stored in this SharePoint site.”
The architecture could potentially remain:
SharePoint │ ▼HR Documents │ ▼SharePoint Agent
There may be no reason to introduce SPFx, APIs or Power Automate.
This is a Knowledge-oriented scenario.
13. When I Want SPFx + Declarative Agent
Now suppose the requirement is:
“I want a specialized Microsoft 365 Copilot Agent and I also want a custom interactive experience implemented by developers using SPFx.”
Now our current architecture becomes relevant:
VS Code │ ▼SPFx │ ├───────────────┐ ▼ ▼Declarative CopilotAgent Component │ │ └───────┬───────┘ ▼ SharePoint Copilot App │ ▼ Microsoft 365 Copilot
This is exactly the laboratory we are currently performing.
14. Standard Harness Agent Is Not an SPFx Web Part
Another source of confusion is the relationship between Copilot Studio and SharePoint.
A Copilot Studio Agent can be published to SharePoint.
But:
Publishing an Agent to SharePoint does not mean converting it into an SPFx Web Part.
These concepts should remain separate.
Copilot Studio ↓Standard Agent ↓Publish ↓SharePoint
versus:
VS Code ↓SPFx ↓Copilot Component ↓SharePoint Copilot App
They can participate in the same Microsoft 365 ecosystem without being the same technology.
15. The Importance of the Authoring Tool
A useful shortcut is to look at where you are developing.
If we are inside:
Copilot Studio
we are probably studying the Copilot Studio Agent model.
If we are inside:
SharePoint → Create agent
we are studying SharePoint Agents.
If we are inside:
VS Code + SPFx
and the project contains:
declarativeAgent.json
instruction.txt
ai-plugin.json
copilotComponents
we are studying:
SharePoint Copilot Apps + Declarative Agents + SPFx Copilot Components.
This simple observation eliminates much of the naming confusion.
16. Publishing Is Also Different
The development model determines the deployment model.
For a Copilot Studio Agent:
Develop ↓Test in Copilot Studio ↓Publish ↓Configure Channels ↓Users
For our SPFx SharePoint Copilot App:
Develop in VS Code ↓Test Copilot Component ↓Build ↓Package ↓.sppkg ↓SharePoint App Catalog ↓Microsoft 365 Copilot integration
For a SharePoint Agent:
SharePoint Content ↓Create Agent ↓Configure ↓Share ↓Users
The word Agent appears in all three architectures, but their development and deployment lifecycles are not identical.
17. Summary Table
| Question | Copilot Studio Agent | Declarative Agent + SPFx | SharePoint Agent |
|---|---|---|---|
| Main authoring environment | Copilot Studio | VS Code | SharePoint |
| Main Agent model | Standard harness | Declarative Agent | SharePoint-oriented Agent |
| Pro-code required? | No, although extensible | Yes for our SPFx scenario | No |
| SPFx involved? | No | Yes | No |
| Custom TypeScript UI | Not through ordinary SPFx Agent authoring | Copilot Component | No |
| Instructions | Yes | Yes | Yes/configurable behavior |
| Knowledge | Yes | Yes | Primarily SharePoint content |
| Tools/Actions | Yes | Supported according to Declarative Agent capabilities | More constrained scenario |
| Topics | Yes | Not the Copilot Studio Topic model | No Copilot Studio Topic model |
| Agent flows | Yes | Not the native authoring model | No |
| Main development strength | Agent orchestration and business processes | Pro-code Microsoft 365 Copilot extensibility + custom UI | Fast content-centric Agent |
| Publishing model | Copilot Studio Publish + Channels | SPFx/app packaging and deployment | SharePoint sharing/publishing experience |
| Typical developer | Maker / Power Platform / Agent developer | Microsoft 365 / SPFx developer | SharePoint information owner / maker |
18. Where Our Current Laboratory Fits
We can finally locate ourselves precisely.
We are not currently building:
Copilot Studio ↓Standard harness
We are building:
Visual Studio Code ↓ SPFx ↓SharePoint Copilot App │ ├── Declarative Agent │ ├── declarativeAgent.json │ └── instruction.txt │ └── Copilot Component └── TypeScript / UI ↓Microsoft 365 Copilot
The Workbench screenshot from our experiment represents the development/testing portion of the Copilot Component, not the final conversational experience of the Agent.
19. Final Mental Model
The easiest way to remember everything is:
Copilot Studio Agent
“I want to build and orchestrate an Agent.”
SharePoint Agent
“I want an Agent primarily over my SharePoint content.”
Declarative Agent
“I want to specialize Microsoft 365 Copilot for a particular purpose.”
SPFx Copilot Component
“I want to program a custom interactive UI that participates in that Copilot experience.”
And therefore our current experiment is:
“I am using SPFx to build a SharePoint Copilot App containing a Declarative Agent and a custom Copilot Component, which will ultimately participate in the Microsoft 365 Copilot experience.”
That is the sentence worth keeping as the reference for the rest of this laboratory.
Official Microsoft references
Declarative Agents for Microsoft 365 Copilot — Microsoft Learn
SharePoint Copilot Apps with SPFx — Microsoft Learn
Copilot Studio harnesses — Microsoft Learn
Publish a Copilot Studio Agent to SharePoint — Microsoft Learn
