Copilot Developer Camp is a lab site, not a framework you install

A workshop hosted in a repository

The README describes the purpose plainly: the repo hosts a virtual workshop for developers who want to build agents and connectors for Microsoft 365 Copilot. The published entry point is a short link, aka.ms/copilotdevcamp, and the rendered content lives under microsoft.github.io/copilot-camp.

That distinction matters. This is a documentation and training project, not a library, and the source tree confirms it. The top-level entries are docs, scripts, src, an archive directory, mkdocs.yml, requirements.txt, global.css, and the usual community files such as CODE_OF_CONDUCT.md, SECURITY.md and SUPPORT.md. There is no published package, no CLI and no service to run.

The content is organised as learning paths chosen by role and scenario rather than as one linear course. The Extend Microsoft 365 Copilot path covers declarative agents, where you define instructions, knowledge sources and actions and Copilot handles orchestration and reasoning. The Build Custom Engine Agents path covers the case where you want full control over the foundation model, the orchestrator and the security stack. Two more areas are listed: Copilot Cowork extensibility, which is described as an orchestrator that goes beyond chat to run multi-step, cross-app workflows across Microsoft 365, and SharePoint agents and Copilot Apps for grounding agents in SharePoint content.

For a reader, the practical value is the sequence and the specificity. The path tells you which bundle matches which problem, and it tells you what you are expected to have built before you start.

Five bundles, from MCP server to enterprise connectors

The declarative agent path is organised around an on-ramp that the README marks as required: start with E1A, which is Agent Builder and no-code, or E1B, which is Agents Toolkit and pro-code, then complete the prerequisites before choosing a bundle.

Bundle A is the MCP Foundation, and its stated output is a built and secured MCP server using OAuth 2.0 and Entra ID for secured MCP tools with least-privilege access. Bundle B is Multi-Agent Workflows, about orchestrating multiple agents with coordinated flows and role-based handoffs. Bundle C is MCP App, which adds a rich interactive UI on top of MCP using React and Fluent UI widgets, and the note in the table says these widgets are portable across MCP hosts. Bundle D is an API-Based Agent, where the deliverable is an API plugin generated from an OpenAPI specification, with authentication and real external operations. Bundle E is Copilot Connectors, aimed at enterprise data grounding, with responses anchored in organizational data.

Read as a set, the bundles cover three different ways to give an agent something to work with. Bundle A and Bundle C extend the agent through the Model Context Protocol, one supplying tools and the other supplying a user interface. Bundle D does the same through a plugin built from an OpenAPI document, which is the conventional path when an API already exists and is described. Bundle E is different again, since a connector grounds the agent in organizational data rather than exposing an action to call.

The ordering matters too. MCP Foundation comes first because the later bundles assume the security model it establishes, with OAuth 2.0 and Entra ID providing the least-privilege access that a multi-agent system then inherits.

Two C# stacks for the custom engine route

The custom engine path is where a developer stops delegating orchestration to Copilot and takes responsibility for the model, the orchestrator and the security stack. The README offers two stacks, both in C#, and both with their own lab page.

The first is the M365 Agents SDK combined with Semantic Kernel. The description puts the starting point in Microsoft Foundry, then describes building with the Agents SDK and Semantic Kernel for multi-step reasoning across Teams and Copilot Chat. The emphasis is on multi-step reasoning that spans the surfaces a Microsoft 365 user already works in.

The second is Agent Framework, where the stated deliverable is a production-ready insurance claims agent built from scratch, with document search, vision analysis and authentication. That is a complete domain scenario rather than a mechanism lesson, and it means you finish the path with an application you could show rather than a mechanism you could describe.

The choice between them is a question of starting conditions. The SDK route assumes Microsoft Foundry as the place where the work begins, while the Agent Framework route is framed as building from the ground up with a specific business scenario attached. Both paths share the same drawback, which is that the resulting agent is tied to the Microsoft service surface rather than being a portable program.

Running the page source locally with MkDocs

The documentation is built with MkDocs, and the repository keeps the dependencies for that in requirements.txt. The file is small. It lists the MkDocs plugins, then the core dependencies for a translation script, then the packages for the typo checker:

