From b5a5876289dec9d260d94e511e480ae6db66dec0 Mon Sep 17 00:00:00 2001 From: rkoster Date: Mon, 10 Aug 2026 11:28:34 +0200 Subject: [PATCH 1/3] Add research note: Microsoft Agent Framework --- research/microsoft-agent-framework.md | 101 ++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 research/microsoft-agent-framework.md diff --git a/research/microsoft-agent-framework.md b/research/microsoft-agent-framework.md new file mode 100644 index 0000000..8b67c50 --- /dev/null +++ b/research/microsoft-agent-framework.md @@ -0,0 +1,101 @@ +--- +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 +--- + +## 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 — but notably, its durable/stateful +execution story runs on **Azure Durable Task Framework**, not Dapr. + +## 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). +- **Durable execution is via Azure Durable Task Framework, not Dapr**: durability, + restartability, and long-running workflow state are delivered by a separate + [`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. + Despite the assumption that Microsoft would lean on Dapr (its own CNCF sandbox project) for + this, no Dapr integration is mentioned anywhere in the MAF README, the durable extension + repo, or the Microsoft Learn overview/workflow docs as of this research. This makes MAF's + durability story architecturally distinct from **Dapr Agents** (see `dapr-agents.md`), which + is Dapr-native (uses Dapr Workflows/Actors/state stores directly) — MAF instead ties its + durability substrate to the Azure Durable Task ecosystem. +- **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. Its choice to +build durability on Azure's own Durable Task substrate (rather than Dapr, a CNCF project +Microsoft also stewards) is a useful data point when comparing execution-substrate options for +CF — it suggests durable agent execution doesn't require Dapr specifically, just *some* +workflow/checkpoint engine, which could be Diego-native, Temporal, Dapr, or otherwise. 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`)? +- Is the lack of Dapr integration a deliberate architectural choice (avoiding a dependency on + a separate runtime) or simply not-yet-built? Worth revisiting as the durable extension + matures. +- 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 can it run against + self-hosted/OSS-compatible backends off Azure? +- 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? From 4ef4429da3744e79bd99c8cf97382e5fd59812a9 Mon Sep 17 00:00:00 2001 From: rkoster Date: Mon, 10 Aug 2026 14:20:44 +0200 Subject: [PATCH 2/3] Correct Dapr integration findings in MAF note Microsoft's own MAF sample does integrate with Dapr (Conversation API as an inference-backend provider), contradicting the earlier claim that no Dapr integration exists. Additionally, Diagrid (Dapr's commercial steward) publishes a third-party library (diagridio/dotnet-ai) that builds MAF agents directly atop Dapr Workflows, pub/sub, and state store for durability - a more complete Dapr-native durability story than Microsoft's first-party Azure Durable Task Framework extension provides. --- research/microsoft-agent-framework.md | 86 ++++++++++++++++++++------- 1 file changed, 63 insertions(+), 23 deletions(-) diff --git a/research/microsoft-agent-framework.md b/research/microsoft-agent-framework.md index 8b67c50..ffa930e 100644 --- a/research/microsoft-agent-framework.md +++ b/research/microsoft-agent-framework.md @@ -10,6 +10,9 @@ sources: - 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 --- ## Summary @@ -21,8 +24,12 @@ workflows. It is explicitly positioned as "the direct successor" to both [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 — but notably, its durable/stateful -execution story runs on **Azure Durable Task Framework**, not Dapr. +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 @@ -48,17 +55,42 @@ execution story runs on **Azure Durable Task Framework**, not Dapr. "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). -- **Durable execution is via Azure Durable Task Framework, not Dapr**: durability, - restartability, and long-running workflow state are delivered by a separate +- **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. - Despite the assumption that Microsoft would lean on Dapr (its own CNCF sandbox project) for - this, no Dapr integration is mentioned anywhere in the MAF README, the durable extension - repo, or the Microsoft Learn overview/workflow docs as of this research. This makes MAF's - durability story architecturally distinct from **Dapr Agents** (see `dapr-agents.md`), which - is Dapr-native (uses Dapr Workflows/Actors/state stores directly) — MAF instead ties its - durability substrate to the Azure Durable Task ecosystem. + 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. - **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 @@ -75,27 +107,35 @@ execution story runs on **Azure Durable Task Framework**, not Dapr. ## 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. Its choice to -build durability on Azure's own Durable Task substrate (rather than Dapr, a CNCF project -Microsoft also stewards) is a useful data point when comparing execution-substrate options for -CF — it suggests durable agent execution doesn't require Dapr specifically, just *some* -workflow/checkpoint engine, which could be Diego-native, Temporal, Dapr, or otherwise. The +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) 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. 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. +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`)? -- Is the lack of Dapr integration a deliberate architectural choice (avoiding a dependency on - a separate runtime) or simply not-yet-built? Worth revisiting as the durable extension - matures. +- 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? Does an equivalent exist for MAF's Python binding, + or is this .NET-only? - 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 can it run against - self-hosted/OSS-compatible backends off 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? - 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? From dfad33620ba6617163579db25ff2ac4804442052 Mon Sep 17 00:00:00 2001 From: rkoster Date: Mon, 10 Aug 2026 14:26:33 +0200 Subject: [PATCH 3/3] Note that Diagrid's Dapr durability layer for MAF is .NET-only diagridio/python-ai wraps 11 other Python agent frameworks (LangGraph, CrewAI, ADK, Strands, PydanticAI, OpenAI Agents, Claude Agent SDK, LangChain, Smolagents, LangChain Deep Agents, HolmesGPT) in Dapr Workflows, but does not cover Microsoft Agent Framework's Python binding - only dotnet-ai does. Updates key findings, CF relevance, and open questions accordingly. --- research/microsoft-agent-framework.md | 41 +++++++++++++++++++-------- 1 file changed, 29 insertions(+), 12 deletions(-) diff --git a/research/microsoft-agent-framework.md b/research/microsoft-agent-framework.md index ffa930e..50ee306 100644 --- a/research/microsoft-agent-framework.md +++ b/research/microsoft-agent-framework.md @@ -13,6 +13,7 @@ sources: - 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 @@ -91,6 +92,18 @@ state store. 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 @@ -110,14 +123,16 @@ MAF is a strong signal of where enterprise agent frameworks are converging: agen 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) 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. 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. +(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 @@ -127,15 +142,17 @@ or droplet analogue) look like for MAF-style agents. (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? Does an equivalent exist for MAF's Python binding, - or is this .NET-only? + `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? + 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?