Title: Lecture 8 — Two Roads to Multi-Agent Systems: Crews, Handoffs, and the State-Management Trade-Off
Course: AIINFRA 300: Agentic AI & the Model Context Protocol (MCP) > Section: Week 08 — Code-First Agent Frameworks II: CrewAI and OpenAI Agents SDK

📖 Lecture — Two Roads to Multi-Agent Systems: Crews, Handoffs, and the State-Management Trade-Off

Last week you built your first code-first agents by hand. This week you'll meet two production-grade frameworks that package that work into reusable abstractions — CrewAI and the OpenAI Agents SDK — plus a third framework you should be able to name and place: AG2. Each answers the same question, "how do multiple agents cooperate?", with a different philosophy, and those philosophies carry real consequences for what's easy to build and what's easy to debug. CrewAI (pip install crewai plus crewai[tools], Python 3.10+) gives you two building blocks. Crews are autonomous, role-based agent teams: you describe who each agent is and let them figure out how to collaborate. Flows are event-driven, production-ready workflow control with fine-grained state — you specify the control flow explicitly, step by step. A full CrewAI workflow has four components: Agents (defined by a role, a goal, and a backstory that shapes tone and judgment), Tasks (units of work assigned to an agent), Tools (functions or MCP-exposed capabilities an agent can call), and the Crew orchestrator that sequences everyone. CrewAI has first-class MCP support, so any MCP server's tools can be handed straight to an agent, and it's built on LiteLLM, which means the same crew code runs against OpenAI, Anthropic, Gemini, or Azure models just by changing a model string — genuinely useful when your organization is multi-vendor or cost-optimizing. The OpenAI Agents SDK (pip install openai-agents) takes a more explicit, control-flow-first approach. Multi-agent systems are built from Agents plus handoffs — a sub-agent that the current agent can delegate to, transferring both conversation history and control to that sub-agent. A Runner executes the agent loop (call model, run tools, decide whether to hand off or finish), and RunHooks/on_handoff callbacks let you observe control transfers as they happen, which makes debugging a multi-agent trace far more transparent than watching a crew's emergent delegation unfold. AG2 (formerly AutoGen, pip install ag2) is worth knowing by name even though this course won't build with it at depth: it supports nine distinct multi-agent orchestration patterns, from simple two-agent chats up through LLM-driven group speaker selection, where a manager agent decides which agent should speak next. Microsoft now recommends its production successor, Microsoft Agent Framework (MAF), for new enterprise projects — AG2/AutoGen is still widely used and referenced in the literature, but treat MAF as the forward-looking name to recognize. The table below compares the three on the dimensions that matter most in production:

Dimension | CrewAI | OpenAI Agents SDK | AG2 (→ MAF)
Core abstraction | Agents/Tasks/Tools + Crew (or Flow for explicit control) | Agents + explicit handoffs + Runner | 9 orchestration patterns, incl. group-chat speaker selection
Conditional branching | Fights the paradigm — gets pushed into agent prompts | Explicit in code via handoff logic | Explicit, pattern-dependent
Delegation transparency | Lower — emergent, harder to trace | Higher — RunHooks/on_handoff observe every transfer | Varies by pattern
Built-in state/persistence | Crew-level state exists; Flows add fine-grained state | Minimal — no native checkpointing/crash recovery | Varies by pattern
Model flexibility | LiteLLM under the hood: OpenAI, Anthropic, Gemini, Azure | Any OpenAI-compatible endpoint (incl. Gemini's compatible API) | Multi-provider
Production successor to watch | — | — | Microsoft Agent Framework (MAF)

Correcting three misconceptions before they cost you a debugging session:

1. "The OpenAI Agents SDK persists and recovers agent state for you." It does not. Context passes forward through handoffs during a single run, but there is no native checkpointing, persistence, or crash recovery. If your process dies mid-execution, you start over — unless you've built your own persistence layer (e.g., logging state to a database after each step).
2. "CrewAI's role/goal/backstory abstraction handles conditional logic for you." Real branching — "if the research finds X, do Y, otherwise do Z" — fights the crew paradigm. Teams end up encoding routing logic into agent prompts, which is brittle and hard to test. CrewAI's delegation is also less transparent than the OpenAI SDK's explicit handoffs, so when a crew misroutes a task, tracing why is harder than reading an on_handoff log.
3. "Handoffs are free — chain as many agents as you like." Each handoff passes the entire conversation history to the next agent. Long handoff chains accumulate tokens, cost, and latency quickly — a five-agent relay can be dramatically more expensive than a single well-prompted agent with tools.

The practical takeaway: reach for CrewAI when your workflow is genuinely a team of specialists collaborating loosely (research, writing, editing) and you want multi-provider flexibility with minimal orchestration code. Reach for the OpenAI Agents SDK when you need explicit, debuggable control flow — especially triage-and-route patterns — and are willing to build your own persistence. Know AG2/MAF by name for when a client or job posting mentions it.