mkdocs-material
mkdocs-static-i18n[material]
python-dotenv
openai
codespell
pyspellchecker

The comment in the file points to the install command, and the repository ships a checker script for validating Markdown pages. Running it locally on a single page looks like this:

python -m pip install -r requirements.txt
python scripts/check_md_typos.py docs/pages/extend-m365-copilot/index.md

The first line installs the dependencies from the repository file, and the second runs the typo checker against one Markdown file, which is described as a quick local validation while editing pages. The script also accepts optional flags. There is a --fix flag to apply auto-corrections where possible, an --ignore-words-file flag that loads ignored terms from a text file with one word per line, an --ignore-words-list flag for extra ignored words given ad hoc, and a --known-typos-only flag that restricts it to the codespell built-in dictionary. The same call with a custom ignore file is:

python scripts/check_md_typos.py docs/pages/extend-m365-copilot/index.md --ignore-words-file scripts/typo-ignore-words.txt

Two things to note. The script checks Markdown pages only, so it is a linting aid for the documentation and does nothing for the C# sample code in the labs. And python-dotenv with openai in the same dependency file points at a translation script that reaches a model API, which means running the full tooling chain is likely to need credentials and network access that the typo check itself does not.

Where the repository shows its seams

A training repository ages in a particular way, and the layout makes that visible. The archive directory at the top level implies that earlier material is retained rather than deleted, which is useful for reading but means a search can land on a page for a lab that no longer reflects the current tooling. The docs directory holds the pages that mkdocs.yml renders, and src sits alongside it as a separate place for code that accompanies the labs.

The project publishes no GitHub releases, and there is no version file that a consumer could pin. Everything is served from the main branch. That is normal for a documentation site that is updated as the Microsoft 365 Copilot surface changes, and it is exactly why a lab should be read as guidance for a point in time rather than as a stable interface.

There is also a feedback loop built into the project. The README asks users to test the labs and report through the issues list, points to a discussions thread for community conversation, and links an on-demand video playlist for the camp. A developer forum and an Azure AI Foundry Discord are listed as places to take questions about building AI applications.

The seams to watch are the external ones. Every lab runs against a Microsoft 365 tenant, the Foundry tooling and the Agent Builder or Agents Toolkit, and the README points to short aka.ms links and to hosted documentation rather than to self-hosted steps. A team without those tenants cannot complete the labs, and the repository does not offer an offline route.

MIT code, a separate CLA and trademark limits

The repository is MIT licensed, with the licence in a LICENSE file at the top level. Contributors, however, are asked to sign a Contributor License Agreement, and the README explains the mechanics: a CLA bot determines on each pull request whether a CLA is needed and decorates the pull request accordingly, and a developer only has to do this once across the repositories that use the agreement. So the MIT licence covers the published content, while the process for adding to it runs through a separate agreement.

The trademark section is the part most people skim and most people should not. The project may contain trademarks or logos for projects, products or services, use of Microsoft trademarks or logos is subject to Microsoft's Trademark and Brand Guidelines, and use of them in modified versions must not cause confusion or imply Microsoft sponsorship. Third-party trademarks remain subject to their own owners' policies. If you fork this content into internal training material, that paragraph is the part that constrains what you may do with the branding, not the MIT licence.

The project has adopted the Microsoft Open Source Code of Conduct, with a link to its FAQ and a contact address for questions about the project itself. There is no release history to track and no changelog to read, but the last push to the repository was on 2026-10-18, so the labs are being revised regularly as the underlying Copilot capabilities move.

Editorial conclusion

Copilot Developer Camp fits a developer who needs a guided path through Microsoft 365 Copilot extensibility, from a no-code declarative agent through to a custom engine agent written in C#, and who is willing to work inside a Microsoft 365 tenant and the Microsoft Foundry tooling. It is the wrong dependency for a production system, since it is a documentation and labs repository with no releases, no packages and no version pinning, so nothing in it can be depended on the way a library can. Before you build on the guidance, read the specific lab pages for the path you need, decide whether the declarative or the custom engine route matches your requirement, and remember that the repository is MIT licensed with a separate contributor licence agreement and trademark rules that constrain reuse of Microsoft branding.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/copilot-camp on GitHub
4. README