Perform ongoing Agent Registry curation
Tools are reviewed now, including the ones Relecloud builds itself. But the agents already sitting in Relecloud's Registry still need ongoing upkeep the one-time onboarding process never covers. An engineering team ships an agent internally, then moves on to the next project without telling anyone. A developer who owns three agents leaves for another role, and those agents keep running with no one accountable for them. A proof-of-concept agent from last quarter still shows up in every list, even though nobody opens it anymore. None of this is an onboarding decision—it's the maintenance that keeps the Registry trustworthy after onboarding ends. Four actions cover it: uploading a custom agent, reassigning an active agent's owner, deleting an agent, and starting or stopping a Microsoft Foundry agent.
| Action | What it does | Role / caveat |
|---|---|---|
| Upload a custom agent | Brings an internally built agent (a ZIP packet) under Registry governance | Downloaded from Copilot Studio or Agent Builder |
| Assign new owner | Reassigns ownership—works for an ownerless or an already-active agent | Only Agent Builder and Copilot Studio agents, not Foundry |
| Delete an agent | Permanently removes the agent and its files (irreversible) | Removes the SharePoint Embedded container for Agent Builder agents; up to 24 hours to propagate |
| Start / stop a Foundry agent | Provisions or deallocates the agent's underlying Azure compute | Requires the Azure AI Owner role, not AI Administrator |
Upload a custom agent into the Registry
Before you can curate an internally built agent, it has to actually be in the Registry—and that's a different problem from the publish/reject request workflow you already use for agents that come to you through the onboarding queue. When one of Relecloud's engineers builds an agent directly in Copilot Studio or Agent Builder, you bring that agent under governance yourself by uploading it.
The agent travels as a ZIP packet file that bundles everything the Registry needs: the manifest, configuration files, icons, branding, and any embedded knowledge files. You get that ZIP from wherever the agent was built. In Copilot Studio, you open the agent, go to Channels, select the channel it publishes to (such as Teams or Microsoft 365 Copilot), then choose Availability options > Download .zip. In Agent Builder in Copilot, you open All agents, select the ellipses next to the agent, choose Edit, then select the ellipses on the right and Download .zip file.
With the ZIP in hand, you upload it in the Microsoft 365 admin center: go to Agents > All agents > Add agent, then Choose file to select the packet. The admin center validates the file, and you select Next. From there, you confirm the agent's name, icon, and host products, choose who can install it under Publish, and optionally choose who it deploys to under Deploy. That's the moment an internally built agent stops being a side project one team knows about and becomes something the whole tenant can see and govern.
Reassign an already-active agent's owner
The onboarding exercises you already worked through cover assigning an owner to an agent that has none—useful the first time an agent lands in the Registry, but that's not Relecloud's problem here. The agents piling up now already have an owner. The owner just doesn't work there anymore.
Assign new owner handles both cases: an agent with no owner and an agent that's already active with one. You select an agent from All agents—the Platform filter narrows the list to a specific agent type quickly—then, in the agent details pane, immediately under the agent name, you select Assign new owner, enter a new owner from the organization, and select Assign.
Before you reach for this on every departed employee's agent, though, check what kind of agent you're looking at. Reassigning ownership of a shared agent is only supported for Agent Builder and Copilot Studio agents—it doesn't work uniformly across every agent platform in the Registry. An agent built on Microsoft Foundry, for example, doesn't offer this option the same way. When reassignment does apply, it's a clean handoff rather than shared access: the new owner gets full edit and delete permissions, plus access to any files the previous owner uploaded, and the previous owner loses all access, including read rights.
Scenario: Two of Relecloud's agents lose their owner in the same week. One is a Copilot Studio agent a support-team developer built to triage tickets. The other runs on Microsoft Foundry and handles a batch data pipeline. For which one does Assign new owner apply, and what would you check first for the other?
Delete an agent no longer needed
Not every ownerless or orphaned agent deserves a new owner. Some just aren't used anymore, and keeping them around adds clutter and risk without adding value. For those, you delete the agent instead of reassigning it.
Deletion permanently removes the agent from the inventory and deletes all associated files. For an agent built with Microsoft 365 Copilot Agent Builder specifically, that also removes the underlying SharePoint Embedded container the agent relied on. There's no undo here—the action is irreversible, so it's worth confirming the agent truly has no remaining owner or use case before you commit to it.
Deletion also doesn't propagate instantly. It can take up to 24 hours for the deletion to reach every user who had access, so during that window some users might still see the agent listed even though they can no longer interact with it. That's expected behavior, not a sign the deletion failed.
Start or stop a Microsoft Foundry Agent
Every action so far applies broadly across Registry agent types, but this one doesn't. Start and stop is unique to agents built on Microsoft Foundry, and it does something more fundamental than the availability toggles you've used elsewhere in this module. Instead of just changing whether an agent is available at the tenant level, starting or stopping a Foundry agent provisions or deallocates the underlying Azure compute resources for that deployment. Stopping the agent isn't a soft pause—it's turning off the infrastructure the agent runs on.
That difference in what the action actually touches explains a role requirement worth remembering for the exam: starting or stopping a Foundry agent requires the Azure AI Owner role, not the AI Administrator or Global Administrator role you've used for tool approval and most other actions in this module. Registry actions generally sit inside Microsoft 365 admin roles, but this one reaches into Azure infrastructure directly, so it needs an Azure role instead. Not every agent-governance action in this module uses the same permission—this is the deliberate exception.
Reflect: Why might Microsoft draw the permission boundary at Azure infrastructure instead of extending AI Administrator or Global Administrator to cover Start/Stop as well?
Where curation goes from here
Individual agents are uploaded, reassigned, and cleaned up now. But with this many agents across this many teams, how do you get a view of the whole estate at once?