LangGraph vs Microsoft Agent Framework: Design Your State First, or Discover It Later

At some point in building an agentic system, you will hit the same wall. An agent workflow needs to pause, wait for a human decision, and resume. The implementation seems straightforward but then you realise: what happens to the state during the pause? Where does it live? Who owns it? How does the resumed execution know what it was doing?

That question is where LangGraph and Microsoft Agent Framework make fundamentally different architectural choices. Everything else, the feature comparison, the ecosystem fit, the vendor landscape, follows from how each framework answers it.

The received wisdom is that LangGraph is for Python teams and Microsoft Agent Framework is for Microsoft shops. This is roughly true, but it is also the least interesting thing about either framework.

Both now offer graph-based workflows, typed nodes and edges, checkpointing, human-in-the-loop interruption, multi-agent orchestration, and MCP tool support. The feature table between them is, at this point, nearly identical. Comparing features tells you almost nothing about which one will produce a maintainable system twelve months from now.

The question worth asking is not “which framework has the features I need?” Both do. The question is: when does your system have to know what its state looks like?

In LangGraph, the answer is before the first line of agent code runs. In Microsoft Agent Framework, the answer is whenever you decide it matters.

Call it the state contract; LangGraph makes you sign it at design time while MAF lets you negotiate it later. These positions, therefore, produce different systems and different failure modes.

In LangGraph, you define a typed state schema before anything else. Every node in the graph receives that state and returns a partial update. The compiled graph, not the node functions, owns the execution model. You cannot compile without a schema; you cannot run without compiling.

The example below is a three-step document review pipeline: an AI reviewer reads the document, a human approves or rejects it, and the result routes to publish or reject. In LangGraph, the shape of the data flowing through those steps is the first thing you write.

Before a single prompt fires, you have defined exactly what flows through this system: a document and a decision. When the graph hits interrupt(), it serialises the full state to the checkpointer and halts. The caller retrieves the saved state, presents it to a human, and resumes execution by passing the decision back in. The graph picks up from the exact checkpoint, with all prior state intact.

The cost of explicit; you cannot prototype quickly without thinking about state. On a trivial workflow, the schema ceremony could appear as disproportionate.

Microsoft Agent Framework separates two concepts from the start: an Agent that drives autonomous, LLM-guided behaviour, and a Workflow that enforces a deterministic execution path.

The same three-step document review pipeline looks like this in MAF. An Executor is MAF’s equivalent of a LangGraph node: a typed processing unit that receives a message, does work, and forwards a result. WorkflowBuilder wires executors together with edges.

Notice what is absent: a state schema. The data contract between executors is the message type passed between them, not a shared typed dict declared before anything runs.

For human-in-the-loop, MAF uses a different model than LangGraph’s checkpoint-and-pause. Rather than halting in-place, the workflow emits an event and you re-run it with the human’s response. Using SequentialBuilder with with_request_info, a pipeline pauses after a nominated agent runs, surfaces its output for human review, and resumes when you feed the response back in:

The emit-and-rerun model is a genuine architectural difference from LangGraph’s interrupt. LangGraph’s state is serialised at the exact point of pause and restored on resume: the graph does not restart, it continues. MAF’s request-response model re-runs the workflow from the current position with the human response as an input. For most approval workflows the behaviour looks the same from the outside. For long-running workflows with complex branching, the difference in how state is maintained across the pause matters more.

The appeal of MAF’s layered approach is real; build the agent behaviour first, run it, understand what actually flows through the system, and _then _add workflow structure once you know what it needs to look like. No schema ceremony on day one.

However, the cost of this position may surface later in a complex production system; needing a workflow that coordinates multiple agents, each maintaining its own session state, and you need consistent state across a human approval step; you will be working across two abstractions that were designed separately. It is possible, but is more work than it looks on day one.

Most comparisons describe LangGraph as steep and MAF as approachable. This is accurate for the first week of development and inaccurate for the first six months.

LangGraph’s learning cost concentrates at the start. There are four concepts to internalise:

• the state schema and how reducers merge concurrent updates;

• the compiled graph as a distinct artefact from the node functions;

• the checkpointer pattern and how thread IDs isolate independent conversations; and

• conditional edges versus routing functions.

These are genuinely non-obvious the first time. Once learned, the model is consistent everywhere. A LangGraph graph written by someone else is readable without context because the state contract is explicit and the execution path can be traced from the compiled artefact before running a single call.

MAF’s learning cost distributes differently. The simple agent is genuinely simple. The workflow API is learnable. The composition challenge, combining an autonomous agent with checkpointed workflows and multi-step human approval inside a single pipeline, arrives later and hits harder. The migration guides from AutoGen and Semantic Kernel exist precisely because neither of those predecessor APIs composed cleanly either. Microsoft unified them in part to solve this problem; how well the composition works in practice is still being tested in production.

The practical upshot is if you prototype a simple agent in both frameworks today, MAF will feel faster. If you build a complex production workflow in both frameworks over three months, LangGraph will have fewer surprises. The inflection point depends on how complex your workflow actually is. For most workflows that require branching, human approval, and fault recovery, it arrives before month three.

LangGraph has a substantially larger open-source community, a deeper ecosystem of integrations, and a set of verified production deployments at scale. Python is the dominant language in AI development and LangGraph is Python-first. Community answers are easier to find. The production evidence, from companies running agent workloads against tens of millions of users, exists and is documented.

MAF is backed by Microsoft. This matters in specific contexts: a documented migration path from AutoGen and Semantic Kernel brings existing practitioners in without a full rewrite; the Azure AI Foundry integration is the default agentic path for teams in the Azure ecosystem; and enterprise procurement conversations are easier when the framework vendor can offer a support contract.

Neither of these is a technical argument, but they are arguments about where default momentum points when a team is choosing a framework without strong prior opinions. For Python-first AI teams without Azure commitments, the momentum is toward LangGraph. For teams inside the Azure ecosystem or migrating from predecessor Microsoft frameworks, it is toward MAF. That is not a reason to override the architectural fit assessment; it is a reason to notice where friction will be lower.

There is one question that is more predictive than any feature comparison:

when you build a system, do you prefer to define the schema first and let the implementation follow, or do you prefer to build the implementation and formalise the schema once you know what it needs to be?

If you are a schema-first developer, LangGraph fits your mental model. The state contract is not overhead; it is how you think. The compiled graph is a readable specification. The investment in state design up front pays back in debugging, resumability, and the ability to hand the codebase to a new engineer without a lengthy explanation.

If you are a behaviour-first developer, MAF’s layered approach fits you better. Build the agent, run it, understand what it actually does, then add workflow structure where the process needs it. The simple agent requires no architecture decisions at all to start.

The ecosystem considerations are secondary to this. Teams have shipped complex agentic systems with both frameworks in both the Python and .NET ecosystems. The architectural fit determines whether the system is a joy or a grind to maintain. The ecosystem determines where you will find help when you get stuck. Both matter, and they matter in that order.

Published earlier in dev.to