CrewAI made its name on a simple, sticky metaphor: put a crew of role-playing agents on a job, give each one a role, a goal, and a backstory, and let them work tasks in sequence or under a manager. The current repository at crewAIInc/crewAI is an MIT-licensed Python monorepo organized as a uv workspace with six packages under lib: the framework itself, the CLI, a new crewai-core package, a files package, the tools ecosystem, and devtools. What a source tour reveals beyond the metaphor is a surprisingly complete platform: two orchestration paradigms, a provider-neutral LLM layer, memory and knowledge subsystems, a skills mechanism, and an unusually serious interop story spanning MCP and the Agent-to-Agent protocol with signed agent cards.

The design idea that carries everything is declarative teamwork. Crew in crew.py is a Pydantic model that composes agents, tasks, and a process mode, and kickoff() turns that declaration into an execution; Task in task.py carries expected output definitions and delegates to its assigned agent; Agent in agent/core.py wraps role, goal, and tools into an executor. Above the crew paradigm sits an entirely second one: the flow package, an event-driven orchestration where state transitions between steps and crews can pause for human feedback. The process enum in process.py offers sequential and hierarchical execution, and the hierarchical mode is the interesting one, because it inserts a manager agent that decides who works next.

As always in this series, this is an educational tour of published source code. Two mechanisms deserve attention before you copy patterns. First, tools execute real code, and the framework attaches security fingerprints to crews, agents, and tasks through the security package, with a security config to match; read how fingerprints thread through tool utilities and decide what your own systems should record. Second, flows can pause mid-execution for human feedback, which is the right default for anything consequential: the framework makes the approval step a first-class artifact rather than an afterthought.

CrewAI at a glance: the Crew model assembles agents and tasks under a process mode, the execution engine drives agent executors that call the LLM layer and bind tools, memory and knowledge ground the work, flows provide event-driven orchestration beside the crew paradigm, the events bus feeds telemetry, and the CLI scaffolds and runs everything.

Reading the overview from left to right:

• The framework trinity lives in lib/crewai/src/crewai/crew.py, with tasks in lib/crewai/src/crewai/tasks and the agent contract in lib/crewai/src/crewai/agent/core.py.
• The process enum at lib/crewai/src/crewai/process.py defines sequential and hierarchical execution.
• The execution engine in lib/crewai/src/crewai/execution.py drives the agent executors in lib/crewai/src/crewai/agents.
• The LLM provider layer is lib/crewai/src/crewai/llms above the core LLM class in lib/crewai/src/crewai/llm.py.
• Orchestration’s second paradigm is lib/crewai/src/crewai/flow, the event-driven flow engine.
• Memory and knowledge ground agents from lib/crewai/src/crewai/memory and lib/crewai/src/crewai/knowledge.
• The events bus in lib/crewai/src/crewai/events and the CLI in lib/cli complete the loop.

Why You Need This

The first reason is that CrewAI is the clearest open implementation of role-based agent teamwork. Where actor-model frameworks give you message passing and graph frameworks give you nodes and edges, CrewAI gives you a team roster: each agent has a role, a goal, a backstory, and tools; tasks describe expected outputs; the crew owns the process. The execution engine in execution.py and the CrewAgentExecutor in agents/crew_agent_executor.py show exactly how a declarative crew becomes a running loop, with the step executor handling one reasoning step at a time and the tools handler gating tool use. If you are designing any multi-agent product, this package answers the question “what does the minimum honest team abstraction look like?” better than any whitepaper.

The second reason is the dual-paradigm design. Crews answer “who does what,” flows answer “what happens when”: the flow engine in flow/flow.py is a state machine where steps emit and consume events, conversation-style flows support back-and-forth patterns through flow/conversational.py, and flow/human_feedback.py makes approval pauses part of the definition. The Crew class itself extends a flow-trackable base, so crews can live inside flows, which resolves the biggest architectural question in agent design, when to use autonomous teamwork versus explicit orchestration, by refusing to choose. Reading both paradigms in one codebase, with shared events and outputs, is a masterclass in composable orchestration.

