# Agent Frameworks: MAF vs AutoGen vs LangGraph vs Prompt Flow

*Published 2025-10-24 · Dmitry Shirokov · shirokoff.ca/blog/agent-frameworks-compared · as of late October 2025*

Three weeks after a client signed off on a multi-agent design built on AutoGen group chat, Microsoft shipped the **Microsoft Agent Framework** and put AutoGen *and* Semantic Kernel into maintenance mode. Three weeks later LangChain and LangGraph hit 1.0. The client asked: do we rewrite? Answering it properly means being precise about lock-in. **An agent framework is three separable things — an orchestration model, a runtime/hosting story, and integrations. Integrations are commodity, the runtime is replaceable, and the orchestration model is what you're marrying.**

## What happened, in dates

- **Oct 1, 2025** — Microsoft Agent Framework (MAF) enters public preview: Python + .NET, merging AutoGen's agent/multi-agent abstractions with Semantic Kernel's plugin model, connectors, and telemetry. **AutoGen and Semantic Kernel move to maintenance mode** — security and bug fixes, no new features.
- **Oct 22, 2025** — **LangChain 1.0** and **LangGraph 1.0** GA. `create_agent` supersedes `create_react_agent`, plus a middleware model; LangGraph is the durable runtime underneath. No breaking changes promised until 2.0.
- **Azure Prompt Flow** — no announcement, which is its own signal. Supported, in hub-based Foundry projects and Azure ML, plainly not where the investment is going.

Short version of my advice: **new .NET/Azure work → MAF, accepting preview churn; new Python work needing durability → LangGraph 1.0; nothing new on Prompt Flow; don't rewrite a working AutoGen system this quarter.**

## The four orchestration shapes

1. **Static DAG** — you decide every step (Prompt Flow).
2. **Single-agent tool loop** — the model decides when to call tools (Semantic Kernel, `create_agent`).
3. **Multi-agent conversation** — agents decide by talking (AutoGen).
4. **Graph state machine** — *you keep the map, the model picks the route* (LangGraph, MAF workflows).

Shape 4 is where serious production work lands, because bounded autonomy is what survives a compliance review. Forcing a problem into the wrong shape is where agent projects die.

## What each one is

**Azure Prompt Flow** — a visual/YAML DAG authoring tool for LLM pipelines with batch runs and built-in evaluation flows, deployable to a managed online endpoint. Its evaluation story was ahead of its time and is still the best reason to use it. Structural limits: a DAG can't loop, so a tool-calling agent is outside the paradigm; control flow lives in designer-owned YAML that diffs and tests badly; tied to hub-based projects. Have one doing non-agentic RAG? Leave it. New work: plain Python plus a separate eval harness.

**AutoGen** — multi-agent framework where work happens through conversation (planner ↔ coder ↔ critic, group-chat manager choosing speakers). The 0.4 rewrite made it async and event-driven with a layered core/AgentChat/extensions design. Great for exploring patterns in an afternoon; hard to bound, hard to make deterministic, hard to explain to a risk committee. Now capped.

**Semantic Kernel** — enterprise SDK: kernel, plugins (native + prompt functions), filters, connectors, .NET-first with real DI and telemetry. Agent abstractions always felt bolted on. Also capped — but its plugin model is the part that survives, inside MAF.

**Microsoft Agent Framework** — the convergence. What matters, in order: **workflows** (typed, checkpointable graph orchestration), **OpenTelemetry** observability following the GenAI semantic conventions, **Python + .NET on one model** (fewer architectures for enterprises with a Python data platform and .NET services), **MCP and agent-to-agent interop** first-class, and a hosting path into Foundry Agent Service. Catch: it's preview — APIs will move, docs run ahead of samples, migration guides from AutoGen/SK are the thinnest part. Build on it for work shipping next quarter, not for a fixed-price API-surface commitment.

**LangChain 1.0 / LangGraph 1.0** — LangGraph is a durable runtime for stateful agent graphs: persisted state, checkpointers that survive process restarts, interrupts that pause for a human and resume exactly where they stopped. LangChain 1.0 is the model/tool/message layer on top with `create_agent` and middleware. Durability is the differentiator, and checkpoint + interrupt is the cleanest real human-approval mechanism I know — if your agent touches money, health data, or anything irreversible, that's not a nice-to-have. Trade-off: the state schema and graph *are* your application structure. Fair when you use what it gives you; a bad trade for a single tool-calling agent a fifty-line loop would handle.

