CrewAI multi-agent orchestration: a developer's playbook

• CrewAI organizes multi-agent work through role-based agents, tasks, crews, and process execution inside a single Python runtime.

• Sequential processes work best when the task order is known in advance, whereas hierarchical processes allow manager agents to make routing decisions during execution.

• Delegation in CrewAI is designed for collaboration among agents within the same crew rather than for discovery across external systems.

• CrewAI handles local orchestration well, but production deployments often require additional capabilities such as delivery tracking, retries, permissions, and recovery.

• Cross-framework collaboration with LangGraph, A2A endpoints, or custom agents typically requires adapters that translate tasks, context, and execution state across boundaries.

• CrewAI is strongest as a framework for role-based agent coordination, while organization-wide agent operations require infrastructure beyond the crew itself.

CrewAI is an open-source Python framework for building role-based agent teams. An agent has a role, a goal, tools, and instructions. A task gives that agent work. A crew runs the tasks under a process.

The model is useful because it maps to how teams already describe work: researcher, analyst, reviewer, writer, support triage, data enrichment. CrewAI turns those roles into a runnable unit.

What it does not give you is a way for that crew to reach agents owned by another team or built in another framework.

Open-source positioning

CrewAI is open source under the MIT license. Its GitHub repository lists more than 53,000 stars as of June 2026, making it one of the more visible ways teams experiment with crew-style agent workflows.

The open-source shape matters. You can inspect the code, run locally, and avoid adopting a hosted backend just to test an agent team. You also inherit the normal framework boundary: CrewAI gives you orchestration primitives, not a shared registry, delivery system, or organization-wide control plane.

Where it sits in the stack

I would place CrewAI at the framework layer: it defines how agents behave within a crew and how tasks move through it. Protocols such as A2A and MCP sit beside it as communication contracts, and cross-process infrastructure sits below it.

Most CrewAI projects get into trouble when those layers blur. The crew can be correct, and the surrounding system can still lose the work.

CrewAI multi-agent orchestration depends less on the number of agents than on the quality of the contracts between them. A loose crew with five agents is usually worse than a tight crew with two.

Agents (role, goal, backstory)

A CrewAI agent has a role, a goal, and a backstory. You can also attach tools, configure the LLM, and control whether the agent may delegate.

The backstory is easy to treat as decoration. It is not. It is the part that keeps a "researcher" from behaving like a generic assistant with a search tool.

A useful role says what the agent is allowed to care about. A weak role says "an expert analyst" and then asks the model to infer the rest. That usually produces polite mush.

Tasks and pipelines

A task is a unit of work with a description, an expected output, and an assigned agent. The expected output is the part I would review first in code review. If it is vague, the next task reads a vague artifact.

A minimal crew looks like this:

• from crewai import Agent, Task, Crew, Process

• researcher = Agent(role="Researcher", goal="Find sources", backstory="...")

• writer = Agent(role="Writer", goal="Draft the brief", backstory="...")

• research = Task(description="Gather 5 sources", agent=researcher, expected_output="A list")

• draft = Task(description="Write a brief", agent=writer, expected_output="500 words")

• crew = Crew(agents=[researcher, writer], tasks=[research, draft], process=Process.sequential)

• result = crew.kickoff()

That example is small, but the failure mode is already visible. If research returns "a list" with no source format, quality bar, or exclusion rules, the writer has to guess what counts as usable input.

CrewAI will still run. The bad contract just moves downstream.

CrewAI runs a crew under one of two processes: sequential or hierarchical. The choice is not about which sounds more agentic. It is about whether the task order is known before the run starts.

Sequential process

In the sequential process, tasks run in the order you list them. Each task output becomes context for later tasks.

I default to sequential for most first versions. Research, then draft, then edit already has an order. Adding a manager agent to decide that order adds cost and another place for the run to drift.

Sequential also makes incident review simpler. You can inspect the task list, find the bad output, and fix the contract at that step.

Hierarchical process (manager agent)

The hierarchical process adds a manager agent. CrewAI can create it, or you can supply one. The manager plans work, delegates to workers, and checks results before the crew returns.

Use a hierarchical process when the next step depends on what the crew finds during the run. A manager is useful when they have a real decision to make, not when it is approving a pipeline you already know.

