Foundry autopilots and Copilot Autopilot (formerly Scout) both have their own identity. They have a different owner, a different status and a different way of being paid for. This article puts them side by side and starts with hosted agents, because a Foundry autopilot always runs on one.
What changed since the summer
Hosted agents are generally available. In August I still pointed out a status mismatch between the Foundry documentation (preview) and the Agent Framework documentation (GA). The Foundry update for July and August 2026 now calls hosted agents generally available. The autopilot layer on top of them is still in public preview.
Scout has been called Autopilot since 25 September and runs in the cloud. It used to be a desktop app and it is now an agent inside your tenant. My earlier advice to keep Scout out of an EU tenant was based on the GitHub Copilot attestation of the desktop version. For the cloud version Microsoft has not published the requirements yet, so the EUDB question is open.
Hosted agents: your own code, a managed runtime
A hosted agent is your own agent code in a container, running on infrastructure that Microsoft manages. You build the image, azd deploy pushes it to your ACR and deploys it to Foundry Agent Service. Foundry gives the agent its own endpoint and its own Entra identity. You pick the framework yourself: Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, the GitHub Copilot SDK or your own code.
Every session runs in its own VM sandbox, and $HOME and /files are kept. After 15 minutes idle the compute is torn down, and when the session resumes the state comes back. That saves money, because you don’t pay for a container that is just waiting.
In my own multi-agent setup we built the Dockerfile, ACR, Container App, ingress, identity, logging and revision management ourselves. A hosted agent takes that whole chain over, so the orchestration logic stays yours and the hosting no longer is.
One pitfall: network injection for private networking has to be set when you create the Foundry account. Adding it afterwards is not supported for hosted agents, so the network choice is a day-zero decision.
A demo that shows well why this exists is a hosted agent that plays an NES game. A headless emulator runs in the container, a vision model picks a button press per invocation and the savestate lives in $HOME. It is slow (1 to 3 seconds per decision) and I haven’t built it yet, so this is a design and not a result. It does show your own code, your own compute and state that survives a session in a single demo.
Foundry autopilots: an identity, not a feature
Microsoft defines an autopilot by who it is and not by what it can do. What makes it an autopilot is an agent user account next to the agent identity. That account gives it its own mailbox, calendar, Teams presence, a place in the org chart and a manager.
Without that account an agent can only act on behalf of a signed-in user. On an event trigger there is nobody to act on behalf of. In a group chat the permissions of one person apply to the whole thread, and then people see content they shouldn’t have access to.
You don’t build an autopilot but a blueprint, from which teams hire instances that each get their own identity, manager and access. Otherwise you end up with one agent per team, each with its own controls that drift apart. With a blueprint you update once and block once, and all instances follow. Only hosted agents can be published as a blueprint.
Three governance properties to use in a customer conversation:
- Anyone outside the configured audience is blocked before the autopilot calls a model.
- Anyone close to the work can block an instance, but only a tenant administrator can switch it back on.
- A blueprint that asks for more scopes has to pass the consent gate again.
The Microsoft GBB team built a procurement officer this way. It refuses an urgent email asking to change a supplier’s bank details and tells its manager. Separately, the governance policy denies that write action, whatever the model decides. That second lock is why I take this pattern seriously: the safety doesn’t live only in the prompt.
Licensing and status. The tenant needs at least one Microsoft 365 Copilot licence or Agent 365 licence, and E7 counts. An agent user is licensed per instance, while Agent 365 is counted per human. Publishing is in public preview and the APIs change often. The prices from my August research (Agent 365 at 15 dollars and E7 at 99 dollars per user per month) need to be checked again before you use them.
Copilot Autopilot, formerly Scout
On 25 September Microsoft rebuilt the Copilot app around Home, Code and Autopilot. You give Autopilot a name, a role and a goal, and then it watches Teams channels and mail threads, chases people for updates and picks work up again days later without a new prompt. You reach it with an @mention in Teams, Outlook, chats and documents. It runs in the cloud with its own identity, memory and workspace inside your tenant.
It is in private preview through Frontier and there is no GA date. Not yet published are the licence requirements, the EU Data Boundary position and which Scout capabilities, such as shell and browser control, will remain.
Chat falls under the fixed licence, while Cowork, Code and Autopilot run on usage-based billing with Copilot Credits. According to the summary of Message Center item MC1479277, an admin setting called “Request access” arrives in October (standard customers) and November (deferred customers). Decide your default beforehand under Microsoft 365 admin center, Copilot, Cost management, because otherwise your users decide through that button.
| Foundry autopilot | Copilot Autopilot | |
|---|---|---|
| Who builds it | You, in code | Microsoft, you set the name, role and goal |
| Status | Public preview, on a GA runtime | Private preview through Frontier |
| Identity | Agent identity plus agent user account | Own identity, object model not published |
| Payment | Azure consumption plus Copilot or Agent 365 licence | Copilot licence plus Copilot Credits |
| Control over behaviour | Full: your own code, tools and policies | Within what Microsoft offers |
I couldn’t establish whether instances of Copilot Autopilot show up in the same Agent 365 registry as Foundry autopilots. That matters for an administrator, because without one registry you manage two fleets.
Which route I would pick
Build one Foundry autopilot as a proof of concept in an EU region. It is the only one of the two you can build today, the runtime underneath is GA and the governance model is documented. Pick one well-defined process with written rules and many small requests, such as following up review actions in an existing SharePoint environment. That way you test what is new: the agent user object, the licence per instance, the approval path and Conditional Access on a non-human identity that presents itself as a user.
If the EU Data Boundary is a hard requirement, switch off Agent 365 data collection on that Foundry resource through the agent365Config resource provider. Otherwise agent activity moves from the Azure regional model to the residency model of the Entra tenant. This comes from my August research, so verify it before you commit to it.
Don’t plan for Copilot Autopilot yet, because the requirements and the data boundary position are missing. Do write down the sponsor model now: every agent user needs a human sponsor. Without that policy you will have the same situation in a year with unmanaged service principals, only now with mailboxes included.
Which role would you give to an autopilot first, and who becomes the manager that has to be able to stop it?
Leave a Reply