Understand Foundry agent publishing options
Unit 2 of 8 · Module 11: Integrate your agent with Microsoft 365
Before you start
Short explainers for ideas this lesson builds on. Watch these first if they're new to you.
Go deeper
Unlocks when you've watched the lesson.
Read this lesson
A stable endpoint and its own identity
Think of a daily newspaper. The name on the masthead stays the same every morning, even though the stories inside change with each edition. In Foundry, every agent works like that from the moment you create it. It gets a stable endpoint: one address that stays put while you release new versions behind it. You choose which version it serves: always the latest, or one version you pin. The agent also gets its own Microsoft Entra identity, separate from your project, like a reporter's press pass. Older agents needed a separate resource called an Agent Application for all this, but that's now the legacy model. So in Foundry today, publishing means one thing: delivering your agent's endpoint to the places where people read.
Delivering to Microsoft 365
The main delivery route in this module is Microsoft 365: your agent shows up in Teams and in Microsoft 365 Copilot. When you publish there, Foundry sets up an Azure Bot Service resource, the delivery van that carries messages between Microsoft 365 and your agent. It packs a Teams app package, a zip file holding the app's manifest and icons. It submits that package to the Teams and Copilot agent store, so people can find your agent. And it switches on the activity protocol, the message format Teams and Copilot speak. The quickest way is straight from the Foundry portal: no code, and your agent logic stays in Foundry. For unusual needs, like custom sign-in, extra processing along the way, or separate test and production pipelines, the Microsoft 365 Agents Toolkit lets you build your own app in between. You'll meet it later as an advanced option.
Two print runs
Before the papers go out, you decide who gets them. Just you is a proof copy on your own desk. It's ready straight away with no approval, and it appears under Your agents in the store. You can share it with a link, and colleagues who have access to your Foundry project can use it too. People in your organization is the citywide edition. It goes to your Microsoft 365 admin for approval first, and after that it appears under Built by your org for everyone in your tenant. Use Just you for testing and small pilots, and your organization for production. Outside Microsoft 365, your own apps can also call the agent's stable endpoint directly, for example with the Responses API.
The press pass and the checklist
Remember the press pass. Your agent signs in to Azure with its own identity, not yours, and the permissions you had while building don't carry over to it. So if a tool reaches Azure AI Search or a storage account, give the agent's identity a role on that resource, or the tool will fail once real users arrive. Before you publish, check four things. You need the Foundry User role on the project. You need permission to create an Azure Bot Service, such as the Azure Bot Service Contributor role on the resource group, which Foundry roles don't include. The Microsoft dot Bot Service provider must be registered in your subscription. And your Microsoft 365 tenant has to allow custom agents and apps.
Facts from Microsoft's documentation: Publish agents to Microsoft Copilot and Microsoft Teams; Migrate from Agent Applications to the new Microsoft Foundry agent model; Agent applications in Microsoft Foundry (CC BY 4.0), rewritten in Loop's own words and examples. Narration, animation, and quiz by Loop. Microsoft, Azure, and Microsoft Foundry are trademarks of Microsoft. Loop is independent and not affiliated with or endorsed by Microsoft.