diff --git a/research/microsoft-agent-framework.md b/research/microsoft-agent-framework.md new file mode 100644 index 0000000..50ee306 --- /dev/null +++ b/research/microsoft-agent-framework.md @@ -0,0 +1,158 @@ +--- +title: "Microsoft Agent Framework — Unified SDK for Agents and Multi-Agent Workflows" +author: Ruben Koster (@rkoster) +date: 2026-08-10 +tags: [orchestration, inter-agent-comms, observability-governance, ecosystem-survey] +cf_areas: [] +status: draft +sources: + - https://github.com/microsoft/agent-framework + - https://github.com/microsoft/agent-framework-durable-extension + - https://learn.microsoft.com/en-us/agent-framework/overview/agent-framework-overview + - https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/overview + - https://github.com/microsoft/agent-framework/blob/main/dotnet/samples/02-agents/AgentProviders/dapr/Agent_With_Dapr/README.md + - https://docs.diagrid.io/develop/agents/microsoft/ + - https://github.com/diagridio/dotnet-ai + - https://github.com/diagridio/python-ai +--- + +## Summary + +Microsoft Agent Framework (MAF) is Microsoft's open-source SDK (Python, .NET, and a +public-preview Go binding) for building individual AI agents and graph-based multi-agent +workflows. It is explicitly positioned as "the direct successor" to both +[AutoGen](https://github.com/microsoft/autogen) (multi-agent orchestration abstractions) and +[Semantic Kernel](https://github.com/microsoft/semantic-kernel) (enterprise-grade +state/telemetry/type-safety), built by the same Microsoft teams. It bundles agents, an +opinionated "harness" for long multi-step tasks, and explicit graph-based workflows with +checkpointing, MCP tool integration, and A2A hosting support. Dapr integration turns out to be +richer than it first appears: Microsoft's own sample uses Dapr only narrowly, as a pluggable +inference-backend provider, while its first-party durable-workflow story runs on **Azure +Durable Task Framework** — but a third-party library from **Diagrid** (Dapr's commercial +steward) instead builds MAF agents *directly atop Dapr's own Durable Workflows*, pub/sub, and +state store. + +## Key findings + +- **Explicit AutoGen + Semantic Kernel successor**: the docs state MAF "combines AutoGen's + simple agent abstractions with Semantic Kernel's enterprise features — session-based state + management, type safety, middleware, telemetry — and adds graph-based workflows for explicit + multi-agent orchestration," and provides dedicated + [migration guides from Semantic Kernel](https://learn.microsoft.com/en-us/agent-framework/migration-guide/from-semantic-kernel) + and [from AutoGen](https://learn.microsoft.com/en-us/agent-framework/migration-guide/from-autogen). +- **Three capability tiers**: **Agents** (LLM-driven, call tools/MCP servers, dynamic + step order), an opinionated **Harness** (batteries-included planning/todo-tracking, context + compaction, file access/memory, "don't-ask-again" tool approval, observability for long + multi-step tasks), and **Workflows** (graph of `executors` and `edges` with type-safe + routing — an explicitly-defined, not LLM-improvised, execution path). +- **Orchestration patterns**: workflows support sequential, concurrent, hand-off, group + collaboration, and "magentic" (AutoGen-lineage) multi-agent patterns, plus checkpointing, + streaming, human-in-the-loop gates, and "time-travel" (replay/rewind of workflow state). +- **MCP and multiple model providers**: agents call tools and MCP servers directly, with + provider support spanning Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, Ollama, and + more — the framework is provider-agnostic by design ("provider flexibility so your + architecture can evolve without major rewrites"). +- **A2A and Foundry hosting**: the `04-hosting` samples cover A2A protocol hosting, + "self-hosted protocol helpers," and one-line-ish deployment to Foundry-hosted infrastructure + (see `azure-hosted-agents.md` for the Foundry hosted-agent runtime model this integrates + with, and `a2a-protocol.md` for the protocol itself). +- **Dapr integration exists, but only as an inference-backend provider**: the + [`Agent_With_Dapr`](https://github.com/microsoft/agent-framework/blob/main/dotnet/samples/02-agents/AgentProviders/dapr/Agent_With_Dapr/README.md) + sample uses Dapr's **Conversation API** building block (`Dapr.AI.Microsoft.Extensions`, + `AddDaprChatClient`) to route an agent's LLM calls through the Dapr sidecar to a + `conversation.*` component (e.g. `conversation.ollama`) instead of calling a model + provider's SDK directly. This buys provider portability (swap the backing LLM by swapping + the Dapr component, not the app code) and built-in response caching (`cacheTTL` on the + component). It is listed as one of a dozen-plus interchangeable "AgentProviders" (alongside + OpenAI, Azure, Anthropic, Ollama, ONNX, GitHub Copilot, A2A, etc.) — i.e. Dapr is treated as + a model-backend abstraction, not as MAF's orchestration or state substrate. +- **Durable *workflow* execution is via Azure Durable Task Framework, not Dapr**: separately + from the inference-provider integration above, durability, restartability, and long-running + workflow state for MAF's **Workflows** feature are delivered by a distinct + [`agent-framework-durable-extension`](https://github.com/microsoft/agent-framework-durable-extension) + repo, built on the **Durable Task Scheduler** (Azure Durable Functions' backing engine), + Azurite (Azure Storage emulator), and Redis — with Azure Functions as a hosting option. No + Dapr Workflows/Actors integration is mentioned for this layer in the MAF README, the durable + extension repo, or the Microsoft Learn overview/workflow docs as of this research. This makes + MAF's *workflow durability* story architecturally distinct from **Dapr Agents** (see + `dapr-agents.md`), which is Dapr-native end-to-end (uses Dapr Workflows/Actors/state stores + directly for both the agent loop and durability) — MAF only touches Dapr at the model-call + edge, and ties its actual durability substrate to the Azure Durable Task ecosystem instead. +- **...unless you use Diagrid's Dapr-native durability layer for MAF**: Diagrid (the company + founded by Dapr's original creators, and its primary commercial steward) publishes + [`diagridio/dotnet-ai`](https://github.com/diagridio/dotnet-ai) (`Diagrid.AI.Microsoft.AgentFramework` + on NuGet) — "a library that facilitates building agents using Microsoft's Agent Framework + atop Dapr's Durable Workflows." This wraps MAF agent tasks in Dapr Workflows for automatic + retries/checkpointing/crash recovery, uses Dapr pub/sub to decouple multi-agent + communication, and uses a Dapr state store to persist chat memory across restarts — i.e. the + complete Dapr-native durability story (workflows + actors/state + pub/sub) that Microsoft's + own `agent-framework-durable-extension` does *not* provide. It reuses the same Conversation + API mechanism as Microsoft's own sample (`AddDaprConversationClient()` + + `conversationComponentName`), and per Diagrid's docs a conversation component is *required*, + not optional, for this integration. This is a **third-party, Dapr-ecosystem-provided** + durability path, not something shipped or endorsed in the core `microsoft/agent-framework` + repo itself. +- **...but not on the Python side**: Diagrid's Python counterpart, + [`diagridio/python-ai`](https://github.com/diagridio/python-ai) (pip package `diagrid`, part + of the "Diagrid Catalyst" managed Dapr Workflow product), wraps **eleven** other agent + frameworks in Dapr Workflows — LangGraph, CrewAI, Google ADK, Strands, PydanticAI, OpenAI + Agents, Claude Agent SDK, LangChain, Smolagents, LangChain Deep Agents, and HolmesGPT — but + conspicuously **not** Microsoft Agent Framework's Python binding, even though the .NET + binding is covered by `dotnet-ai`. So the Dapr-native durability path for MAF is currently + .NET-only; Python MAF users have no equivalent, despite Diagrid actively building out + framework coverage elsewhere. This also reveals Diagrid's play more broadly: a + framework-agnostic "bring your own agent framework, we supply the Dapr-backed durability" + product, positioning Dapr Workflows as a universal durability substrate across the wider + agent-framework ecosystem, not just Dapr's own `dapr-agents` or MAF specifically. +- **Observability built on OpenTelemetry**: "Built-in OpenTelemetry integration for + distributed tracing, monitoring, and debugging" is listed as a first-class feature, with + dedicated Python and .NET observability samples, though the README does not explicitly cite + the GenAI semantic conventions by name (see `opentelemetry-genai.md`) — worth confirming + whether MAF's span attributes actually conform to that spec. +- **Declarative agents**: agents can be defined in YAML "for faster setup and versioning," + suggesting a config-driven deployment path that could matter for platform-level agent + packaging, similar in spirit to a buildpack/manifest model. +- **Positioning vs. LangGraph/CrewAI**: the README doesn't directly benchmark against + LangGraph or CrewAI, but the "Is this the right framework for you?" section reads as an + implicit contrast — MAF pitches itself at production use requiring durability, + restartability, governance, and human-in-the-loop control, beyond a "stateless chat loop." + +## CF relevance + +MAF is a strong signal of where enterprise agent frameworks are converging: agents, explicit +workflow graphs, tool/MCP integration, and A2A as the default set of primitives. The three-way +split between Microsoft's own durability path (Azure Durable Task Framework), Microsoft's own +Dapr touchpoint (Conversation API only), and Diagrid's third-party Dapr-native durability layer +(Dapr Workflows + pub/sub + state store, .NET-only for MAF) is a useful data point for CF: it +shows a mature framework's durability substrate is *not* fixed to one vendor's stack — the +ecosystem, not just the framework author, can supply the durability/state layer, and a single +vendor (Diagrid) is actively productizing "durability-as-a-service" across a dozen-plus +competing agent frameworks. That decoupling (agent framework vs. durability substrate vs. +inference-backend abstraction, as three independently swappable concerns) may be a more useful +design reference for CF than any single implementation. The declarative YAML agent definitions +and Foundry one-line hosting also raise the recurring question from other notes: what would a +CF-native "agent packaging" story (buildpack, manifest, or droplet analogue) look like for +MAF-style agents. + +## Open questions + +- Does MAF's OpenTelemetry instrumentation actually conform to the GenAI semantic + conventions, or is it a custom schema (see `opentelemetry-genai.md`)? +- Why does Microsoft's own first-party durability extension not use Dapr, when a third party + (Diagrid) has already built a working Dapr Workflows-based alternative? Is this organizational + (different teams, Azure-first bias) or a deliberate technical preference? +- How mature/supported is Diagrid's `dotnet-ai` integration compared to Microsoft's own + `agent-framework-durable-extension` — is it production-grade, or a demonstration/marketing + vehicle for Dapr? And why does `python-ai` cover eleven other frameworks but not MAF's Python + binding — is MAF-Python support simply not built yet, or deliberately deprioritized? +- How does MAF's A2A hosting story compare to Azure Foundry's native A2A support + (`azure-hosted-agents.md`) — is A2A exposed identically regardless of hosting target? +- If CF wanted to host MAF-based agents, would the Durable Task Scheduler dependency (Azure + Storage emulator/Azurite, Redis) need a CF-native substitute — or could the Dapr-native path + (Diagrid's library) be used instead, making Dapr (already covered in `dapr.md`) sufficient + infrastructure for both the durability layer and the inference-backend abstraction? Would CF + be better served by a Diagrid-style "durability-as-a-service" layered under many frameworks + rather than betting on one framework's built-in durability story? +- How does the "Harness" (planning, context compaction, memory, tool approval) compare to + similar batteries-included agent runtimes elsewhere in this research set — is this a + reusable pattern platforms should expect to support generically?