Microsoft 365 Copilot has an agent store. Users can discover first party, third party and internally built agents, install them, and use them directly inside the Copilot experience they already work in. 

For an ISV, this is not just an extensibility option. It is a distribution channel. 

This guide focuses on one scenario only: 

An ISV / Software Development Company wants to integrate its product with Microsoft 365 Copilot and publish an agent that customer organizations can deploy through Microsoft 365. 

The best official starting point is the Microsoft 365 Copilot extensibility overview. 

What publishing an agent actually means 

When a customer installs your agent in Microsoft 365 Copilot, they are using your product through Copilot’s interface. 

Your agent can expose your instructions, your APIs, your domain logic, and your data in a Microsoft 365-native experience. At the same time, deployment still happens within Microsoft’s enterprise environment, which means admin control, governance, validation, and platform rules still apply. 

For an ISV, that means publishing is not just a packaging exercise. It is the point where your product becomes a deployable Microsoft 365 extension.

 

Start with the publishing target, not the tool 

Before you build anything, decide how you want customers to get your agent. 

There are two main publishing outcomes: 

1. Publish to a specific customer organization
   

   This is the right route for pilots, customer-specific deployments, and managed implementations. 

2. Publish to the Microsoft Commercial Marketplace
   

   This is the right route if you want broad discoverability through Microsoft channels, including the Microsoft 365 Copilot Agent store. 

That decision matters early because not every build path supports the same publishing options. The official publishing matrix is here: Publish Agents for Microsoft 365 Copilot. 

What to build 

For an ISV targeting Microsoft 365 Copilot, there are three pro-code options. 

Copilot connectors 

Use this when your value is mainly in the data you want to provide to Copilot. 

A connector pushes content from your platform into the Microsoft 365 semantic index so Copilot can retrieve, summarize, and reason over it. 

This is a good fit for knowledge bases, document repositories, catalogs, and similar scenarios where the main need is grounding rather than actions. It’s also important to note that these grounding data sources should be relatively stable and not subject to frequent changes. For example, you might use a product catalog as a grounding source, but it would not be suitable for dynamic information like the current quantity in stock, which changes often. 

 

Reference: Copilot connectors overview 

Declarative agents 

This is the most common option for ISVs that want to publish an agent. 

A declarative agent lives inside Copilot, uses custom instructions, can call selected APIs, and gives customers a purpose-built experience for your product. But a declarative agent does not have its own foundational model or orchestration. Instead, Copilot deals with this. 

MCP (Model Context Protocol) Can be used to extend declarative agents to bring external data in the context of the agent here a great video that shows how.

If your goal is to publish an agent into Microsoft 365 for customer deployment, this is usually the best place to start. 

Reference: Declarative agents overview 

Custom engine agents 

Use this when you need to own the runtime, orchestration, model choice, or long-running workflows. Additionally, the custom engine approach is ideal for ISVs that already have their own agents and want to integrate them into the Copilot UI, making it easier for customers to access and interact with these agents directly within the Microsoft 365 environment. This integration allows ISVs to leverage their existing investments in agent technology while providing a seamless experience for end users. 

Microsoft Foundry Use this when you are building or already have an agent on Azure infrastructure and want to publish it to Microsoft 365 Copilot without manual manifest and bot registration setup. Foundry supports a no-code publishing flow from the Foundry portal directly to Microsoft 365 Copilot and Teams, with built-in governance routing through the Microsoft 365 Admin Center. This path is agent-type agnostic — it works for prompt agents, hosted agents, and workflow agents.  Reference: Publish agents to Microsoft 365 Copilot and Microsoft Teams (Microsoft Learn)

 

Reference: Custom engine agents overview 

Where Copilot Studio fits 

Copilot Studio also matters in this conversation, especially because it is a great way to quickly build agents on a SaaS platform and can be integrated into Microsoft Copilot easily. Many teams assume it offers the same publishing outcome as the pro-code route. Currently, it doesn’t. 

According to Microsoft’s official publishing guidance, agents built with Copilot Studio can be published to Microsoft 365 Copilot and Teams and can be shared with individuals, groups, or made available through the organization’s catalog, depending on how availability is configured and how the tenant is governed. See: - Extend Microsoft 365 Copilot with agents in Copilot Studio - Connect and configure an agent for Teams and Microsoft 365 - Key concepts - Publish and deploy your agent 

