Building Microsoft 365 Copilot Apps from Zero
A Complete Step-by-Step Developer Guide Based on Microsoft Learn
Introduction
Microsoft 365 Copilot introduces a new application model into the Microsoft 365 ecosystem.
For many years, Microsoft 365 developers have built solutions using technologies such as SharePoint Online, SPFx, Microsoft Graph, Teams Apps, Office Add-ins, Power Automate, Power Apps, Azure Functions, REST APIs and custom web applications.
Generative AI and Agents add another architectural layer to this ecosystem.
An enterprise solution can now include an intelligent component capable of understanding natural language, accessing organizational knowledge, reasoning over retrieved information and invoking explicitly defined capabilities.
A simplified architecture can look like:
User
↓
Microsoft 365 Copilot
↓
Agent
↓
Instructions
↓
Knowledge / Actions / Capabilities
↓
Microsoft 365 / Enterprise Systems
↓
Business Result
However, an Agent should not be understood merely as a chatbot.
Microsoft makes an extremely important architectural statement in its documentation:
When you build an Agent, you are also building an app for Microsoft 365.
This means Agent development is connected to the Microsoft 365 application model.
An Agent can therefore involve concepts such as:
- App packages
- App manifests
- Agent manifests
- Icons
- Permissions
- Capabilities
- Deployment
- Distribution
- Organizational administration
- Source control
- CI/CD
- Enterprise governance
This article develops that idea from the beginning.
Instead of immediately building a complex Agent connected to SharePoint, Microsoft Graph, APIs and Power Automate, we will follow the official Microsoft Learn tutorial and progressively understand what happens at each stage.
Our learning methodology will be:
Concept
↓
Architecture
↓
Microsoft Learn
↓
Minimal Implementation
↓
Test
↓
Technical Analysis
↓
Next Capability
1. Official Microsoft Learn Tutorial Used in This Article
The primary tutorial used throughout the first part of this article is:
Tutorial: Create declarative agents by using Microsoft 365 Agents Toolkit
Official Microsoft Learn:
This should be opened while following this article.
The Microsoft tutorial is intentionally small.
It covers four main areas:
- Prerequisites
- Create and provision a declarative Agent
- Test the Agent
- Continue to customization
This simplicity is extremely useful.
Microsoft does not start by connecting Graph, SharePoint, REST APIs, Power Automate or external enterprise systems.
The tutorial first proves the smallest architecture:
Developer
↓
Visual Studio Code
↓
Microsoft 365 Agents Toolkit
↓
Declarative Agent
↓
Microsoft 365 Copilot
↓
User
We will follow exactly this foundation before expanding it.
2. Microsoft 365 Copilot Extensibility
Before opening Visual Studio Code, we need to understand the architecture we are entering.
Microsoft maintains an entire documentation area dedicated to Microsoft 365 Copilot extensibility.
Official documentation:
Microsoft currently organizes Copilot extensibility around several important areas, including:
- Agents
- Copilot connectors
- Plugins and actions
- Microsoft 365 Agents Toolkit
- Microsoft 365 Agents SDK
- Work IQ
- Microsoft 365 Copilot APIs
- Agent management
Therefore, Copilot extensibility is considerably broader than simply creating prompts.
We are extending a Microsoft 365 platform.
3. The First Critical Concept: Agents Are Apps
Before following the tutorial, read this Microsoft article:
Agents are apps for Microsoft 365
Official Microsoft Learn:
This is one of the most important documents for a Microsoft 365 developer learning Agents.
Microsoft explains that Agents participate in the common Microsoft 365 application model.
That means they share concepts such as:
- Manifest schema
- Packaging
- Distribution
- Management
- Icons
- Application configuration
Conceptually:
Agent
is also
Microsoft 365 App
This changes how we should think about Agent development.
We are not simply configuring an AI personality.
We are developing an application component that runs within the Microsoft 365 ecosystem.
4. Microsoft 365 App Package
According to Microsoft’s application model, an Agent package is fundamentally an application package.
Conceptually:
App Package
├── manifest.json
├── declarativeAgent.json
├── color.png
└── outline.png
Additional files can appear depending on the capabilities of the application.
Microsoft documents the package as a ZIP file containing configuration manifests and icons.
Application logic and external data can remain hosted elsewhere and be accessed through HTTPS.
This gives us an important architectural separation:
Microsoft 365 App Package
↓
Describes the application
but
External Service
↓
Implements external runtime/business capability
For developers familiar with Teams Apps, this model should already look somewhat familiar.
5. The App Manifest
One fundamental file is:
manifest.json
The Microsoft 365 app manifest describes application-level information.
Conceptually, it answers questions such as:
What is this application?
What is its name?
Which capabilities does it expose?
Which resources does it require?
Which Agent definition belongs to it?
Which icons represent it?
The manifest belongs to the Microsoft 365 application layer.
We can visualize:
Microsoft 365
↓
App Manifest
↓
Application
↓
Agent Capability
6. The Declarative Agent Manifest
A declarative Agent introduces another configuration layer.
Conceptually:
Microsoft 365 App Manifest
↓
Declarative Agent Manifest
↓
Agent Behavior
This distinction is important.
The application manifest describes the Microsoft 365 application.
The declarative Agent definition describes the Agent.
As our Agent evolves, the Agent definition can describe concepts such as:
Instructions
Knowledge
Conversation starters
Capabilities
Actions
The architecture therefore becomes:
Microsoft 365 App
↓
App Manifest
↓
Declarative Agent
↓
Instructions
↓
Knowledge
↓
Actions
↓
Capabilities
7. What Is a Declarative Agent?
Microsoft describes a declarative Agent as a customized version of Microsoft 365 Copilot.
Rather than creating an entirely independent AI runtime, we declare how Microsoft 365 Copilot should behave for a particular purpose.
Three concepts are especially important:
Instructions
Define how the Agent should behave.
Knowledge
Defines information the Agent can use.
Actions
Define operations the Agent can perform.
This produces one of our most important mental models:
Declarative Agent
=
Microsoft 365 Copilot
Instructions
Knowledge
Actions
This is deliberately simplified, but extremely useful.
8. Knowledge and Action Must Remain Separate
Before proceeding, we need to establish a distinction that will remain important throughout Agent development.
Suppose an employee asks:
“What is our vacation policy?”
The Agent needs information.
This is primarily:
Knowledge
Architecture:
User
↓
Agent
↓
Knowledge
↓
Corporate Policy
↓
Answer
Now consider:
“Create my vacation request.”
The Agent needs to perform an operation.
This is:
Action
Architecture:
User
↓
Agent
↓
Action
↓
Business System
↓
Create Request
These are fundamentally different responsibilities.
A mature Agent architecture must understand the difference between knowing and doing.
9. Ways to Build Declarative Agents
Microsoft currently provides several approaches for building declarative Agents.
Official comparison:
The major options include:
| Tool | Approach | Typical Audience |
|---|---|---|
| Microsoft 365 Agents Toolkit | Pro-code | Developers |
| Copilot Studio | Low-code | Makers and developers |
| Agent Builder | No-code | Business users |
| SharePoint | No-code | SharePoint content scenarios |
These approaches solve different problems.
10. Microsoft 365 Agents Toolkit
Agents Toolkit provides a developer-oriented experience.
It is particularly appropriate when we want:
- Source control
- Pro-code development
- Direct API integration
- CI/CD
- Advanced actions
- Adaptive Cards
- Custom engine Agents
- Microsoft 365 Agents SDK
- Professional development lifecycle
This makes it especially relevant to developers coming from:
SPFx
TypeScript
JavaScript
C#
Microsoft Graph
REST APIs
Teams Apps
Azure development
11. Copilot Studio
Copilot Studio provides a low-code Agent development environment.
It integrates naturally with the Power Platform ecosystem and supports scenarios involving:
- Instructions
- Knowledge
- Tools
- Actions
- Topics
- Power Automate
- Connectors
- Adaptive Cards
- Business logic
- Power Platform ALM
Therefore:
Agents Toolkit does not replace Copilot Studio.
Copilot Studio does not replace Agents Toolkit.
They represent different development approaches.
12. Why We Start with Agents Toolkit
For this particular article, we start with Agents Toolkit because we want to understand:
Agent as application
↓
Project files
↓
Manifest
↓
Agent definition
↓
Provisioning
↓
Microsoft 365
↓
Copilot
This gives us an excellent technical foundation before we return to Copilot Studio.
It also allows us to compare the pro-code and low-code worlds later.
13. Prerequisites from the Microsoft Tutorial
Return to our primary Microsoft tutorial:
Microsoft currently requires:
Visual Studio Code
and
Microsoft 365 Agents Toolkit Visual Studio Code extension
The development environment also needs access to an appropriate Microsoft 365 environment.
The Microsoft tutorial targets users licensed for Microsoft 365 Copilot.
Microsoft also documents Agent scenarios for Microsoft 365 Copilot Chat users, but capabilities can differ.
This is an important architectural distinction:
Development tools
≠
Runtime licensing
≠
User entitlement
We should never assume that because we can develop an Agent, every Microsoft 365 user automatically has access to every capability.
14. Agents Toolkit Version
Microsoft currently states that the screenshots in this tutorial were created using:
Microsoft 365 Agents Toolkit Release 6.0
This detail matters because Microsoft 365 development tooling evolves rapidly.
If your interface differs from the Microsoft Learn screenshots, verify:
- Toolkit version
- Release vs Pre-Release
- Visual Studio Code version
- Tenant capabilities
Do not immediately assume that your environment is wrong.
15. Install Visual Studio Code
Visual Studio Code is available at:
Install and open Visual Studio Code.
If you already use Visual Studio Code for SPFx, TypeScript or other Microsoft 365 development, no additional conceptual introduction is required.
16. Install Microsoft 365 Agents Toolkit
Inside Visual Studio Code open:
Extensions
Search for:
Microsoft 365 Agents Toolkit
Install the Microsoft extension.
After installation, Agents Toolkit becomes part of your Visual Studio Code development environment.
This is our first important transition:
Microsoft 365 Agent development is now integrated into a normal developer IDE.
17. Start the Official Tutorial
Now we begin following Microsoft Learn directly.
Official tutorial:
Microsoft instructs us to open:
Microsoft 365 Agents Toolkit
Then select:
Create a New Agent/App
Notice the wording:
Agent/App.
That wording reinforces the architecture we studied earlier.
The Agent exists within the Microsoft 365 application model.
18. Select Declarative Agent
The next Microsoft Learn step is:
Declarative Agent
Select it.
At this moment we have made an architectural decision.
We are not building a completely independent custom AI engine.
We are extending Microsoft 365 Copilot.
19. Select No Action
Microsoft then instructs us to select:
No Action
This step may appear trivial.
Architecturally, however, it is excellent.
Microsoft is intentionally keeping our first Agent small.
We are creating:
Agent
↓
Instructions
↓
Response
rather than:
Agent
↓
Action
↓
Authentication
↓
REST API
↓
External System
↓
JSON
↓
Response
This reduces the number of variables in the first experiment.
20. Why No Action Is the Correct Starting Point
Suppose our first Agent included:
SharePoint
Graph
REST
Authentication
Power Automate
Knowledge
Actions
If the Agent failed, we would not immediately know whether the problem involved:
Agent definition
Instructions
Authentication
Permissions
API
Tool selection
Knowledge retrieval
External system
By selecting No Action, we isolate the Agent lifecycle itself.
This is excellent experimental design.
21. Select the Project Folder
Microsoft Learn then instructs:
Default folder
You can also choose an appropriate workspace depending on your development practices.
For a production project, I would normally expect this source eventually to live inside a Git repository.
For our laboratory, the default location is sufficient.
22. Application Name
Microsoft asks us to enter:
My Agent
and press Enter.
Again, notice:
Application Name
This reinforces that we are not merely naming a conversation.
We are creating an application artifact.
23. Inspect Before Provisioning
Microsoft Learn moves quickly to Provision.
As developers, however, this is a good moment to stop briefly.
Look at the generated project.
Do not modify anything yet.
Our first question should be:
What did Agents Toolkit create for us?
We should expect to encounter concepts involving:
App package
Manifest
Declarative Agent definition
Icons
Environment configuration
Provisioning configuration
The precise generated structure can evolve with Toolkit versions, so the generated project itself should be treated as the authoritative representation of the version we are currently using.
24. The Generated Project Is Source Code
This is an important conceptual transition.
When using a graphical Agent builder, it can feel as though the Agent exists only inside a cloud configuration interface.
With Agents Toolkit we can think differently:
Repository
↓
Agent Source
↓
Configuration
↓
Manifest
↓
Provision
↓
Microsoft 365
This enables software engineering practices such as:
Git
Code review
Branches
Versioning
CI/CD
Automated validation
Environment management
Deployment pipelines
25. Provision
Now return to the exact Microsoft Learn procedure.
Inside Microsoft 365 Agents Toolkit find:
Lifecycle
Then select:
Provision
Provisioning is a very important concept.
Do not mentally translate Provision into simply:
“Run.”
Provisioning means preparing/configuring the resources necessary for the application in the Microsoft 365 environment.
Conceptually:
Local Project
↓
Agents Toolkit
↓
Provision
↓
Microsoft 365 Environment
↓
Agent becomes available
26. Authentication During Provisioning
During this process you might need to authenticate.
Always verify:
Which Microsoft account?
Which tenant?
Which environment?
Which license?
This becomes particularly important for consultants and developers who have:
Development tenants
Customer tenants
Demo tenants
Personal Microsoft accounts
Multiple Microsoft 365 identities
Provisioning into the wrong tenant is an easy mistake.
27. Provisioning and ALM
Provisioning also introduces our first glimpse of application lifecycle management.
Today:
Developer
↓
Provision
↓
Development Tenant
Later:
Git
↓
Build
↓
DEV
↓
TEST
↓
PROD
↓
Monitoring
Agents should eventually participate in normal enterprise ALM practices.
We will not implement that yet.
For now, simply recognize that Provision belongs to a larger lifecycle.
28. Test the Agent
Microsoft Learn now instructs us to open Microsoft 365 Copilot.
Official application:
Open this application using the same appropriate Microsoft 365 identity.
29. Locate the Conversation Drawer
According to the current tutorial, next to:
New Chat
select the conversation drawer icon.
Then locate:
My Agent
Select the Agent.
This means our local project has now crossed several boundaries:
Visual Studio Code
↓
Agents Toolkit
↓
Provision
↓
Microsoft 365
↓
Microsoft 365 Copilot
↓
My Agent
30. Execute the First Test
Microsoft Learn asks us to send a question to the Agent.
The tutorial expects the Agent to respond with a confirmation indicating that Microsoft 365 Agents Toolkit was used to create the declarative Agent.
The precise sentence is less important architecturally than the proof.
We have now demonstrated:
User Prompt
↓
Microsoft 365 Copilot
↓
Correct Declarative Agent
↓
Agent Instructions
↓
Generated Response
31. What Have We Actually Proven?
This tiny laboratory proves considerably more than it initially appears.
We have established:
Visual Studio Code development
↓
Agents Toolkit project
↓
Microsoft 365 App Model
↓
Declarative Agent
↓
Provisioning
↓
Microsoft 365 Tenant
↓
Microsoft 365 Copilot
↓
End-user interaction
That is our first complete vertical slice.
32. What We Have NOT Proven
Equally important is understanding what we have not yet tested.
We have not tested:
SharePoint Knowledge
Retrieval
Grounding
Power Automate
Actions
Microsoft Graph
REST APIs
Authentication to external systems
MCP
Adaptive Cards
Complex Topics
Dataverse
Autonomous Agents
This is intentional.
Our first laboratory proves only the basic Agent lifecycle.
33. The Next Microsoft Learn Step
At the end of the tutorial Microsoft points toward customization of:
Instructions
and:
Conversation Starters
This is exactly where our second laboratory should begin.
But Microsoft provides another tutorial that goes much deeper.
34. The Second Official Tutorial: TypeSpec
Our next major reference is:
Create declarative agents using Microsoft 365 Agents Toolkit and TypeSpec
Official Microsoft Learn:
This is an extremely useful tutorial because it progressively extends the Agent.
35. What the TypeSpec Tutorial Covers
The current Microsoft tutorial progresses through capabilities including:
Create declarative Agent
↓
Instructions
↓
Conversation Starters
↓
Web Content
↓
OneDrive / SharePoint Content
↓
Teams Messages
↓
People Knowledge
↓
Email Knowledge
↓
Image Generator
↓
Code Interpreter
↓
Copilot Connectors
This is almost a small course in declarative Agent architecture.
36. Create the TypeSpec Agent
The beginning is similar.
Open:
Microsoft 365 Agents Toolkit
Select:
Create a New Agent/App
Then:
Declarative Agent
But this time select:
Start with TypeSpec for Microsoft 365 Copilot
Then:
Default folder
Application Name:
My Agent
Finally:
Lifecycle → Provision
Again, test using:
37. Why TypeSpec Matters
TypeSpec gives us a more declarative, developer-oriented way of describing Agent capabilities.
Instead of thinking only in terms of UI configuration, we increasingly think:
Agent Definition
↓
Source
↓
Version Control
↓
Provision
↓
Microsoft 365
This is extremely valuable for enterprise development.
38. TypeSpec Instructions
The Microsoft tutorial then introduces:
@instructions
Conceptually:
@instructions
↓
Agent Manifest
↓
Instructions property
↓
Agent behavior
Microsoft explicitly explains that the contents of this decorator are inserted into the instructions property of the Agent manifest during provisioning.
This is extremely useful because we can now see the connection between:
Source definition
and:
Generated Agent manifest.
39. Instructions Are Behavior
This is the correct moment to reinforce:
Instructions are not Knowledge.
Instructions answer:
“How should the Agent behave?”
Examples:
Be concise.
Use technical language.
Answer as a SharePoint architect.
Ask for clarification when information is ambiguous.
Do not invent corporate policies.
Knowledge answers:
“What information is available?”
Examples:
SharePoint documents.
Policies.
Technical manuals.
Microsoft 365 organizational information.
40. Reprovision After Changing Instructions
After changing the instructions, Microsoft tells us to select:
Provision
again.
Then reload Microsoft 365 Copilot.
This establishes a development cycle:
Edit
↓
Provision
↓
Reload
↓
Test
↓
Observe
↓
Edit again
This is our first real Agent development loop.
41. Conversation Starters
The TypeSpec tutorial next introduces:
@conversationStarter
Conversation Starters are suggestions shown to users to help them understand what they can ask.
They serve an important UX purpose.
An Agent with no guidance forces users to discover its capabilities themselves.
Conversation Starters communicate:
What is this Agent for?
What can I ask?
What kinds of requests are expected?
For example:
“Search our SharePoint documentation.”
“Explain our development standards.”
“Find the vacation policy.”
“Summarize the onboarding process.”
42. Conversation Starter Architecture
Conceptually:
Agent Purpose
↓
Conversation Starters
↓
User understands capability
↓
Better Prompt
↓
Better Agent interaction
This demonstrates that Agent engineering is not only prompt engineering.
It also involves interaction design.
43. Knowledge Enters the Architecture
After Instructions and Conversation Starters, the tutorial begins adding Knowledge capabilities.
This is where the Agent becomes substantially more interesting.
The architecture evolves from:
User
↓
Agent
↓
Instructions
↓
Response
to:
User
↓
Agent
↓
Instructions
↓
Knowledge
↓
Retrieval
↓
Relevant Context
↓
Response
44. Microsoft Knowledge Tutorial
Microsoft also maintains a dedicated tutorial:
Add knowledge sources to a declarative agent created with Microsoft 365 Agents Toolkit
Official Microsoft Learn:
Microsoft currently covers knowledge sources involving:
Web
SharePoint
Teams
People
Microsoft 365 Copilot connectors
This is extremely relevant for enterprise Agents.
45. SharePoint Becomes Our Primary Knowledge Source
For our own learning path, SharePoint should become the primary enterprise scenario.
Consider a library:
Corporate Policies
containing:
Vacation Policy
Remote Work Policy
Information Security Policy
Travel Policy
Expense Policy
The architecture becomes:
Employee
↓
Microsoft 365 Copilot
↓
Corporate Policy Agent
↓
SharePoint Knowledge
↓
Retrieval
↓
Relevant Document
↓
Grounding
↓
Answer
This is our first truly enterprise-oriented Agent architecture.
46. Knowledge Is Not Simply File Access
It is important not to think:
User asks question
↓
Agent opens entire SharePoint library
↓
Agent reads everything
↓
Agent answers
A better conceptual model is:
User Prompt
↓
Agent
↓
Knowledge Source
↓
Retrieval
↓
Relevant Content
↓
Grounding Context
↓
Generative Response
This distinction becomes critical when we study RAG.
47. SharePoint Permissions Matter
Connecting SharePoint does not mean every Agent user should automatically access every connected document.
Identity and authorization remain fundamental.
Our security questions must include:
Who is asking?
Which SharePoint content can this user access?
Which identity is used?
Which Knowledge is eligible?
Could restricted information be surfaced?
How are permissions respected?
Knowledge architecture is also security architecture.
48. Adding Actions
Once Knowledge is understood, we can move to Actions.
Microsoft maintains another progression for adding capabilities and custom actions.
Official documentation:
Capabilities can include built-in functionality and custom actions.
At this point our architecture changes significantly.
49. From Knowing to Doing
Before:
User
↓
Agent
↓
Knowledge
↓
Answer
After:
User
↓
Agent
↓
Action
↓
External Capability
↓
Result
↓
Agent
↓
User
This is one of the largest conceptual transitions in Agent development.
50. Example with SharePoint
Suppose the user asks:
“What is the equipment request policy?”
The Agent uses:
Knowledge
Now the user asks:
“Create an equipment request for me.”
The Agent needs:
Action
A possible architecture becomes:
Agent
↓
Action
↓
Power Automate
↓
SharePoint List
↓
Create Item
↓
Return ID
↓
Agent
↓
User
51. Why Power Automate Is Important
Power Automate gives us a deterministic execution layer.
This is useful because the LLM should not necessarily implement business rules.
For example:
If RequestAmount > 10000
then
ManagerApproval = Required
This is deterministic logic.
Power Automate can execute it predictably.
The Agent can concentrate on:
Understanding natural language
Collecting information
Explaining results
Summarizing content
Selecting appropriate capabilities
52. Later: API Actions
Eventually we can expose APIs.
Architecture:
User
↓
Agent
↓
API Action
↓
HTTP
↓
External API
↓
JSON
↓
Agent
↓
Natural Language Response
This introduces:
OpenAPI
GET
POST
Parameters
Headers
Authentication
Schemas
HTTP status codes
Error handling
External security boundaries
53. Later: Microsoft Graph
Microsoft Graph should not automatically be our first integration.
Before Graph, ask whether the requirement can be solved using:
Native Agent capability
SharePoint
Power Automate
Connector
Copilot capability
API Action
If Graph becomes necessary, then we study:
Endpoint
HTTP method
Request
Response
Scopes
Authentication
Delegated permissions
Application permissions
Consent
Least privilege
54. Copilot Studio Track
There is another official Microsoft course that we should run in parallel later:
Build your first declarative agent for Microsoft 365 Copilot by using Copilot Studio
Official Microsoft Learn:
The current module contains nine units and takes approximately one hour.
55. What the Copilot Studio Course Teaches
Microsoft currently structures the module approximately as:
Introduction
↓
Create a Declarative Agent
↓
Exercise: Create Declarative Agent
↓
Add Custom Knowledge
↓
Exercise: Add Custom Knowledge
↓
Add Suggested Prompts
↓
Exercise: Add Suggested Prompts
↓
Assessment
↓
Summary
This gives us an excellent comparison with Agents Toolkit.
56. Pro-Code vs Low-Code
We can therefore run the same conceptual experiment twice.
Architecture:
Declarative Agent
Implementation A:
Microsoft 365 Agents Toolkit
Implementation B:
Copilot Studio
Then compare.
| Aspect | Agents Toolkit | Copilot Studio |
|---|---|---|
| Approach | Pro-code | Low-code |
| IDE | Visual Studio Code | Browser |
| Source control | Strong | Power Platform oriented |
| Direct file control | Strong | Abstracted |
| Power Platform | Less central | Native |
| APIs | Strong | Supported |
| Business automation | Possible | Strong integration |
| CI/CD | Developer-oriented | Power Platform ALM |
| Target user | Developer | Maker / Developer |
This comparison will teach us considerably more than learning either tool in isolation.
57. Our Progressive Laboratory Plan
Instead of consuming all Microsoft documentation at once, we can transform it into controlled laboratories:
| Lab | Experiment |
|---|---|
| 1 | Create Declarative Agent |
| 2 | Inspect generated project |
| 3 | Understand App Manifest |
| 4 | Understand Declarative Agent Manifest |
| 5 | Modify Instructions |
| 6 | Add Conversation Starters |
| 7 | Create TypeSpec Agent |
| 8 | Add Web Knowledge |
| 9 | Add SharePoint Knowledge |
| 10 | Study Retrieval |
| 11 | Study Grounding |
| 12 | Test missing Knowledge |
| 13 | Test SharePoint permissions |
| 14 | Add first Action |
| 15 | Connect Power Automate |
| 16 | Create SharePoint item |
| 17 | Return Action output |
| 18 | Add API |
| 19 | Study OpenAPI |
| 20 | Add authentication |
| 21 | Introduce Microsoft Graph |
| 22 | Study permissions |
| 23 | Package Agent |
| 24 | Publish Agent |
| 25 | Study ALM |
Every laboratory should change as few architectural variables as possible.
58. Our First Real Enterprise Agent
After completing the foundation, a good project would be:
SharePoint Technical Documentation Agent
Purpose:
Allow employees and developers to query approved SharePoint technical documentation.
Architecture:
User
↓
Microsoft 365 Copilot
↓
SharePoint Technical Agent
↓
Instructions
↓
SharePoint Knowledge
↓
Retrieval
↓
Grounding
↓
Answer
No Action initially.
No Power Automate.
No Graph.
No API.
This keeps the first enterprise Agent atomic.
59. Second Version
Then:
SharePoint Technical Agent V2
adds:
Action
Architecture:
User
↓
Agent
↓
Knowledge
↓
Technical Guidance
and optionally:
Agent
↓
Action
↓
Power Automate
↓
SharePoint List
↓
Create Support Request
Now the Agent can both:
Know
and:
Do
60. Third Version
Then we introduce an API.
User
↓
Agent
↓
API Action
↓
Enterprise API
↓
Structured JSON
↓
Agent
↓
Response
This teaches us how generative reasoning interacts with deterministic external systems.
61. Fourth Version
Only later do we introduce Graph when a requirement actually justifies it.
For example:
Agent
↓
Microsoft Graph
↓
Microsoft 365 Resource
↓
Structured Result
↓
Agent
At that point we must explicitly study Microsoft Entra ID and permissions.
62. Security Must Follow Every Laboratory
Security is not Lab 25.
It starts with Lab 1.
Every time we add something, ask:
Knowledge
Who can read it?
SharePoint
Which permissions apply?
Action
Who executes it?
Power Automate
Which connection executes the Flow?
API
Which credential authenticates?
Graph
Which scopes exist?
Agent
Who can use it?
Publication
Who receives it?
Security should run horizontally through the entire learning path.
63. The Final Architecture
Eventually, after many laboratories, we should understand an architecture like:
Microsoft 365 User
↓
Microsoft 365 Copilot
↓
Declarative Agent
↓
Instructions
↓
Orchestration
↓
Available Capabilities
↓
┌─────────────────────────────┐
│ Knowledge │
│ │
│ SharePoint │
│ Web │
│ Teams │
│ Email │
│ People │
│ Copilot Connectors │
└─────────────────────────────┘
↓
Retrieval
↓
Grounding
↓
LLM
↓
┌─────────────────────────────┐
│ Actions │
│ │
│ Power Automate │
│ REST APIs │
│ MCP │
│ Microsoft Graph │
│ Enterprise Systems │
└─────────────────────────────┘
↓
Business Process
↓
Business Result
64. Official Microsoft Learn Study Path
Keep these pages as the core documentation for this learning track.
1 — Microsoft 365 Copilot Extensibility
Use this as the main documentation portal.
2 — Agents Are Apps for Microsoft 365
Read this before developing Agents.
It explains:
App package
App icons
App manifest
Declarative Agent manifest
API plugin manifest
3 — Choose the Right Agent Development Tool
Use this to understand:
Agents Toolkit
Copilot Studio
Agent Builder
SharePoint
4 — Create a Declarative Agent with Agents Toolkit
This is the primary tutorial for our first laboratory.
Follow:
Visual Studio Code
→ Microsoft 365 Agents Toolkit
→ Create a New Agent/App
→ Declarative Agent
→ No Action
→ Default folder
→ My Agent
→ Lifecycle
→ Provision
→ Microsoft 365 Copilot
→ Test
5 — Build Declarative Agents with TypeSpec
This becomes our second major tutorial.
It expands the Agent with:
Instructions
Conversation Starters
Web
SharePoint
OneDrive
Teams
People
Image Generator
Code Interpreter
Copilot Connectors
6 — Add Knowledge Sources
This becomes extremely important when we move into:
SharePoint
Retrieval
Grounding
Enterprise Knowledge
7 — Add Capabilities and Actions
This introduces the transition from:
Knowledge
to:
Action
8 — Copilot Studio Declarative Agent Course
We will use this to reproduce some of the same architectural concepts using the low-code development model.
65. The Most Important Lesson
The first Agent we build will be almost useless from a business perspective.
That is intentional.
Its purpose is not to solve a large enterprise problem.
Its purpose is to prove:
Visual Studio Code
↓
Agents Toolkit
↓
Microsoft 365 App
↓
Declarative Agent
↓
Provision
↓
Microsoft 365 Copilot
↓
User
Once that chain works and we understand it, we add:
Instructions.
Then:
Conversation Starters.
Then:
Knowledge.
Then:
SharePoint.
Then:
Retrieval.
Then:
Grounding.
Then:
Actions.
Then:
Power Automate.
Then:
REST APIs.
Then:
Authentication.
Then, only where justified:
Microsoft Graph.
Conclusion
Microsoft 365 Copilot Agent development represents much more than configuring a chatbot.
An Agent participates in the Microsoft 365 application model.
It can have an application package.
It has manifests.
It has identity and configuration.
It can expose specialized Instructions.
It can consume enterprise Knowledge.
It can use SharePoint.
It can retrieve and ground information.
It can expose Actions.
It can interact with Power Automate.
It can integrate with REST APIs.
It can eventually interact with Microsoft Graph and other enterprise platforms.
And all these capabilities must operate inside security, identity, permission, governance and lifecycle boundaries.
The correct learning strategy is therefore not to begin by creating the most sophisticated Agent possible.
The correct strategy is:
Create the smallest Agent.
Understand what Agents Toolkit generated.
Provision it.
Test it.
Change one thing.
Test again.
Understand Instructions.
Introduce Knowledge.
Understand Retrieval.
Understand Grounding.
Connect SharePoint.
Test permissions.
Only then introduce Actions.
Only then introduce external systems.
This progression transforms Agent development from experimentation with generative AI into disciplined Microsoft 365 solution architecture.
And the first practical milestone is intentionally small:
Visual Studio Code → Microsoft 365 Agents Toolkit → Declarative Agent → No Action → Provision → Microsoft 365 Copilot → successful response.
Once that works, we stop.
Then we inspect exactly what Agents Toolkit generated before adding the next capability.
