How to Publish Microsoft 365 Copilot Agents Without the Rollout Falling Over

Most teams think the hard part of building a Microsoft 365 Copilot agent is the building. It isn't. The agent that demos beautifully on a developer's laptop is often the same agent that sits in limbo for six weeks because nobody worked out how it was going to get from "finished" to "in front of staff". Publishing is the bit everyone underestimates, and it is the bit that quietly decides whether your agent ever gets used.

I have watched genuinely good agents die in the gap between development and deployment. The code was fine. The problem was that no one had mapped the approval path, no one knew who owned the admin centre decision, and the agent ended up parked in a personal sideload while the business moved on. So this post is about the unglamorous end of the work: how you actually publish a Copilot agent, the routes available, and where Australian organisations tend to trip.

Microsoft's own guidance on publishing agents walks through the mechanics. What follows is the judgement around it, the stuff the docs won't tell you because it depends on how your organisation actually behaves.

The three ways an agent reaches users

There are really three publishing routes, and picking the right one early saves you a lot of grief.

The first is sideloading, or uploading a custom app. This is the developer's playground. You package the agent, upload it directly, and it runs for you and maybe a few testers. It is instant, it needs no approvals, and it is perfect for iterating. It is also completely unsuitable for anything beyond a pilot, because it does not scale and it leaves no governance trail. Use it to prove the thing works, then move on.

The second is publishing to your organisation's app catalogue. This is where most internal agents should live. You submit the agent, a Teams or Microsoft 365 admin reviews it, and once approved it becomes available to the people or groups you target. This is the route that gives you control: you decide who gets it, you can stage the rollout, and IT keeps oversight without you having to ship anything to the public. For a bank's internal policy assistant or a manufacturer's maintenance-lookup agent, this is almost always the answer.

The third is the commercial marketplace, Microsoft's public store. This is for software vendors and partners who want anyone with Copilot to be able to find and install their agent. The bar here is much higher: Microsoft validates the submission, there is a proper certification process, and you are now maintaining a product, not an internal tool. Very few of the agents we build for clients need this. If yours does, you are effectively becoming an ISV, and you should plan accordingly.

The mistake I see is teams building for one route and then discovering, late, that they actually needed another. An agent built and tested only as a sideload, with no thought to how the admin approval will read, hits the catalogue submission and suddenly there are questions about permissions and data handling that nobody prepared for. Decide the destination before you write the manifest, not after.

Where organisations actually get stuck

The technical publishing steps are not hard. The friction is human and it is procedural.

The first blocker is almost always admin approval. When you publish to the org catalogue, someone with the right admin role has to approve the agent in the Microsoft 365 admin centre or the Teams admin centre. In a lot of Australian organisations, that person is busy, cautious, and has never heard of your project. If you have not warmed them up in advance, your beautifully finished agent joins a queue behind a hundred other requests. We now treat the admin approver as a stakeholder from day one, not a rubber stamp at the end. Tell them what the agent does, what data it touches, and what permissions it needs, before you hit submit. It changes a three-week wait into a same-day yes.

The second blocker is permissions and consent. If your agent calls out to APIs, whether that is a Microsoft Graph connector or your own backend, someone has to consent to those permissions. Admin consent for Graph scopes is a governance decision, and in regulated industries it can trigger a security review. This is not a bad thing. It is the system working. But it needs to be in your timeline. An agent that quietly needs Sites.Read.All is going to prompt a conversation, and you want to be ready for it with a clear justification rather than scrambling.

The third blocker is the manifest and validation itself. The app package has to be valid, the manifest has to match what the agent actually does, and the metadata has to be honest. Microsoft's validation will catch mismatches, missing icons, and dodgy descriptions. Getting a clean package sounds trivial and mostly is, but I have seen submissions bounce three times over things like an icon that was the wrong size or a description that overpromised. Read the validation requirements once, properly, and you will save yourself the loop.

Governance is not optional, and that is fine

There is a temptation, especially among developers, to see the approval and governance layer as bureaucracy getting in the way of good work. I understand the feeling. I do not share it.

An agent that can read documents, call systems, and act on behalf of a user is a real piece of software with real reach into your organisation's data. The admin review, the consent flow, the catalogue controls, these exist because someone, somewhere, is going to build an agent that shouldn't have been let loose. The governance is the thing that catches it. When we build for clients in healthcare or financial services, the review process is often the most valuable conversation in the whole project, because it forces the questions that should have been asked anyway: what can this thing see, who can use it, what happens when it gets something wrong.

So my honest position is that you should lean into the publishing controls rather than route around them. The organisations that treat governance as a partner ship agents that survive contact with their own security team. The ones that treat it as an obstacle ship agents that get pulled the first time an auditor asks a hard question. This is exactly the sort of thing our Copilot Studio consultants work through with clients before a single line of manifest gets written, because the shape of your governance changes the shape of your agent.

Staged rollout beats big-bang every time

Once you can publish, resist the urge to switch it on for everyone at once. The org catalogue lets you target specific users and groups, and you should use that.

Start with a small group who understand the agent is new and will tell you when it does something odd. Watch how they actually use it, which is never quite how you imagined. Fix the prompts, tighten the responses, adjust the scope. Then widen. This is not caution for its own sake. It is that an agent's behaviour in the wild is genuinely hard to predict, and the cost of a bad first impression across a whole company is high. People try a new internal tool once. If it fumbles, they don't come back, and no amount of later polish wins them over.

We usually pair the staged rollout with a feedback loop so the pilot group can flag problems easily, and we watch the actual usage rather than trusting our assumptions. The agents that succeed are the ones that got quietly better during a controlled rollout before they went broad. This is a big part of what our AI agent builders do beyond the build itself, because shipping the thing is only step one.

What to watch out for

A few practical warnings from the field.

Version updates need the same care as the first publish. When you update a published agent, depending on what changed, it may need re-approval, and if you have added permissions it will almost certainly trigger a fresh consent. Do not assume an update is frictionless just because the original got approved. Plan updates like small releases, because that is what they are.

Descriptions and metadata are user-facing and they matter more than developers think. The name, the description, the example prompts, these are what a user sees when deciding whether to trust and try your agent. A vague or overhyped description undersells a good agent. Write them like you are trying to earn a busy person's attention, because you are.

And keep the agent's stated capabilities honest. If the manifest claims the agent can do things it can't, or the description implies reach it doesn't have, you erode trust and you invite validation problems. An agent that does three things well and says so beats one that claims ten and delivers four.

The bottom line

Publishing a Copilot agent is a governance and rollout exercise dressed up as a technical step. The packaging is easy. The winning move is deciding your publishing route early, treating the admin approver as a real stakeholder, being honest about permissions, and rolling out in stages so the agent gets better before it gets big. Do that and the agent you built actually gets used, which after all was the whole point.

If you are building Copilot agents and want them to land properly inside a real organisation rather than stall at the approval gate, that end-to-end work is what we do. Have a look at our broader Microsoft AI consulting, or if you have got an agent you want to get into people's hands, get in touch.