CrewAI ships an MIT framework and a paid control plane, and its agent skills live in another repository

Crews and Flows solve different problems, and the choice is made early

The framework's central decision is which of two abstractions you build on. Crews are described as optimizing for autonomy and collaborative intelligence through role-based agents, where a job's shape comes from its role, goal and backstory. Flows are the opposite lever: event driven automations with precise workflow control, single LLM calls, and native support for Crews embedded inside them. The readme frames the whole library as high level abstractions over low level APIs, which is the claim to hold onto, because it means the four entry points are the same four choices the framework's own installable skills ask a coding agent to make.

That skill table is more precise than the marketing copy. The `getting-started` skill is described as scaffolding new projects and choosing between `LLM.call()`, `Agent`, `Crew` and `Flow`, then wiring `crew.jsonc` or `main.py`. So a single LLM call is a supported starting point rather than something you build by hand, and a four agent crew is the far end of the same axis. The cost of picking wrong is structural: a Flow with a Crew inside it has both the event layer and the agent loop to reason about, and the readme's own example list carries a section on using Crews and Flows together, which is where the combination is actually explained.

Observability, governance and support are not in the MIT package

The readme is candid that a commercial product sits on top of the framework. The AMP Suite is positioned as a control plane for organisations that need managed deployment, observability, governance, security and enterprise support, and the feature list for it is specific: real time tracing and monitoring of agents and workflows including metrics, logs and traces, a centralised platform for managing and scaling them, connections to existing enterprise systems and cloud infrastructure, compliance measures, analytics, round the clock support, and deployment either on premise or in the cloud. One part of it, the Crew Control Plane, can be tried without paying, at app.crewai.com.

So the split to price correctly is this. The MIT licensed framework is the agent and flow code you can run yourself, and the observability layer, the scaling story and the support contract are the commercial tier. A team that self-hosts the framework and assumes the tracing shown in the readme comes with it will find the feature list belongs to a different deployment. One more number deserves a caveat: the claim of more than 100,000 certified developers is tied to the vendor's own community courses at learn.crewai.com, so it measures the course funnel rather than production use of the framework.

The four skills that instruct a coding agent come from a separate repository

The readme's first feature is aimed at agents rather than humans, and it installs structured instructions from crewAIInc/skills into a coding agent. For Claude Code the sequence is a marketplace add, a plugin install and a reload.

/plugin marketplace add crewAIInc/skills
/plugin install crewai-skills@crewai-plugins
/reload-plugins

For Cursor, Codex, Windsurf and others the same skills are added with a single command.

npx skills add crewaiinc/skills

What the agent then knows is narrower than the framework: `getting-started` for scaffolding and the abstraction choice, `design-agent` for role, goal, backstory, tools, LLMs, memory and guardrails, `design-task` for task descriptions, dependencies, structured output through `output_pydantic` or `output_json`, and human review, and `ask-docs`, which queries a live CrewAI documentation MCP server at docs.crewai.com/mcp for current API details. The limitation follows from that last item. The instructions and the answers come from two places that are not your installed package, so a skill can be newer than the crewai version in your environment and an `ask-docs` answer can describe an argument your version does not accept.

Python support ends below 3.14 while patch releases arrive every two weeks

The project manifest sets the interpreter range explicitly at `>=3.10,<3.14`, and the linter's target version is the floor of that range, py310. Anyone on Python 3.14 is outside the supported window today, which is worth knowing before the interpreter upgrade that your base image or a colleague's laptop has already made for you. The development toolchain is pinned by hand in a dependency group: ruff, mypy, pre-commit, bandit, pytest and its plugins, plus type stubs for requests, pyyaml, regex, appdirs, psycopg2, pymysql, aiofiles and redis, and a bedrock runtime stub for boto3. Every one of those carries an exact version except commitizen, which is a floor.

