Flows

Crews are great at role pipelines. They are weak at product branching, retries across the whole job, and resume-after-crash. Flows add that control.

Crews are the film crew on set. Flows are the shooting schedule with weather delays and pickup days.

Visual Workflows

Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.

100%

Loading diagram...

Scroll inside the frame to explore · use + / − to zoom up to 200%

Key Takeaways

1.A Flow is controlled, event-driven application workflow: explicit state, start, listen, router. If you only learn Crew, you know the beginner side of CrewAI.
2.Modern production CrewAI uses Flows as the orchestration layer around agents and crews. Routers return a label; listen methods take the branch.
3.A Flow is a Python class with typed state. Start is the entry.
4.Listen runs after. Router returns a string label that later listen methods bind to.
5.You may kick off a Crew inside a method — the Flow does not replace the Crew, it calls it.

Learn elsewhere

→LangGraph — Phase 10
→Crew + Flow Hybrid
→Durable Execution — Phase 21

Real Example

Scenario

Start → classify topic → router: short FAQ is one agent; deep brief kicks a research+write crew → end.

What you would do

In CrewAI, apply Flows to this scenario: Start → classify topic → router: short FAQ is one agent; deep brief kicks a research+write crew → end. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.

Commands

Commands to Remember

Start then listen
Router returns a label
Typed flow state
Crew kickoff inside a step

Cheat Sheet

Quick recap

quick ref

•Flows = control
•Crews = collaboration
•Router labels
•Persist long jobs

Common Mistakes

✕Skipping evaluation for Flows before production
✕No logging or tracing around crewai flows steps
✕Ignoring cost and latency implications