agent-framework vs crewAI: a graph framework with durability machinery against role-based crews and flows

A graph of named patterns against crews and flows

agent-framework's model is a graph. Its workflow layer offers named patterns, sequential, concurrent, handoff and group collaboration, plus checkpointing, streaming, human-in-the-loop and time-travel, and the samples under python/samples/03-workflows/ show what each one looks like. An agent is a node, the edges are how control moves, and middleware wraps the request path.

crewAI's model is two abstractions, and the README is explicit about the division. Crews are for autonomy and collaborative intelligence with role-based agents. Flows are for event-driven automations that combine precise workflow control, single LLM calls and native support for Crews. A Flow can call a Crew, so the two are meant to nest rather than to compete.

The difference is where the coordination logic lives. In agent-framework the logic is in the graph, which means the graph is the thing you design, test and read. In crewAI it is split between the agents' own behaviour, described by role, goal and backstory, and the Flow that sequences them, so you hold two pictures at once. Our analysis of crewAI says to skip it if your team cannot handle the learning curve of two distinct abstractions, and that is the difference in one sentence.

Middleware and YAML against roles, goals and backstories

agent-framework lets you shape an agent from outside the code. A middleware system sits on the request and response path for processing, exception handling and custom pipelines, which is where cross-cutting concerns such as logging, retries or redaction belong. There is also a declarative path, with agents defined in YAML and samples under declarative-agents/, so a definition can be reviewed and versioned without a Python file.

crewAI's shape is richer in one direction and simpler in another. An agent is configured with a role, a goal and a backstory, and a task is written as a description with dependencies and expected output. Structured output is a first-class option rather than a parsing exercise, since tasks can declare output_pydantic or output_json, and human review can be inserted into a task. Our analysis of crewAI lists the same knobs: role, goal, backstory, tools, LLMs, memory and guardrails for an agent, dependencies, structured output and human review for a task.

The comparison is really about where your rules live. If a policy applies to every call the agent makes, middleware is the better model. If a policy belongs to a role or to one piece of work, crewAI's configuration reads closer to how you would describe that work to a colleague.

Checkpointing and time-travel against event-driven state

agent-framework treats a long workflow as something that can be stopped and resumed. Checkpointing is listed among the workflow features and time-travel sits beside it, so a run can be paused, written down, picked up again and inspected at an earlier point. Our analysis of agent-framework makes this the deciding factor: the checkpointing, middleware and human-in-the-loop machinery only pays off if your agents actually run in production.

crewAI's answer to long-running work is the Flow, which is a different mechanism rather than a weaker one. Flows are event-driven, state changes in response to events, and each step can be a single LLM call or a whole Crew. The point of that model is that control flow stays explicit and readable, and that a step's size is your choice rather than the framework's.

The practical question is whether your workflow has a long tail of expensive, resumable steps. A research agent that can burn twenty minutes of tool calls and then hit a rate limit wants checkpoints. A pipeline that reacts to events as they arrive wants a clear state machine. Our analysis of crewAI recommends checking the current release notes for breaking changes in the Flow API, since the framework evolves quickly, and that warning belongs exactly on this layer.

Observability and where the commercial boundary sits

agent-framework has observability built into the framework. The README lists built-in OpenTelemetry integration for distributed tracing, monitoring and debugging, with samples for both Python and .NET, so agent runs emit standard traces without a separate vendor SDK. There is also a DevUI for interactive development and debugging, and an experimental labs package for benchmarking and reinforcement learning work.

crewAI puts its operational story in two places. The open-source project ships telemetry by default, and our analysis of crewAI tells you to verify that your deployment environment can tolerate that default before you adopt it, which is a real question for a regulated or air-gapped deployment. Tracing is listed among the framework's own tools, and the commercial layer adds the management around it: the CrewAI AMP Suite provides managed deployment, observability, governance and security, with a control plane that can be deployed on-premise or in the cloud.

So this is not open source against closed source. agent-framework's commercial counterpart is Microsoft Foundry, which hosts your agents rather than observing them. crewAI's commercial counterpart observes and governs agents you host. That difference decides which budget you are asking for.

Language reach: Python and .NET against Python alone

agent-framework keeps the Python and the .NET implementations in the same repository, under python/ and dotnet/, described as full framework support for both with consistent APIs. The Python install is one command, pip install agent-framework, with experimental packages in agent-framework-lab installed separately. The .NET install is NuGet packages: Microsoft.Agents.AI for the core, Microsoft.Agents.AI.Foundry for the Foundry integration and Azure.AI.Projects beside it. A Go SDK exists in its own repository.

crewAI is Python only, and it leans into that with the tooling around it. The project publishes an official skills repository, crewAIInc/skills, that teaches coding agents its own patterns, with skills for scaffolding a project, configuring an agent, writing a task and querying the live documentation. Installing it into an editor or agent tool is one command through npx skills add crewaiinc/skills.

That is a different kind of investment. agent-framework spreads a small surface across two languages and two release lines, so a .NET shop gets parity. crewAI concentrates everything in one language with a short path for AI coding assistants, so a Python shop gets a shorter distance from idea to a working agent.

Where each one falls short

agent-framework's weakness is weight and Microsoft alignment. Its value sits in layers you would not use if all you wanted was a thin wrapper around one provider's chat API, which our analysis of agent-framework states outright. The framework also asks you to learn middleware, checkpointing, time-travel, declarative YAML, agent skills, a DevUI and a labs package. And the provider question is concrete: the providers with working examples are those under python/samples/02-agents/providers/, so anything else is yours to build, while Foundry hosting assumes a Foundry environment you already have.

crewAI's weakness is the one its own analysis names. If you want a minimal single-LLM-call library, this is the wrong size of tool, and if your team cannot carry two abstractions, the Crews and Flows split will slow you down. The commercial dependency matters too: the tracing and governance you would want for a production deployment sit in the AMP Suite rather than the open-source package, the telemetry default has to be checked against your deployment environment, and the Flow API changes fast enough that the release notes deserve reading before each upgrade.

MIT for both, and the choice by scenario

Both are MIT licensed, so neither imposes a copyleft obligation or a source-available restriction, and either can be modified and hosted without publishing anything. agent-framework's last push was on 2026-10-21 and crewAI's on 2026-10-19, so both are being worked on.

The choice comes down to what you are building. A team writing a production workflow that has to survive a crash, needs a person to approve one step out of fifty, and must run the same logic from a Python service and a .NET service, gets the most out of agent-framework: checkpointing, middleware, human-in-the-loop and time-travel are in the box, the APIs match across languages, and OpenTelemetry is already wired in.

A team that wants agents to behave like a small team with job titles, writing tasks with dependencies and structured output, and sequencing the work with explicit events, gets the most out of crewAI. The two are not rivals on capability so much as on the shape of the abstraction, and the honest test is whether you would rather design a graph or write job descriptions.

Bottom line

Choose agent-framework for durable, restartable workflows and for parity between Python and .NET; choose crewAI for role-based autonomy with event-driven control in a Python-only codebase. Verify first that your provider appears in the framework's own samples, and read the release notes for the Flow API before you upgrade a running crew.

Sources

1. microsoft/agent-framework repository
2. microsoft/agent-framework README
3. crewAIInc/crewAI repository
4. crewAIInc/crewAI README