Foundry Agents Are Moving From Apps You Build to Coworkers IT Has to Govern

Microsoft’s newest Foundry agents story is easy to misread as another “now you can publish your bot to Teams” announcement. That is the small version. The more important version is that Microsoft is turning agents from app endpoints into governed workplace actors: things with identities, scopes, admin review, social presence, and the ability to keep working after the initial prompt has left the room.

That shift matters because the enterprise agent problem was never just model quality. It was distribution and trust. A brilliant internal agent trapped behind a separate web UI is a pilot. An agent that shows up in Microsoft 365 Copilot, Teams, Agent 365, and interoperable agent-to-agent channels is infrastructure. Useful, dangerous, auditable infrastructure. The same sentence is doing a lot of work there.

Microsoft’s Foundry update lays out three pieces: publishing Foundry agents into Microsoft 365 Copilot and Teams, generally available next month; autopilot agents in public preview; and incoming Agent-to-Agent endpoints in public preview. The framing is explicit: Microsoft wants the interaction model to move from Prompt → Response to Goal → Ongoing execution → Checkpoints → Collaboration. That is not a UI tweak. That is the difference between a chatbot answering a question and a delegated worker managing a task over time.

The agent is not a tab anymore

The most consequential detail is identity. Microsoft says autopilot agents operate with their own identity and user accounts, including productivity licensing for email, calendar, OneDrive, Teams access, and an org-chart presence. That means the agent is no longer just code behind an endpoint. It is closer to a service account that participates in human workflows, with all the authority and ambiguity that implies.

The Workstream Manager sample is revealing because it is full of small social-product details. The agent tracks tasks and deadlines, summarizes conversations into action items, follows up on overdue work, surfaces blockers, answers workstream questions, and uses Microsoft 365 WorkIQ tools across Word, Excel, Outlook, calendar, OneDrive, and SharePoint. It also exposes manager-controlled access commands like /access add, /access remove, and /access list. It reacts with 👍 when it intends to answer and 📌 when it logs a commitment.

Those reactions sound minor until you have watched a bot ruin a group chat. Shared workspaces need legibility. Humans need to know when an agent is listening, when it is recording an obligation, when it is acting, and who gave it permission to be there. Silent automation in a shared channel is how useful tools become surveillance vibes. Microsoft’s sample suggests the company understands that agent UX is not just prompts and cards; it is social choreography.

The publishing path reinforces the same governance story. Publishing to Microsoft 365 and Teams creates or reuses an Azure Bot Service resource and supports direct publish scopes: “Just you,” which does not require admin approval, or “People in your organization,” which does. Foundry agents are automatically registered in Microsoft Agent 365, where admins can review metadata such as name, description, tools, agent identity, and blueprint. That is the boring layer enterprises actually buy: not “can the agent answer?” but “can we discover it, approve it, identify it, and revoke it?”

A2A turns delegation into a supply-chain problem

The Agent-to-Agent piece is where this gets sharper. Foundry incoming A2A supports protocol versions 1.0 and 0.3; Microsoft says new integrations should target v1.0, while unspecified requests default to v0.3. Enabling incoming A2A is not yet in the portal, so developers use REST or Python SDK. Agent cards describe capabilities and are published at version-specific endpoints. All A2A URLs require Microsoft Entra ID authentication, and anonymous access to the agent card is not supported. Calling agents need a valid token with the Foundry User role on the project.

That is a sane default, but it does not eliminate the hard problem. Once agents can discover and delegate to other agents, you have a new supply chain. The dependent agent trusts another agent’s card, semantics, permissions, uptime, traces, and output quality. If a sales agent delegates to a contract agent, which delegates to a pricing agent, the failure path is no longer a single prompt gone wrong. It is a chain of identities and assumptions.

For practitioners, the action item is not “turn on A2A because interop is cool.” It is to define a trust policy before delegation goes live. Which agents may call which endpoints? What data can cross the boundary? Are tool traces retained in one project, both projects, or neither? What happens when a downstream agent denies a request, times out, or returns a partial result? Can the original human see the delegation chain, or does the result arrive as one neat answer with the provenance stripped out? If you cannot answer those questions, you do not have agent interoperability. You have distributed vibes.

Builders should write an agent operating contract before publishing anything beyond a private test scope. It should name the owner, the agent identity, allowed data sources, write permissions, approval thresholds, group-chat behavior, logging policy, retention period, escalation path, and rollback process. That sounds bureaucratic only if you still think the agent is a fancy FAQ. If the agent has email, calendar, OneDrive, Teams, A2A endpoints, and a visible place in the org, the contract is the product boundary.

The strategic read is straightforward: Microsoft is making distribution the feature, but governance is the reason the feature can exist. Standalone agent apps will still matter for specialized workflows, but the default enterprise adoption path is going to run through existing work surfaces and admin control planes. That gives Microsoft a serious advantage, not because its agents are magically better, but because enterprises already live in the places those agents are being inserted.

There is a risk here. Once agents look like coworkers, organizations may grant them coworker-like trust faster than their controls mature. That would be a mistake. Treat an autopilot agent less like a junior employee and more like a production service with a chat avatar. It needs least privilege, observability, incident response, and user-facing transparency. The icon can be friendly. The control plane should not be.

Sources: Microsoft Foundry Blog, Microsoft Learn: publish to Copilot, Microsoft Learn: Agent 365, Microsoft Learn: A2A endpoints