The trade-off is simple enough to write down:

CrewAI delegation lets one agent ask another agent in the same crew for help. Treat it as a local collaboration within a known team, not as discovery across your company.

In-crew delegation mechanics

When an agent has allow_delegation=True, CrewAI gives it coworker tools. The agent can ask a teammate a question or hand off a subtask. In hierarchical crews, the manager uses this pattern for the whole team. In sequential crews, peer agents can delegate when you enable it.

This is useful in exactly the cases CrewAI is built for. A writer can ask a researcher to verify a claim. A reviewer can send a section back to the drafter. CrewAI's collaboration model handles that message passing inside the crew.

Limits of in-crew delegation

The limit is the Crew object. Delegation routes to agents registered in that crew and available to that process. An agent cannot address a service it has never been given, and it cannot discover a crew owned by another team.

CrewAI is making a scoping decision here. Within the crew, delegation answers the question "which teammate should handle this subtask?" Outside the crew, the question changes to identity, routing, permissions, and delivery state.

CrewAI starts to feel thin when the crew stops being the whole system. A single crew can be clean. A production agent estate usually has several runtimes, owners, repos, queues, permission models, and incident paths.

The framework boundary matters here. The same issue arises in any single-framework approach to multi-agent orchestration: the local workflow can be well designed, yet the cross-system handoff lacks a shared record.

Scale and reliability limits

A basic crew runs lives where your Python process lives. If that process dies mid-run, you need your own strategy for what happens next. For long-running or high-value workflows, that usually means checkpointing, retries, idempotency, and a way to avoid replaying an unsafe action.

This is not an argument that CrewAI should ship every database and queue primitive. It is a warning against treating a successful crew run as proof that the operational layer exists.

Cross-system limits

The harder problem is reach. A CrewAI agent may need to call a LangGraph agent, a custom service wrapped as an agent, or an A2A endpoint another team published. At that point, the task has left CrewAI's local model.

You now need answers CrewAI does not try to provide: where the other agent is registered, who owns it, which messages it accepts, how task history maps across the boundary, and how you know whether it accepted, processed, failed, or retried the work.

Connecting CrewAI to agents outside its crew is mostly boundary work. The crew has its own task model and collaboration rules. The other runtime has its own model too. Someone has to translate between them and preserve enough history to debug the handoff later.

The cross-network problem

Hand wiring the crew to one outside system is fine. Each connection carries its own message conversion, task history mapping, timeout behavior, and definition of "done." Past a couple of integrations, that private wiring becomes the part most likely to drop a handoff: a message marked sent inside the crew and missing everywhere else.

Adapter-based integration

An adapter provides CrewAI with a way to join a shared interaction model. The adapter translates CrewAI tasks, messages, and outcomes into a format other agents can address. It also maps incoming work back into the crew without pretending every framework shares the same runtime.

This leaves CrewAI doing what it is good at: role-based work inside the crew. The adapter owns the boundary: routing, format conversion, delivery status, and recovery signals.

BAND wraps CrewAI without changing the crew logic. The crew still owns the role design, task sequence, and local delegation. BAND gives the crew a way to participate in a wider agent network with identity, addressed routing, delivery state, and governance around the handoff.

The CrewAI adapter

BAND's CrewAI integration registers a crew as an agent with a discoverable @handle. LangGraph agents, Pydantic AI agents, A2A endpoints, and custom agents can address the crew via mention-based routing, so they process messages intended for them rather than listening to every shared room event.

The adapter also gives the handoff a lifecycle: delivered -> processing -> processed/failed. That matters when a crew crashes or reconnects, because the platform can distinguish between "the message was sent" and "the crew accepted and finished the work." The setup steps are in the CrewAI adapter tutorial.

Governance and observability around crews

Around the crew, BAND adds controls that fall outside the framework: RBAC, cross-organization sharing, and delegation-chain visibility that shows how agents passed work to one another.

The scope should stay clear. CrewAI keeps the reasoning loop. Model eval and prompt-tracing tools do their jobs. BAND provides the agentic mesh around the crew, in which distributed agents require identity, routing, delivery state, and policy.