« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 19 — CrewAI: Role-Playing Agent Crews, Processes & Event-Driven Flows

Answers these JD lines: Citi's Lead Agentic AI Engineer requirements list jd.md name CrewAI and AutoGen alongside LangChain/LangGraph, LlamaIndex, and Google ADK, on top of "architect multi-agent systems covering perception, reasoning, planning, and execution." Phase 07 built multi-agent orchestration from first principles (supervisor/worker/critic, a message bus, typed handoffs); Phase 18 built LangGraph's execution model. This phase does the same for CrewAI — the framework whose whole pitch is role-playing autonomous agents — so that when an interviewer says "you list CrewAI; walk me through what kickoff actually does, and when you'd pick it over LangGraph," you answer from the mechanism, not the marketing.

Why this phase exists

CrewAI is the fastest way to stand up a team of agents: you describe each agent by its role / goal / backstory, give each a task, group them into a crew with a process, and call kickoff. That role-first abstraction is genuinely productive — and genuinely misleading if you only ever operate it from the outside, because three mechanisms do all the real work and every one of them is an interview target:

1. The process is the execution model. sequential runs listed tasks in order with no LLM deciding control flow (cheap, deterministic). hierarchical adds a manager LLM that delegates each task to a worker and synthesizes the result (flexible, but N+1 extra LLM calls and a single point of judgment). Knowing which, when, and what it costs is the skill.
2. Context is how work flows between tasks. A task feeds forward by default, reads specific prior tasks via context=[...], or is isolated with context=[]. Get this wrong and your crew either starves the writer of the researcher's facts or drowns it in everything.
3. Flows are a different tool than Crews. A Crew is a self-contained task sequence. A Flow is event-driven orchestration — @start / @listen / @router, or_/and_, structured state, @persist — that wires multiple crews together with branching and human-in-the-loop. Confusing the two is the most common CrewAI misconception.

You build faithful miniatures of all three, with the LLM injected as a pure policy, so the mechanism is muscle memory and the whole thing is deterministic and testable offline.

Concept map

• Primitives: Agent (role, goal, backstory, tools, llm) → Task (description, expected_output, agent, context) → Crew (agents, tasks, process) → kickoff(inputs).
• Processes: sequential (listed order, feed-forward, no manager) vs hierarchical (manager LLM delegates + synthesizes; cost = N+1 manager calls).
• Context passing: None → feed-forward · [t1, t3] → explicit fan-in · [] → isolated.
• Interpolation: {placeholders} in task text filled from inputs at kickoff.
• Flows (distinct from Crews): @start → @listen(m) (fires on completion, receives output) → @router (emits a label) → @listen("label"); or_/and_ gates; structured (Pydantic / here a dataclass) vs unstructured (dict) state, both id-stamped; @persist (SQLite); Crews-inside-Flows; human-in-the-loop.
• Choosing: CrewAI (role/crew abstraction) vs LangGraph (explicit graph/state) vs AutoGen (conversation between agents).

The labs

Integrated scenario (how this shows up at work)

A support-automation team wants an agent that triages a ticket, drafts a reply, has it reviewed, and — only for refunds over a threshold — routes to a human before sending. The naive build is one giant "autonomous agent." The CrewAI-literate build is a Flow with two Crews: a sequential "triage → draft → review" crew (deterministic, cheap, the 80%), wrapped in a Flow whose @router branches on the refund amount to either send directly or @listen("needs_human") for approval, with @persist so the ticket survives a restart while it waits. You reach for the hierarchical process only inside the one sub-task that genuinely needs a manager to route across specialists — and you can state that it adds N+1 manager LLM calls, so you use it deliberately. That decomposition — Crews for the fixed sequences, a Flow for the branching/HITL/durability, and hierarchical used sparingly — is the Staff-level answer.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py (22 tests).
• Lab 02 green (21 tests); you can state manager_calls == len(tasks) + 1 and defend it.
• Lab 03 green (21 tests); you can wire a @router branch and an and_ fan-in by hand.
• You can contrast sequential vs hierarchical on order, cost, and determinism.
• You can say, in one sentence each, when you'd choose CrewAI vs LangGraph vs AutoGen.

Key takeaways

• CrewAI's abstraction is roles and crews; the process is the execution model, and the process — not the prompt — is what you defend in a design review.
• sequential is the cheap, deterministic default; hierarchical buys dynamic delegation for N+1 manager calls and a coordinator you now have to trust and observe.
• Crews are sequences; Flows are event graphs. Use a Crew for a fixed task pipeline; use a Flow to orchestrate multiple crews with branching, persistence, and human-in-the-loop.
• CrewAI is fast to prototype role-based teams; LangGraph is what you reach for when you need explicit state and control; AutoGen when the paradigm is agents conversing. Naming the right one for the task is the signal.