However, Microsoft’s publishing matrix makes the key limitation clear: 

Copilot Studio is a good path for tenant deployment, not the default ISV marketplace path 

If your goal is: - deploy to a specific customer tenant - pilot with a customer - share within an organization - publish through admin-controlled organizational deployment then Copilot Studio can be a valid option. 

If your goal is: - broad ISV distribution - repeatable packaged deployment across many customers - submission to the Microsoft Commercial Marketplace - visibility in the broader Microsoft commercial publishing motion, then Copilot Studio is not yet the preferred starting point. 

The official Microsoft 365 Copilot publishing documentation states that, today, only declarative agents built with Microsoft 365 Agents Toolkit and custom engine agents built with the same toolchain support submission to the Microsoft Commercial Marketplace. - Publish Agents for Microsoft 365 Copilot - Microsoft 365 Copilot agents admin guide 

Practical reasoning for ISVs 

For an ISV, the question is not whether Copilot Studio can build a good agent. It can. 

The question is whether it matches your distribution model. 

Copilot Studio is strongest when: - the deployment scope is one tenant or a controlled set of users - the solution is highly customized per customer - the customer or partner team wants low-code control in a Power Platform environment - marketplace-style packaging is not the primary requirement 

Microsoft 365 Agents Toolkit is usually stronger when: - the agent is part of a repeatable product offer - the ISV wants app-style packaging and versioning - submission to the Microsoft Commercial Marketplace matters - the ISV wants a cleaner productization story for broad customer deployment. 

 

Where MCP servers fit 

MCP is important because it changes the packaging discussion. 

If you expose your product through an MCP server, the MCP server is usually not the commercial product by itself. It is the integration layer that lets agents access your tools, actions, and real-time data. 

That distinction matters for publishing. 

The practical publishing logic for MCP-based solutions: 

• your agent is published through the Microsoft 365 app and agent path when you want a Copilot-native experience 

• your core commercial offer is published in Microsoft Marketplace as a SaaS application when your value is really the external service behind the MCP server 

This is a useful pattern when your MCP server is backed by a multitenant cloud product that you own and operate. In that case, the MCP server is part of your SaaS architecture, and the SaaS offer becomes the cleanest commercial package for procurement, subscription, and customer onboarding. Microsoft’s marketplace guidance explicitly supports Software as a Service (SaaS) applications as a core offer type. See: - Overview of Microsoft Marketplace - Plan a SaaS offer for Microsoft Marketplace 

 

When this matters most 

This approach is especially relevant when: - the MCP server exposes real-time tools or transactional actions - the customer needs an ongoing subscription to your hosted platform - the value is primarily in your external service, not only in the Microsoft 365 shell - you want a cleaner procurement and licensing path for your underlying product 

In other words: if the agent is the experience, but the SaaS platform is the product, publish the product as SaaS and treat MCP as the integration surface. 

 

Practical guidance for ISVs 

Use MCP when: - your customers need live access to tools, actions, or operational data - your product already exists as a hosted platform - your commercial model is subscription-based - you want the Microsoft 365 agent to act as a front end to your SaaS product 

In that scenario, the cleanest model is often: 

SaaS application in Marketplace + MCP-powered integration + agent experience in Microsoft 365 Copilot 

This is more precise than thinking of MCP itself as the thing you publish. 

 

MCP and Copilot Studio 

Copilot Studio can also connect to MCP servers. Microsoft documents MCP onboarding in Copilot Studio and even notes that you can optionally publish the MCP connector for broader reuse across tenants. That is useful for enablement and reuse, but it is still a different concern from packaging your commercial offer as a SaaS application. See Extend your agent with Model Context Protocol. 

So for ISVs, the practical split is: - MCP is the technical interface - SaaS offer is often the commercial offer - agent publishing is the user experience and deployment path inside Microsoft 365. 

The above can be condensed in the following decision tree:

 

The pro-code stack in simple terms 

For this publishing scenario, the important distinction is this: 

Microsoft 365 Agents Toolkit 

This is the development and packaging toolchain in Visual Studio Code. It is where you scaffold the project, manage the app package, test, and publish. Additionally, you define the adaptive cards that will display your content within Microsoft 365, allowing you to customize the user interface and present information interactively to users. 

