Skip to main content
TechExplainedTechExplained
|
How-toLevel: Intermediate

How to publish an agent in the Microsoft ecosystem

From your own organization's Agent Store to Microsoft Marketplace, a customer tenant and Microsoft Foundry: which route fits which goal, what each one requires, and where things go wrong in practice.

TechExplained 13 min readPublished: 3 August 2026Last updated: 3 August 2026
#copilot#agents#copilot studio#microsoft foundry#governance
Architects discussing the four publishing routes for agents in the Microsoft ecosystem.
All how-tos
  1. 01

    Decide where your agent needs to land

    You built an agent and it works. The question now is how to get it to the people who need to use it. Before you pick a route, you need to know where an agent can end up, because three destinations get mixed up all the time.

    • The Agent Store in Microsoft 365 Copilot. This is where users discover and install agents. Agents your own organization built and approved show up here under Built by your org.
    • Microsoft Marketplace. The central catalog for cloud solutions, AI apps and agents. Customers find your offer here and in the in-product stores across Microsoft 365, Microsoft Teams and Azure. Watch the naming: the partner pages on Learn say Microsoft Marketplace, while the extensibility documentation and the certification policies still say Microsoft Commercial Marketplace. It is the same catalog.
    • The customer tenant itself. Here the customer's administrator decides what gets approved, deployed and made visible. This is not a store, it is a management surface.
    Decision
    who is this agent for? Only colleagues, other organizations, or one specific customer you already serve? That answer determines your route, not the other way round.
    Note
    publishing and being available are not the same thing. An agent is only ready for users once an administrator has approved and assigned it. Plan for that step in your timeline.
  2. 02

    Pick the route that matches your audience

    There are four routes. Which one you pick depends on who needs to use the agent and whether you want to sell it.

    RouteWhen to choose itWhere the agent lands
    A. Your own organizationYou want an agent to be discoverable internally and tested at scale by colleagues.The Agent Store in Microsoft 365 Copilot, under Built by your org.
    B. Commercial distributionYou want to offer or sell a reusable solution to other organizations.Microsoft Marketplace through Microsoft Partner Center, plus the in-product stores.
    C. Managed customer tenantsYou are a partner or MSP rolling out an agent for a customer you already serve.The customer tenant, through the Microsoft 365 admin center and Microsoft Agent 365.
    D. Microsoft FoundryYou build the agent in Microsoft Foundry and want to make it available to users.The agent catalogs of Microsoft 365 Copilot and Microsoft Teams.
    Decision
    start with route A or go straight to route B? Almost always A. Feedback from your own users is free, and a rejection in Partner Center costs you a validation round.
  3. 03

    Route A, publishing to your own organization's Agent Store

    This is the fastest route and usually the first one you take. You publish an agent from Copilot Studio into your own tenant, where an administrator approves and releases it.

    1. Build the agent in Copilot Studio and test it in the built-in test panel. Add the instructions, knowledge sources, tools and integrations it needs.
    2. Publish the agent. That makes it visible to the administrator in the Microsoft 365 admin center.
    3. Open the Channels tab, select the Microsoft 365 Copilot and Microsoft Teams channel and confirm Make agent available in Microsoft 365 Copilot. Under Edit details you configure how the agent is displayed. Select Save to send it to the administrator.
    4. The administrator reviews the request under Agents, All agents and Requests, and selects Publish or Reject. On a rejection the maker is notified and can adjust and resubmit.
    5. Once approved, the agent appears in the Agent Store under Built by your org and is available in Microsoft 365 Copilot and Microsoft Teams.

    What the administrator looks at. Whoever submits can prepare for the review. In practice the display name and short description get reviewed, along with the capabilities, knowledge sources and actions, the risks and protections under Security and compliance, and the certification or publisher attestation details. Get that right before you submit and you save yourself a rejection round.

    Decision
    do you even need the Agent Store? For a pilot with a handful of colleagues you can share the agent directly. The Agent Store exists for discoverability at scale, and that discoverability costs you an approval step.
    Note
    availability in other Microsoft 365 apps such as Word, Excel and Outlook is not automatic. It depends on your app package, host support and the distribution route you choose.
  4. 04

    Route B, distributing commercially through Microsoft Marketplace

    If you want to offer your agent as a product to other organizations, that runs through Microsoft Partner Center into Microsoft Marketplace. Sort out the basics first, because without them you cannot submit at all.

    • A Partner Center account within the Microsoft AI Cloud Partner Program.
    • Enrollment in the Microsoft 365 and Copilot program.
    • Completed publisher verification, where Microsoft confirms your organization is authentic. That earns a verified badge on the Microsoft Entra consent prompt and on your marketplace listing.

    After that you go through these steps.

    1. Package the agent as a Microsoft 365 app package, which is the same app manifest used for Teams apps.
    2. Check your agent against the marketplace certification policies, the store validation guidelines for agents and the Responsible AI validation checks. Optionally you also go through the Microsoft 365 App Compliance Program.
    3. Submit through Partner Center, in the Microsoft 365 and Copilot program, under the offer type Apps and agents for Microsoft 365 and Copilot.
    4. Microsoft validates and approves the app package.
    5. Once approved the agent is in the marketplace and ready for IT enablement at the customer. As soon as a customer's IT administrator enables it, it appears in the Apps store within Microsoft 365 Copilot, Microsoft Teams, Outlook, Word, Excel and PowerPoint, and in the Agent Store within Microsoft 365 Copilot.

    Choose your monetization model deliberately and early. Microsoft supports a Microsoft-managed transactable model, where you link the agent to a SaaS offer, and a bring your own license model. With BYOL you ship no licenses, so you have to state the license requirements explicitly in both the manifest description and the listing.

    Decision
    transactable or BYOL? Transactable gives you billing through Microsoft but ties you to a SaaS offer. BYOL is quicker to set up but moves the licensing conversation into your own sales process.
    Pitfall
    not every agent type is allowed into the marketplace. Declarative agents from Copilot Studio cannot go there, and the multitenant route from Copilot Studio is preview. Check the table below before you write a proposal.
  5. 05

    Route C, deploying and managing inside a customer tenant

    This is where the mental model breaks down most often. Microsoft Agent 365 and the Agent Registry are not a marketplace and not a publishing target in themselves. They are the governance and management layers an organization uses to keep control of the agents in its tenant.

    • Microsoft Agent 365 is the layer for observing, managing and securing agents. It is available as a separate license and included in Microsoft 365 E7.
    • The Agent Registry in the Microsoft 365 admin center is the inventory and management layer where agents are registered, approved and taken through their lifecycle.
    • Microsoft Entra Agent ID remains the identity foundation and provides the identity platform capabilities Microsoft Agent 365 builds on.

    As a partner or MSP, this is how it works in practice.

    1. Agree up front on the rights you get: delegated or admin rights, plus explicit customer approval. The customer tenant stays in charge of approval, deployment and availability.
    2. Publish or upload the agent package into the customer tenant through the Microsoft 365 admin center, under Agents and All agents. Alternatively you let the customer's administrator activate the agent from the marketplace.
    3. Use Agent 365 and the Agent Registry for inventory, approval, deployment, monitoring and lifecycle management, and set rules to flag things like ownerless agents.
    Decision
    do you deploy it yourself or does the customer? Doing it yourself is faster but requires rights you have to justify. Let the customer activate once the agent comes from the marketplace, which keeps governance where it belongs.
    Note
    you cannot simply drop an agent into a customer tenant. Without the right permissions and without customer consent, nothing happens.
  6. 06

    Route D, publishing from Microsoft Foundry

    If you build agents in Microsoft Foundry you have your own route to the user. Foundry publishes the agent's stable endpoint and delivers the package to the agent catalogs of Microsoft 365 Copilot and Microsoft Teams.

    1. First pick the active version your consumers should see. That can be a fixed version or Always use latest.
    2. Publish from your Foundry project through Publish and then Teams and Microsoft 365 Copilot. Foundry creates an Azure Bot Service resource if needed, validates your metadata and compiles an app manifest as a ZIP package.
    3. Choose the scope. Just you makes the agent available immediately under Your agents and needs no approval. People in your organization goes to a Microsoft 365 administrator and appears under Built by your org once approved.
    4. If you want to adjust the manifest, choose Download and customize and upload the package into Microsoft Teams yourself.

    What you need: a Foundry project, the Foundry User role at project scope, and permission to create an Azure Bot Service resource and configure its channels. The Azure Bot Service Contributor role grants exactly those permissions; Foundry roles do not. Mind the rename: Foundry User was previously called Azure AI User, and you will still see the old names in places while the rename rolls out.

    Decision
    do you publish tenant-wide right away? Start with Just you. That way you test the real Teams experience without putting an administrator in your iteration loop.
    Note
    publishing from the Foundry portal does not work for projects with public network access disabled. For those you use the REST API with the accompanying networking steps.

