We Audited crewAI's AI Dependencies: Here's What the Data Says

Ask an AI assistant about crewAI's dependencies and you'll get: "LiteLLM is a good choice, Pydantic is standard, the vector store options are reasonable." That's recognition, not insight. It tells you what the dependencies are but not whether they're the right ones.

We ran crewAI's 47 dependencies against PT-Edge's dataset of 220,000+ AI repositories, scored daily on maintenance, adoption, maturity, and community. Here's what the data reveals that general knowledge can't — and where our own data has gaps we're working to close.

What we can score: 8 of 47 dependencies

Of crewAI's 47 direct dependencies, 8 match repos in PT-Edge's AI taxonomy with quality scores. That's 17% coverage — and we'll be transparent about why the other 83% aren't scored. But the 8 we can score tell a remarkably clear story.

Six of seven scored dependencies are #1 in their category. This isn't "good choices" — it's best-in-class across the board. Someone on the crewAI team made very deliberate dependency decisions, and the data confirms they picked exceptionally well. The seventh — mem0 — isn't weak; it's in the one category that hasn't settled yet.

LiteLLM: the best dependency choice, with a caveat

litellm (98/100, 38,910 stars) is #1 of 285 in llm-api-gateways. It's the dependency 155 other tracked AI projects also chose. By every metric, it's the right abstraction layer for multi-provider LLM access.

The caveat: 2000 commits in the last 30 days. That's roughly 80 commits per day. An AI assistant would say "well-maintained." The data says something more nuanced: this project is evolving at a pace where breaking changes are a real operational concern. If you're pinning versions (and you should be), expect to evaluate upgrades frequently. The velocity is a sign of health and a maintenance burden.

The vector store decision: LanceDB, Chroma, and Qdrant

An AI assistant would guess "probably ChromaDB." The actual picture is more interesting: crewAI has three vector store dependencies.

• lancedb (94/100, 9,425 stars) — core dependency, embedded/local-first
• chromadb (94/100, 26,607 stars) — core dependency, client-server model
• qdrant-client (76/100, 1,240 stars) — dev/optional dependency

Both LanceDB and Chroma score 94/100 and are #1 in their respective subcategories. The strategic choice is that LanceDB is in core dependencies while Qdrant is optional — crewAI defaults to embedded/local vector storage rather than requiring a separate database server. For teams that want zero-infrastructure agent memory, this is the right default. For teams running at scale, the Qdrant and Chroma options are there.

Agent memory: the one category that hasn't settled

Every other scored dependency is a clear category leader in a relatively stable landscape. mem0 (72/100, 49,646 stars) is a strong project — the most adopted agent memory tool in the ecosystem. But it sits in a category of 977 repos where the top 10 spans a wide quality range and multiple competing approaches:

cognee (80/100) is a knowledge engine that builds structured knowledge graphs from documents — architecturally different from mem0's conversational memory service. They're more complementary than competitive: mem0 remembers what the user said and what the agent learned; cognee processes documents into structured knowledge. A production crewAI deployment might use both.

The real observation isn't that mem0 is wrong. It's that agent memory is the most volatile part of the AI stack. With 977 repos and approaches ranging from knowledge graphs to episodic memory to video-based retrieval, this category is moving faster than any other in crewAI's dependency tree. LiteLLM's position as LLM gateway is secure. Chroma and LanceDB are established vector stores. But agent memory hasn't settled — and we should expect crewAI's memory integrations to evolve as the category matures.

json_repair: the dependency nobody mentions

Ask anyone about crewAI's stack and they'll mention LiteLLM, Chroma, maybe Pydantic. Nobody mentions json_repair (87/100, 4,585 stars). It fixes malformed JSON from LLM outputs — a problem every agent framework hits when models return truncated or invalid structured data.

It's #1 of 54 in llm-json-streaming, depended on by 31 tracked projects, and quietly essential. A strategic dependency audit should surface these hidden load-bearing libraries, not just confirm what everyone already knows.

The ecosystem importance picture

Quality scores tell you how good a dependency is. Reverse dependency counts tell you how important it is — how much of the AI ecosystem is built on top of it. For crewAI's dependencies:

The five most systemically important packages in crewAI's stack — the ones that would affect the most projects if they had a problem — are all ones we don't yet score. pydantic alone underpins 1,029 AI projects in our index. This is a gap we're actively closing (more below).

What we can't score yet, and why it matters

39 of crewAI's 47 dependencies aren't scored. They fall into three categories:

AI-adjacent infrastructure we should be tracking (and will be): The LLM provider SDKs (openai-python, anthropic-sdk-python, google-genai), the MCP protocol SDK, pydantic, instructor, and opentelemetry. These are the foundational layer that every AI application depends on. PT-Edge tracks 220K+ AI tools but not yet the plumbing underneath them. We're adding a foundational infrastructure layer to close this gap — it's the most important coverage improvement on our roadmap.

AI-specific tools not yet in our index: docling (document parsing), voyageai (embedding API), tiktoken (OpenAI's tokeniser). These should be tracked and will be ingested as we expand coverage.

General Python infrastructure (out of scope): click, tomli, regex, portalocker, openpyxl. These aren't AI-specific and aren't where strategic risk lives in an AI stack. A dependency audit focused on AI should acknowledge them and move on.

This transparency is deliberate. We'd rather show you what we can and can't measure than pretend the picture is complete. The value is in what the scored dependencies reveal — and in knowing exactly where the blind spots are.

What a strategic dependency audit looks like

This analysis is a prototype for something we're building: automated strategic fitness reports for AI projects. Not vulnerability scanning (Snyk does that well). Not version bumping (Dependabot handles that). The question these tools don't answer: is this the right library to be using at all?

A strategic dependency audit tells you:

• Whether each AI dependency is the quality leader in its category, or whether better alternatives exist
• How systemically important each dependency is to the broader ecosystem
• Whether development velocity signals healthy maintenance or risky churn
• Which dependencies nobody talks about but that are quietly load-bearing

If you're interested in this for your own AI projects, or if you'd like to be notified when we ship the automated version, check the PT-Edge API.

How to use this data

Every project mentioned in this audit has a quality-scored page in our directory, updated daily:

• Explore crewAI's own page (97/100)
• Browse 977 agent memory tools to evaluate alternatives to mem0
• Compare 285 LLM API gateways to understand LiteLLM's competitive position
• Check trending agent projects this week

Quality scores update daily. If a dependency starts losing momentum or a new alternative emerges, the data moves before the blog posts catch up.