## Side by side

| Framework | Shape | Languages | Durability | Status Oct 2025 | Reach for it when |
|---|---|---|---|---|---|
| Prompt Flow | Static DAG | Python | None | Supported, no investment signal | You already have one |
| AutoGen | Multi-agent conversation | Python (.NET partial) | You persist it | **Maintenance mode** | Exploring patterns fast |
| Semantic Kernel | Tool loop + plugins | .NET, Python, Java | You build it | **Maintenance mode** | Already in production |
| Microsoft Agent Framework | Tool loop + multi-agent + workflows | Python, .NET | Workflow checkpointing | **Public preview** | New Azure/.NET work |
| LangGraph 1.0 | Graph state machine | Python, JS/TS | **First-class** | **GA**, stable to 2.0 | Long-running, resumable, approvals |
| LangChain 1.0 | Tool loop + middleware | Python, JS/TS | Via LangGraph | **GA** | Fast start, model portability |

## What actually locks you in

| What | Portability | Why |
|---|---|---|
| Tool implementations | Free | Plain functions — *if* you wrote them that way |
| Prompts and instructions | Nearly free | Strings; copy-paste plus retest |
| Model/provider config | Cheap | Rewrite the initialization |
| Observability wiring | Medium | Cheap on OpenTelemetry, expensive on proprietary callbacks |
| **Orchestration graph + state schema** | **Expensive** | This is the application; frameworks disagree about what state *is* |
| **Persisted memory / checkpoint format** | **Expensive — and it has data** | You can rewrite code; you can't re-shape a million rows of in-flight state |

So: keep the top four fat and the bottom two thin. Domain tools as plain functions with docstrings and **zero framework imports**, plus a ~10-line adapter per framework that registers them. Looks like over-engineering right up until a vendor reorganizes their SDKs. Expose tools over **MCP** and any framework — including the one that replaces your pick — can consume them.

## Choosing

Needs to survive a restart or pause for a human → **LangGraph 1.0** (GA today). Otherwise: .NET or .NET+Python → **MAF**. Python, Azure-committed, shipping this quarter with an SLA → Semantic Kernel or plain SDK calls, migrate to MAF later. Python, cloud-agnostic → LangChain `create_agent`. And the branch I use most: **is it really an agent, or a pipeline?** No loop, no tool selection, no autonomy → three hundred lines of Python with a test suite, cheaper and more reliable than any framework.

On migration: a working AutoGen system in maintenance mode is **not an emergency** — security fixes continue and the code still runs. Rewriting onto a preview framework trades known risk for unknown risk on someone else's schedule. What I told the client: keep the prototype, extract tools into framework-free modules this sprint (a week, useful regardless), build the *next* agent on MAF, revisit porting when MAF is GA and the migration guides are more than a page. Port the multi-agent conversation piece last and test it hardest — that's what the two frameworks model most differently.

## Two traps

**The preview trap** — no SLA, API churn, no support story. A preview SDK's breaking change once ate two days of a delivery week: survivable internally, unacceptable on a fixed-price milestone. **Don't let the framework own your state** — conversation history, memory, and in-flight workflow position are your application's data. Living only inside a checkpoint format turns "switch frameworks" from a refactor into a data migration. Persist what you'd need to reconstruct a session in a schema you control, even when the framework persists its own.

## Carry-away

The orchestration model is the commitment; everything else is plumbing. MAF is the right bet for new Azure/.NET work if you can absorb churn — the workflow model and OpenTelemetry story are the substance. LangGraph 1.0 is the right bet when durability is the requirement. If your "agent" is a pipeline, write the pipeline. And structure code so next month's announcement is an adapter change: plain-function tools, MCP where possible, state in a schema you own, telemetry via OpenTelemetry. Two of the four frameworks here changed status in three weeks — the teams that shrugged were the ones whose agents were mostly their own code.

*Related: [What MCP standardizes](https://shirokoff.ca/blog/model-context-protocol) · [Airflow vs Prefect vs Dagster](https://shirokoff.ca/blog/airflow-prefect-dagster-orchestration) · [Azure ML MLOps in production](https://shirokoff.ca/blog/azure-ml-mlops-production) · [MLflow tracking and registry](https://shirokoff.ca/blog/mlflow-experiment-tracking-registry)*