Which agent type can go where?

This is the table worth remembering, because how you build determines where you can publish.

How you buildYour own organizationMicrosoft Marketplace
Declarative agent with Agent Builder in Microsoft 365 CopilotYes, through the org catalog and the Agent Store.No.
Declarative agent in Copilot StudioYes, through the org catalog and the Agent Store.No.
Declarative agent with Microsoft 365 Agents ToolkitYes.Yes, through Partner Center.
Custom engine agent with Microsoft 365 Agents ToolkitYes.Yes, through Partner Center.
Custom agent in Copilot StudioYes, through the Microsoft 365 Copilot and Teams channel.Yes, through Partner Center, but the multitenant route is preview.
Agent in Microsoft FoundryYes, after admin approval at org scope.Publishing runs through the agent catalogs, not directly.

Can I publish as an individual developer?

This is the question that comes up almost every time someone finishes their first agent. The short answer: inside your own organization an individual can publish just fine, but for the commercial marketplace you need a registered business in practice.

RouteCan an individual do this?
A. Your own organizationYes. Any employee with the right license can build and submit an agent. Only the approval sits with an AI Administrator or Global Administrator. If you would rather not involve an administrator at all, you can share an agent directly with a few colleagues without the Agent Store.
B. Commercial distributionNot as a private individual. An Office or Microsoft 365 developer account in Partner Center requires signing authority on behalf of your company, plus the legal company name, the address and a primary contact. Microsoft verifies those details while the account is created. You sign in with a Microsoft Entra work account, not a personal Microsoft account.
C. Managed customer tenantsNo. This is by definition a partner or MSP scenario with delegated or admin rights in the customer tenant.
D. Microsoft FoundryPartly. Publishing with the just yourself scope works without approval, publishing tenant-wide does require an administrator.

