What Microsoft Agent Framework is
Microsoft Agent Framework is an MIT licensed, open-source SDK and runtime for building and orchestrating agents and multi-agent workflows in .NET and Python. It comes from the teams behind Semantic Kernel and AutoGen and reached its 1.0 release in April 2026. Workflows are graphs with sequential, concurrent, handoff and group collaboration patterns, with checkpointing, streaming, human-in-the-loop control, OpenTelemetry tracing and a middleware system. Agents can also be declared in YAML, and Microsoft documents hosting on Foundry. As of October 2026, Semantic Kernel receives fixes while new feature work happens in Agent Framework, and AutoGen is in maintenance mode, with migration guides for both.
Code-defined workflows versus declared configuration
If you came here searching for AutoGen or Semantic Kernel, the practical comparison today is with Agent Framework, because that is where Microsoft points new projects. It is an SDK: your workflow is code in your service, in your language, and you choose how to host, secure and audit it, with strong support for Azure. EDDI makes the opposite trade. The agent is JSON configuration interpreted by a deployed platform, so behavior can be diffed, reviewed and changed without a rebuild, and the platform supplies the API, Manager UI, secrets vault and audit ledger.
SDK for your service versus platform you deploy
| Dimension | Microsoft Agent Framework | EDDI |
|---|---|---|
| Form factor | SDK and runtime embedded in your .NET or Python service | Deployable middleware on a JVM (Quarkus); runs wherever Docker or Kubernetes runs |
| How agents are defined | Code-defined agents and graph workflows; agents can also be declared in YAML | JSON configuration; deterministic behavior rules decide the next action, LLM calls happen in declared tasks |
| Languages | .NET and Python (Go in a separate repository) | Any language through REST, MCP and the OpenAI-compatible API; the agent itself needs no code |
| License | MIT | Apache 2.0, OSI approved |
| Custom logic at runtime | Your code and tool functions run in your process | No runtime eval() or code execution; logic is declared, or lives behind an MCP tool or HTTP call |
| Human in the loop | Workflow-level human-in-the-loop control | Gates at three levels: turns (PAUSE_CONVERSATION), tool calls (toolApprovals) and group phases, with timeout policies |
| Multi-agent patterns | Sequential, concurrent, handoff and group collaboration in code | Group discussions with 7 styles (round table, peer review, devil's advocate, Delphi, debate, task force, negotiation), recorded decisions and dissent |
| State and recovery | Checkpointing and time-travel in the workflow runtime | Conversation memory persisted by the platform; explicit states such as AWAITING_HUMAN |
| Observability and audit | OpenTelemetry tracing and middleware hooks; where the data goes is up to you | Prometheus metrics plus an HMAC-signed, append-only, sequence-checked audit ledger with a verify endpoint |
| Secrets and identity | Your platform's mechanisms, for example Azure services | Built-in AES-256-GCM Secrets Vault; optional Keycloak/OIDC with eddi-admin and eddi-approver roles |
| Ecosystem fit | Deep Microsoft and Azure integration, including Foundry hosted agents | Vendor-neutral: 19 LLM providers, local models through Ollama or Jlama, 84 MCP tools |
Details about the other tool were checked against its official documentation and repository in October 2026. These projects change quickly, so confirm current behavior with the vendor before you decide.
Choosing between them
Where Microsoft Agent Framework is the better choice
- Your team writes .NET, and the agents belong inside an existing C# service with its own deployment and tests.
- You build on Azure and want first-class integration with Foundry and the surrounding Microsoft services.
- You have Semantic Kernel plugins or AutoGen code, and the supported migration path is cheaper than a platform change.
- The workflow needs control flow that configuration cannot express, such as bespoke graph topologies, checkpoint branching or time-travel debugging.
- You want a developer SDK and prefer to decide for yourself how to host, secure and observe it.
Where EDDI is the better choice
- Agent behavior must be configuration that reviewers can read and promote between environments, with no rebuild.
- A security review will ask what code runs at inference time, and you want the answer to be none in the platform.
- Approvals must exist at the turn, tool call and group-phase level, with a signed record of who decided what.
- You need a ready Manager UI, secrets vault, API and audit ledger instead of assembling them around an SDK.
- You want to stay cloud-neutral: Kubernetes, OpenShift, on-premises or air-gapped with local models.
Moving from AutoGen, Semantic Kernel or Agent Framework
Expect a translation of intent rather than of code. Roles and tools carry over; graph logic becomes behavior rules, and anything that needs real code moves behind an MCP tool or an OpenAPI endpoint.
| Microsoft Agent Framework | EDDI |
|---|---|
| Agent with instructions | EDDI agent with an LLM task and a system message |
| Semantic Kernel plugin or function | MCP tool, or an httpCall or OpenAPI-imported API |
| Workflow graph or AutoGen team | Behavior rules for routing, or a group discussion style for multi-agent work |
| Human-in-the-loop step | PAUSE_CONVERSATION rule, toolApprovals globs, or requiresApproval on a group phase |
| Checkpoint store | Conversation memory with step, conversation and longTerm scopes |
| Middleware and filters | Behavior rules and tool approval policies |
| OpenTelemetry traces | Prometheus metrics and the audit ledger |
Frequently asked
Is Microsoft Agent Framework the replacement for AutoGen and Semantic Kernel?
Microsoft presents it as the successor to both and publishes migration guides. As of October 2026, Semantic Kernel receives fixes while new features land in Agent Framework, and AutoGen is in maintenance mode. If you are starting a new Microsoft-stack project, Agent Framework is the one to evaluate against EDDI.
Can EDDI replace AutoGen for multi-agent conversations?
For many cases, yes. EDDI group discussions cover round table, peer review, devil's advocate, Delphi, debate, task force and negotiation styles, with phases that can require human approval and a recorded decision with dissent. If your agents need free-form code-level coordination, an SDK is the better fit.
Do I have to give up Azure to use EDDI?
No. EDDI supports Azure OpenAI as a provider and runs on Kubernetes, including AKS. It does not provide the deep Azure and Foundry integration that Agent Framework does, so weigh that if you are committed to the Microsoft ecosystem.
Can the two work together?
Yes. EDDI exposes an MCP server, a REST API and an OpenAI-compatible API, and it can consume MCP servers and A2A agents. A .NET service can call EDDI agents as tools, and EDDI can call your service through httpCall.
Other comparisons
- EDDI vs. LangChain and LangGraph
- EDDI vs. CrewAI
- EDDI vs. Dify
- EDDI vs. n8n
- EDDI vs. Flowise
- EDDI vs. Rasa
- All alternatives: builders, libraries, and cloud platforms
Ready for production?
Get managed deployment, SLA-backed support, and hands-on help from the team that builds EDDI.
Talk to us about enterprise deployment