CrewAI

You will like CrewAI the first day: give three agents a role, a goal and a backstory, hand them tasks, and a crew runs them in sequence or under a manager, well enough to demo before dinner. The second week you will want more control than prose gives you, because the interesting failures are in the handoffs and the handoffs are written in English.

Pick it for prototypes shaped like a team, and for anything a non-engineer needs to read. Pick LangGraph when the workflow is a state machine and you need to resume it after a crash.

The risk is that the abstraction is prose. Role, goal and backstory are strings; the framework composes them into prompts, and the behavior lives in the model's reading of those strings, so correctness depends on phrasing and model version in equal measure. Change a sentence, change the system; upgrade the model, change it again, and no test suite catches either.

Write evals before crews, and freeze the model version in production. What it does right: Flows persist state between start, listen and router steps, so the orchestration around the prose is deterministic code you can unit test.

1. Crews: agents with tools, memory and knowledge execute tasks in a sequential process or a hierarchical one where a manager delegates, so context flows through task outputs rather than a shared store. 2. Flows: start, listen and router steps form an event-driven graph with persisted state, a different execution model with different failure characteristics. Verification is absent; a crew's output is whatever the last task returns, and nothing checks it against the first task's intent.

No benchmark is published for either. The observation: two orchestration models in one library suggests the first was not enough, and the second is the one to learn.

The enterprise page claims adoption by 65% of the Fortune 500, sells a 45-day onboarding, and offers forward-deployed engineering and training a la carte. That is consulting revenue wrapped around an open library, which scales with headcount, not code, and a services margin is a different company from the one the star count implies. The library is the lead generator; the engineers are the product.

Likely acquirer: Salesforce or ServiceNow, either of which buys services companies with a developer following and knows what to do with a forward-deployed team. Position: small, read the services mix, and do not confuse the library's popularity with the company's margin.

The demo is three agents writing a memo. As a dependency: maintained by CrewAI Inc, the library costs sixty engineers nothing and installs like any Python package. The hosted Basic tier allows 50 workflow executions a month, one team's morning, so the hosted path is Enterprise or nothing. Enterprise adds SSO, RBAC, workload identity, PII redaction and deployment in our own VPC, at an unlisted price, a complete list attached to a blank number.

Onboarding is a day for a Python engineer. Approved with conditions: library only, our own keys through the cloud contract, and no hosted platform until a price exists.

All Python, MIT, mine to read. uv tool install crewai gets the CLI, and an MCP server is a context manager, MCPServerAdapter with a url and transport of streamable-http, whose tools I pass straight to an Agent, no config file, just code. The model layer is LiteLLM, so Ollama counts and my local box is a provider string away from being the whole stack.

A fork would be a rename, and the license says so. Grudging note: the docs push the hosted platform hard, and every second page ends in a signup link, which is a smell in a library.