Reference: Microsoft 365 Agents Toolkit overview 

Microsoft 365 Agents SDK 

This is relevant mainly for custom engine agents. It is the communication layer between your agent runtime and Microsoft channels. As note this is the evolution of Bot Framework 

Reference: Microsoft 365 Agents SDK overview 

Microsoft Foundry provides a platform for building, testing, and publishing intelligent agents using the Agent Framework SDK (formerly Semantic Kernel).

For most ISVs building a declarative agent, the toolkit is the key piece. 

The development flow before publishing 

The standard pro-code flow is straightforward. 

1. Scaffold 
   Use Microsoft 365 Agents Toolkit in VS Code to create the agent project and app package structure. 
2. Configure 
   Define instructions, capabilities, and the APIs or actions you want to expose. If you have an OpenAPI definition, you can use it to shape the callable surface.
3. Test 
   Validate the experience in a development tenant before thinking about external distribution. 
4. Package 
   Generate the Microsoft 365 app package that will be used for publishing. 

A useful hands-on resource is Copilot Camp. 

Publishing path 1: deploy to a specific customer organization 

This is the fastest way to get an agent in front of a customer. 

It is the right path for: - pilots - proof of concepts - customer-specific deployments - managed implementations 

In this model, you build and package the app, then publish it to the customer tenant. The customer admin still has to approve and enable it. 

This route does not mean “skip validation.” Responsible AI and platform checks still apply. 

The relevant admin-side path is described here: Publish your app to your org. 

Publishing path 2: publish to the Microsoft Commercial Marketplace 

This is the path for broad distribution. 

If you want your agent to be discoverable through Microsoft channels, including the Microsoft 365 Copilot store experience, you need to go through Partner Center. 

The process is more formal and includes business, technical, and listing requirements. 

Step 1 — Set up Partner Center early 

Create and prepare your publisher account well before submission. 

Reference: Partner Center for marketplace offers 

Step 2 — Prepare the app package 

Your package must be valid, complete, and aligned with the latest requirements for Microsoft 365 app publishing. 

Helpful references: - Publish Agents for Microsoft 365 Copilot - Microsoft 365 app manifest reference 

Step 3 — Prepare the store listing 

You will need listing content, screenshots, support details, privacy documentation, and other materials required for store submission. 

Helpful references: - Teams Store validation guidelines - Submission checklist 

Step 4 — Submit and validate 

Once submitted, the offer goes through Microsoft validation. Feedback may include issues that must be fixed before approval. 

Reference: Publish to the Teams Store 

What usually blocks publishing 

For ISVs, the common blockers are not only technical. 

Weak product value 

If the agent looks like a thin wrapper around generic Copilot behavior, it may struggle in review. 

Poor packaging quality 

Manifest issues, inconsistent naming, broken metadata, or incomplete assets can stop a submission quickly. 

Weak store readiness 

Bad screenshots, vague descriptions, or incomplete privacy and support information create avoidable friction. 

Unsafe or unclear actions 

If the agent triggers actions in external systems, the experience must be clear, well-scoped, and safe. 

Validation and policy issues 

Marketplace and store requirements still apply, and they should be reviewed early. 

Core references: - Microsoft Commercial Marketplace certification policies - Teams Store validation guidelines 

 

What an ISV should have ready before submission 

Before you submit, you should have these basics in place: 

• a clear use case and target user 

• a clear reason the agent adds value beyond generic Copilot chat 

• a stable API or product surface behind the agent 

• a valid app package 

• listing assets and store copy 

• support, privacy, and ownership information 

• a testing setup that covers the full end-to-end flow 

A practical reference for readiness is the Microsoft 365 app publishing checklist. 

Suggested reading order 

If your goal is publishing, this is the cleanest reading path: 

1. Microsoft 365 Copilot extensibility overview 

1. Declarative agents overview 

1. Create declarative agents using Microsoft 365 Agents Toolkit 

1. Publish Agents for Microsoft 365 Copilot 

1. Teams Store validation guidelines 

1. Submission checklist 

 

Final takeaway 

For an ISV or Software Development Company, publishing an agent into Microsoft 365 Copilot is not just about building an agent. 

It is about packaging your product as a deployable Microsoft 365 extension, choosing the right publishing path, and meeting the requirements that let customers install it with confidence.