The nuance sits with route B. Partner Center formally has two account types, Company and Individual, with verification steps for email, employment and business. The program you need for agents, Microsoft 365 and Copilot, is however set up around a business entity. For a Dutch reader that means: a sole trader registered with the Chamber of Commerce can arrange this without trouble, a hobbyist without a registered business cannot. So you do not need to be a large company, but you do need a verifiable business with its own domain and work account.

Licensing, roles and cost

There is no single answer to what you need. It depends on the scenario, and that is exactly where proposals and architecture diagrams go wrong.

Licensing. Microsoft 365 plans include Copilot Chat, which provides web data agents. Microsoft 365 Copilot is added on top of E3 or E5 and provides agents that also reach work data; in Microsoft 365 E7 it is already included, together with Microsoft Agent 365 and the Microsoft Entra Suite. On top of that, depending on the scenario, you need a Copilot Studio license, Copilot Credits or pay-as-you-go. You need an Azure subscription for pay-as-you-go, for Microsoft Foundry and for external agents, but not for every Copilot Studio publication.

Roles. Tenant-wide agent management sits with the AI Administrator or the Global Administrator: only those two can install, modify, approve and configure agents. Global Reader and AI Reader see everything but change nothing. Security Administrator, Security Reader and Reports Reader are read-only as well. The Teams Administrator remains relevant for Teams app policies, but is not the approval role in the Agent Registry. Stick to least privilege and use Global Administrator only when no suitable role exists.

Cost and monetization. Deliberately choose between a Microsoft-managed transactable SaaS offer, bring your own license, Copilot Credits or pay-as-you-go, and Foundry or model consumption. Avoid blanket statements about cost per token unless you are genuinely talking about model or Foundry consumption.

Checklist before you publish

  1. Determine your route and your build type, and confirm that combination is possible.
  2. Arrange your publisher identity early, because a work account, your own domain and business verification all take lead time.
  3. Prepare your metadata: name, short description, developer information, privacy statement and terms of use.
  4. Check the agent's knowledge sources, capabilities and actions.
  5. Work through the certification policies, the store validation guidelines and the Responsible AI validation checks.
  6. Sort out the roles: who approves, who deploys and who manages the agent after go-live?
  7. Use separate environments for development, test and production. This is our own recommendation rather than a hard Microsoft requirement, but it makes your releases predictable.

Three mistakes you can avoid

  1. Assuming publishing equals being available. There is almost always an administrator in between. Plan for that step in your timeline.
  2. Selling a preview route as a production route. The multitenant route from Copilot Studio into the marketplace is preview. Be transparent about it.
  3. Thinking about monetization too late. Your licensing, consumption and monetization model belongs in your listing. Sorting that out up front gets you through validation faster.

In closing

Publishing is less complicated than it looks, as long as you answer two questions first: who is this agent for, and how did I build it? Those two answers determine your route, your requirements and your lead time. Start small with route A, learn from the feedback of your own users, and scale up to the marketplace after that.

Sources

The process at a glance

Click a step for its key decision

Decision

Decide where your agent needs to land

who is this agent for? Only colleagues, other organizations, or one specific customer you already serve? That answer determines your route, not the other way round.

Read next

Publishing an agent: the four routes in the Microsoft ecosystem