The third reason is the interop posture. The mcp package bridges Model Context Protocol servers into the framework’s tool system, with a tool resolver that can even consult the CrewAI Plus API for managed tool resolution. The a2a package is a full Agent-to-Agent implementation: agent cards with signing utilities, transports, delegation helpers, streaming and push-notification update handlers, and a UI extension catalog. The auth package ships OAuth2 token management with first-party providers for Auth0, Entra ID, Keycloak, Okta, and WorkOS. Few frameworks take interoperability this seriously, and the a2a package alone is the best available reading on what production agent-to-agent integration actually requires.

The detailed view: the framework core with Crew, Task, process modes, and the execution engine, the agent runtime with its executor, step executor, tools handler, and a lite agent for single-shot work, the flow engine with human feedback, the intelligence group of providers, memory, and knowledge, tools bridging the ecosystem package, MCP, and A2A, the skills registry and loader, and the platform group of events, hooks, fingerprinting, project definitions, and the Plus API client.

The detailed diagram rewards a slow pass. In the agent runtime, lib/crewai/src/crewai/agents/step_executor.py and lib/crewai/src/crewai/agents/tools_handler.py split reasoning steps from tool gating, while LiteAgent in lib/crewai/src/crewai/lite_agent.py offers a lighter single-shot path that skips the full crew machinery. In the platform group, lib/crewai/src/crewai/security attaches fingerprints to crews, agents, and tasks, lib/crewai/src/crewai/project holds the JSON-first crew definitions and loaders that back the CLI’s project scaffolding, and lib/crewai/src/crewai/plus_api.py is the client for CrewAI’s hosted platform, used by the tracing listener and the MCP tool resolver. The skills mechanism, with its registry, loader, parser, and validation in lib/crewai/src/crewai/skills, turns structured skill definitions into callable agent capabilities.

From CLI to Kickoff

The README workflow starts with the CLI. crewai create crew <project_name> scaffolds a JSON-first project where agents live in agents/*.jsonc files and tasks plus crew-level settings live in crew.jsonc, and crewai run loads that JSON definition directly, prompting for any missing placeholder inputs. Teams that prefer the classic Python style can pass --classic and define everything in code. Then:

crewai install
crewai run

Inside the process, the project definitions from the project package are loaded into Crew, Task, and Agent objects, the process mode decides the order or the manager’s delegation, and kickoff() begins the loop. Output comes back as a CrewOutput from crews/crew_output.py, a typed artifact carrying the raw response, token usage, and per-task results, which flows can pass downstream or APIs can serialize. The README’s recommended extras, the official CrewAI Skills repository for structured instructions and the crewAI-examples repository for full applications, make the onboarding path unusually concrete.

The Interop Story

Three packages define CrewAI’s openness. The MCP bridge lets agents consume external tool servers through the standard protocol, so community tooling arrives without a fork. The A2A implementation lets a crew expose itself as a remote agent, complete with a signed agent card, streaming and push-based task updates, and delegation utilities, or consume other A2A agents as teammates. And the LLM provider layer under llms, sitting above the model-agnostic LLM class, keeps model choice orthogonal to orchestration, which is what makes running the same crew against local or frontier models a configuration change rather than a rewrite. Together with hooks for lifecycle interception and the events bus feeding telemetry, the framework draws a clean line between your orchestration logic and the world it talks to.

CrewAI earns its place in this series because it operationalizes the most intuitive metaphor in the field without making it a toy: role-based teams with declarative definitions, two composable orchestration paradigms, fingerprint-tracked security artifacts, and protocol-grade interop. For anyone building agentic products where teams of specialists beat a single generalist, this is the codebase to read first.

Next up in this series: microsoft/promptflow, Microsoft’s take on LLM app engineering as reproducible flows. Until then, read the seams, not the slogans.

Enjoyed this post? Never miss out on future posts by following us