Microsoft Foundry has a lot of places to learn from: samples, solution templates, quickstarts and a learning path. When I started, I could not tell which one to open first, or which parts were Microsoft's and which were not. So I read them all. This post is the short version: the big picture, and the Microsoft learning path I would follow.

An agent in one sentence

An agent is a model that can think, use tools, know things and team up with other agents, running with an identity that decides what it is allowed to do. Foundry is Microsoft's place to build, run and look after agents like that.

What is open, and what does Microsoft add?

Most of the ideas are not unique to Microsoft. They are cross-industry standards and open source, and that is a good thing: what you learn is not locked in, and your tools and agents can work with other platforms. Microsoft's contribution is mostly the work around them: running agents, finding your data and keeping everything safe.

• Open and cross-platform: MCP for tools, A2A for agents talking to agents, OpenTelemetry for traces, and the OpenAI-style Responses API and SDK for talking to models. For code you can use Microsoft's Agent Framework (MIT licence, .NET and Python), LangGraph (MIT) or your own. A2A is Apache 2.0, and I found it lives under its own a2aproject organisation, with Google Cloud among the partners it names. I wrote about MCP, LangGraph with A2A and A2A in Foundry.
• Microsoft adds: a place to host agents, one toolbox for tools, Foundry IQ and a memory store for knowledge, identity and roles for every agent, guardrails, and a way to publish to Teams and Microsoft 365.

The pattern: bring your own, and Microsoft runs it

The most useful thing I learned is a pattern. Foundry does not ask you to write agents its way. A hosted agent is your container, built with any framework, and Microsoft's own docs name Agent Framework, LangGraph, Semantic Kernel or plain custom code. Foundry then does the plumbing: it hosts the container, gives it an identity, and sends its traces to Application Insights through OpenTelemetry.

The edges speak open protocols. A hosted agent can answer on the Responses protocol, so any OpenAI-compatible SDK can talk to it. It can also answer on A2A, and it can use a custom Invocations protocol when the caller has its own format. Even the Microsoft-only parts show an open face:

• The toolbox exposes all its tools through one MCP endpoint.
• A Foundry IQ knowledge base is reached through an MCP endpoint too.
• The model catalog holds more than OpenAI models. Microsoft's page lists DeepSeek, Meta Llama, Mistral, Cohere, xAI and Black Forest Labs, and one of the samples runs an Anthropic Claude model through Foundry.

How portable is it?

Here is my rough sorting of the pieces. It is my judgement from reading the docs, not a promise.

So I would put the valuable logic in the open layer, and let Foundry carry the plumbing. Then moving later would mean replacing the plumbing, not rewriting the agents.

Standards Microsoft supports, and what comes next

Here are the standards I saw Microsoft support in its own docs and samples. I did not find one official list, so this is what I found, not everything.

Three cautions. Microsoft's own protocols, such as the Activity protocol for Teams and Microsoft Entra for identity, are not cross-industry standards. I did not check which MCP spec version Foundry supports. And I did not find explicit support for other agent protocols such as AG-UI, only a mention that you can serve one through the custom Invocations protocol.

What Microsoft is working on with others. I looked for places where Microsoft says it is helping to develop a standard, not just use one. Here is what I could confirm from primary sources.

Both big protocols now sit under the Linux Foundation. MCP moved to the Agentic AI Foundation in December 2025, and Anthropic's announcement lists Microsoft among its supporters. A2A is hosted by the Linux Foundation, with more than 150 supporting organisations.

Where the standards are heading. The MCP roadmap, dated August 2026, plans four things: long-running tasks and events, a simpler HTTP transport, agent identity (agents acting for a user who is not present) and a cleaner tool result shape. I find two of these interesting. Agent identity is the same theme as the roles and identities in the quickstarts, so the standards are moving towards agents, not just people, signing in. And MCP growing its own tasks starts to overlap with A2A's. I do not know how the two will fit together, so I would watch it. Both points are my reading.

What might become a standard next?

Earlier I said Microsoft's contribution is mostly the work around the standards: running agents, finding your data and keeping everything safe. Some of that work may harden into standards over time. Here is my guess, with the signal behind each one. These are guesses, not announcements.

The pattern I see is that the parts which cross a boundary tend to become standards first: who an agent is, how it is found, how its work is traced, and how it asks for something. The parts that sit inside one platform, such as memory and guardrails, are the least likely to.

What the retirements tell us

Most of what Microsoft is retiring is its own shape, but not all of it. Connected Agents and workflows were Foundry features. They are replaced by the open A2A tool and by Agent Framework, which is open source. Prompt flow is the exception that teaches the most: it was open source too, with an MIT-licensed public repository on GitHub. Its repository sits in Microsoft's own GitHub organisation, and I found no foundation or other vendors behind it. That is my reading, because I could not tell contributors' employers apart from the commit data. Being open source did not save it, and it is retiring on 20 April 2027, with Agent Framework as the recommended replacement.

So the lesson is not simply "open good, Microsoft-only bad". An open licence does not make a tool a standard. MCP, A2A and OpenTelemetry are different because many companies back them, not because their code is open. That is the signal I would look for before building on something: a standard with several backers, or a Microsoft-only tool, and which of the two it is.

Four kinds of agent

Foundry describes every agent with a kind. The first two are where I would start.

• Prompt agent: instructions, a model and tools, all defined in Foundry. Start here.
• Hosted agent: your own code, running as a container in Foundry.
• Voice agent: a managed agent you talk to. A side trip.
• Workflow: a visual flow of agents. Going away, see below.

Follow the learning path

The best single thing I found is a Microsoft Learn path, Develop AI agents on Azure. It has nine modules and takes about ten hours, and each module ends with a 30-minute lab. I read the module pages, not the labs. It is the nearest thing to an official order, so I would follow it and use my posts and the quickstarts to go deeper.

I liked the Foundry IQ module most. Its sample instructions are a good template for any agent that must answer from documents, and I tested them in Part 5.

The quickstarts, the samples and the templates are for after the path. A quickstart teaches one thing, a sample is code to copy, and a template shows a whole system.

What is going away

Skip these. I confirmed the first two on Microsoft's pages.

The Prompt flow date is stated in the project's own GitHub README. The learning path still has a workflows module, so skip that one. I did not check Microsoft's official retirement list, so confirm a date before you rely on it.

Recap