What Microsoft Actually Ships for a Private Multi-Agent Framework

What people mean by a private multi-agent framework

A search for a private multi-agent framework from Microsoft is really a search for one of three separate things, and mixing them up is the fastest way to end up reading the wrong page.

The first is AutoGen, Microsoft Research's original framework for agents that solve a task by talking to each other. The second is Semantic Kernel, an older and separate SDK built for orchestrating LLM calls inside an enterprise app. The third is the Microsoft Agent Framework, the newer SDK that folds the first two together and is where Microsoft is putting its development effort now.

None of the three ships the word private in its name, and none of them is a vault. Privacy, when it shows up at all, comes from a separate decision you make about where you deploy and how you store your keys.

• AutoGen: the original multi-agent conversation framework, from Microsoft Research.
• Semantic Kernel: an older, enterprise-focused orchestration SDK.
• Microsoft Agent Framework: the current SDK that merges both.

AutoGen: where Microsoft's multi-agent work started

AutoGen is the framework behind the arxiv paper a lot of private multi agent framework arxiv searches are actually looking for. Microsoft Research published it in October 2023, and the accompanying paper, AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, is on arxiv as 2308.08155. It won the best paper award at the ICLR 2024 LLM Agents Workshop.

The idea is agents that solve a problem by talking to each other in a structured conversation. An AssistantAgent proposes code or an answer, a UserProxyAgent can run that code or ask a human for input, and a GroupChat lets several agents take turns in the same conversation instead of one agent doing everything alone.

As of 2026, Microsoft has moved AutoGen into maintenance mode. It still runs and is still supported, but new multi-agent features land in the Microsoft Agent Framework, not here.

• Published by Microsoft Research in October 2023.
• Paper: AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, arxiv 2308.08155.
• Core pattern: an AssistantAgent, a UserProxyAgent, and a GroupChat for multi-agent turns.
• Status in 2026: maintenance mode, not the place to start a new project.

Semantic Kernel: the enterprise half, still very much alive

Semantic Kernel predates the current wave of multi-agent interest. It treats a call to a language model as one more function your program can invoke, alongside your own code, which made it a natural fit for enterprise apps that needed an LLM to do one task inside a bigger system rather than run the whole show.

Semantic Kernel is not deprecated. Microsoft's own guidance is a gradual migration toward the Agent Framework, and Semantic Kernel keeps running underneath it as a foundation layer rather than disappearing.

• Treats an LLM call as a plugin function, not a standalone agent loop.
• Not deprecated: Microsoft recommends a gradual migration, and SK still works underneath the newer framework.

The Microsoft Agent Framework: where the two converge

The Microsoft Agent Framework is the open-source SDK and runtime that converges AutoGen and Semantic Kernel into one codebase. It entered public preview on October 1, 2025, and reached general availability, version 1.0, on April 3, 2026, with stable APIs in both Python and .NET, under the MIT license.

Architecturally it separates agents, the stateful units that actually do the work, from workflows, the graph that decides which agent runs next. That split is new: neither AutoGen nor Semantic Kernel had it on its own.

It also speaks the protocols other agent ecosystems use: OpenAPI for calling existing services, Agent2Agent (A2A) for talking to agents built on other frameworks, and the Model Context Protocol (MCP) for connecting tools. None of those are unique to Microsoft, which is the point: an agent built on this framework is not stuck only talking to other Microsoft agents.

• Public preview: October 1, 2025. General availability (v1.0): April 3, 2026.
• Open source, MIT licensed, with stable Python and .NET APIs at GA.
• Separates stateful agents from the graph-based workflow that orchestrates them.
• Supports OpenAPI, Agent2Agent (A2A), and the Model Context Protocol (MCP).

Where the private and vault part of the search actually comes from

None of the three frameworks ships its own secrets store. Whatever credential an agent needs, a model API key, a database password, a cloud token, has to come from somewhere, and Microsoft's own documentation points at the same answer it gives any Azure-hosted app: put it in Azure Key Vault and have the agent pull it at the moment it runs, instead of writing it into a config file or an environment variable that sits on disk.

That is the vault half of a search like vault multi agent framework ai private. It is not a feature of AutoGen, Semantic Kernel, or the Agent Framework specifically. It is the ordinary Azure pattern for keeping a secret out of source control, applied to an agent the same way you would apply it to any other service.

If what you actually need is enterprise-wide governance rather than a single key, that is a different layer: Foundry Agent Service, the production side of Azure AI Foundry, adds identity checks, lifecycle control and an audit trail once you deploy an agent there. It only applies after deployment. While you are still writing and testing the agent, you are managing your own keys.

• No framework here ships its own vault; the standard answer is Azure Key Vault.
• Pull a credential at the moment a command needs it, rather than storing it in a file.
• Foundry Agent Service adds governance and an audit trail once an agent is deployed, a separate layer from where you keep a key.

Is there actually a research paper on a private multi-agent framework

Not under that exact name. The paper most private multi agent framework arxiv searches are looking for is almost certainly AutoGen's, which never claims privacy as its subject; it is about getting agents to coordinate, not about encrypting what they say to each other.

Privacy-preserving multi-agent LLM systems, agents that share a task without exposing each other's private context, is a real and active academic question, but it is a research topic, not a Microsoft product. A page claiming Microsoft ships a framework built specifically around that guarantee does not hold up; treat it as marketing, not as a citation.

• AutoGen's paper (arxiv 2308.08155) is the one most searches land on, and it is not about privacy guarantees.
• Privacy-preserving multi-agent coordination is an open research area, not a shipped Microsoft product.

Which one to actually start with

For a new project in 2026, start with the Microsoft Agent Framework. It is the one still getting new features, and it is where Microsoft's own documentation and samples now point.

If you already have a Semantic Kernel app that works, there is no deadline forcing you off it. Migrate toward the Agent Framework when a specific feature pulls you there, not because SK is going away; it isn't.

If you already have an AutoGen app, the calculation is different: it still runs, but it will not gain the newer protocol support, such as A2A or MCP, that ships with the Agent Framework, so plan a migration path even if you are not doing it today.

• New project: Microsoft Agent Framework.
• Existing Semantic Kernel app: no rush, migrate gradually.
• Existing AutoGen app: still works, but plan ahead since new protocol support lands in the Agent Framework, not here.

If you're prototyping one of these on your own machine

None of AutoGen, Semantic Kernel, or the Agent Framework ship a desktop supervisor, and nothing here wires Forkbench into any of them. This section is about the ordinary problem of running a Python or .NET script on your own laptop, not an integration.

Before an agent you built on one of these frameworks ever reaches Azure AI Foundry, it is a local process, and a local process can read anything your account can read. A key sitting in a .env file next to the script is as readable by that script as by you.

Forkbench is a Mac app that runs that script in a real terminal, keeps the key in the macOS Keychain, and lets a command use it by name instead of writing it into the project folder. That only covers your own Mac while you are developing. Once the agent is deployed to Azure, Foundry's own governance tools are the layer doing the work, and Forkbench has nothing to do with that part.

• No framework here ships a desktop supervisor, and Forkbench has no integration with any of them.
• On your own machine, a local process can still read any key left in a plain file.
• Forkbench keeps a key in the Keychain and releases it by name, for the local half only.