The release cadence points the other way. The three most recent versions are 1.15.21 on 2026-09-09, 1.15.22 on 2026-09-16 and 1.15.23 on 2026-09-28, so this is a patch level moving every one to two weeks, and the last push to main landed on 2026-09-29. Nothing in the readme tells you which patch is safe, which is why the exact pins in the development group and the presence of a lock file at the top of the tree matter: the maintainers' own environment is reproducible even though the published version numbers move quickly.

The root project is a workspace, and the installed package is not its name

The manifest at the root is named `crewai-workspace` and carries no version of its own, which is a workspace rather than a distribution. The code lives under lib/, and the ruff configuration shows the split in its exclude paths: `lib/crewai`, `lib/crewai-tools` and a separate `lib/cli` whose package is `crewai_cli`. The published artefact a user installs is the `crewai` distribution on PyPI, linked from the badge row, while the repository root is the thing contributors clone.

The exclude list carries one more detail for anyone touching the scaffolding. The formatter skips the CLI template directories, the ones under `lib/crewai/src/crewai/cli/templates` and `lib/cli/src/crewai_cli/templates`, as well as the three test directories. Generated templates are exempt from the project's own formatting rules, which means a template change will not be caught by the format check and can drift from the surrounding style without a diff complaining. The root also holds conftest.py for pytest collection, a `.env.test` file, a pre-commit configuration, a pinned `.python-version`, and an AGENTS.md, so a contributor joining the repository has agent instructions, test configuration and commit hooks waiting at the top level.

The test dependencies name the providers and stores the framework talks to

The development dependency group is more informative about scope than the feature section. Model access is covered by recorded HTTP rather than live calls, with vcrpy pinned to 8.2.1 next to pytest-recording, and the comment in the manifest says lower versions of vcrpy break the recording plugin. Tests can therefore replay provider responses instead of paying for them, which also means a suite run tells you nothing about whether a provider's current API matches the cassette. Test order is deliberately unpredictable through pytest-randomly, execution parallelises with pytest-xdist, and suites shard with pytest-split, so a failure after a clean run locally can be an order dependency rather than a real one.

The type stubs narrow the integration surface. boto3 stubs with the bedrock runtime extra point at one hosted model provider, psycopg2 and pymysql stubs at two relational stores, a redis stub at caching, and aiofiles and regex stubs at async file access and pattern matching. The dependencies also include bandit for static security checks and pip-audit for dependency vulnerabilities, plus commitizen for conventional commit messages, which is consistent with a published changelog discipline. None of this is a promise of support for each of those stores, but it does show which paths the codebase exercises, and it shows that a Bedrock keyed deployment is a considered case rather than an afterthought.

The readme's own contents ends with Telemetry, License and an FAQ

The table of contents is the fastest way to see how the project expects you to work, and the order is instructional. It opens with Build with AI and Why CrewAI, then Getting Started broken into learning resources, understanding Flows and Crews, installation, setting up your crew and running your crew, then Key Features, then four worked examples under Examples: a quick tutorial, writing job descriptions, a trip planner and a stock analysis, plus the section on using Crews and Flows together. After that come Connecting Your Crew to a Model, When to Use CrewAI, Contribution, Telemetry, License and the frequently asked questions.

Three of those entries carry weight for a decision. Connecting Your Crew to a Model is where a provider belongs, which is the section to read before writing any agent code. When to Use CrewAI is the project's own statement of fit, and it is worth reading with the same scepticism as the Why CrewAI bullets, one of which claims optimisation for speed and minimal resource usage with no measurement, no benchmark and no figure attached anywhere in the document. Telemetry is the section a self hoster should read first, because an MIT licence tells you what you may do with the code and says nothing about what leaves the host at runtime.

Editorial conclusion

CrewAI is a reasonable choice when you want role-based agents with a predictable file layout, and the four installed skills make a first project cheap to scaffold. It is the wrong choice if you need observability, governance or enterprise support from the same artefact you self-host, because those sit in the AMP control plane. Before committing, check the Telemetry section of the readme, confirm the installed version against the model provider you intend to use, and pin the patch release, since 1.15.21 through 1.15.23 landed in three weeks.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes