What does wrapping each crew in a CrewAI Flow step give you over one big crew?

## The two ways to compose Given four units of work, CrewAI offers two shapes. One crew with many tasks and, in a hierarchical process, a manager model deciding who does what next. Or several small crews, each invoked from its own flow step, with the ordering written in Python. Both run the same agents against the same models. The difference is *who decides the order* — and therefore what varies run to run, what you can test, and what you pay. ## The mechanics There is no special API for this. A flow step is a normal method, so it constructs (or looks up) a crew and calls `crew.kickoff(inputs={...})`. Inputs typically come off `self.state`, so the flow decides what context this crew sees. The call returns a `CrewOutput`: `.raw` for the text, `.pydantic` or `.json_dict` when the final task declared structured output, `.tasks_output` for per-task results, and `.token_usage` for what it cost. The step writes what matters onto `self.state` and returns whatever the next step needs. That is the whole integration surface, and its plainness is the point: between two crew calls you are in Python, with no model in the loop. ## What the seams buy **Deterministic work between crews.** Validation, deduplication, a database write, an idempotency check, a call to an internal service. Doing these as flow steps costs zero tokens. Doing them as agent tasks costs tokens *and* can be skipped or fumbled by the model. **Skipping.** A router can decide that the cached answer is fresh, that the request failed policy checks, or that the first crew already answered well enough — and the expensive crew is simply never invoked. Inside one hierarchical crew, an agent that decides not to act has still read its task and reasoned about it, on the clock. **Retry granularity.** If the extraction crew produced malformed JSON, you can re-run *that* crew — possibly with a stricter prompt or a different model wired into the retry path — without re-running the research crew that cost ten times as much. Retry logic lives in the step, where you can bound it with a counter on state. **Cost attribution.** Each `CrewOutput` carries its own token usage, so per-crew cost lands on state and in your logs. A single large crew gives you one number and a guess. **Context control.** Each crew gets exactly the inputs the step passes it. Inside a hierarchical crew, context accumulates across tasks whether or not the next task needs it, and prompts grow. Flows let you deliberately *not* forward the previous crew's raw output. **Testability.** A step is a method. You can construct the flow, set state, call the step with the crew stubbed, and assert what it wrote. Manager-driven delegation has no comparable seam. ## What it costs You wrote the sequence, so the system cannot adapt to a situation you did not anticipate. If the work genuinely requires discovering the plan at runtime — an open-ended research request where the next move depends on what was just found — hardcoding steps produces a rigid pipeline that fails on the interesting inputs. There is also more code: models, routers, state fields, tests. And you own the failure semantics, because a crew that raises inside a step propagates out of `kickoff()` with no retry unless you wrote one. ## The practical middle The shape that holds up is **deterministic outside, non-deterministic inside**. The flow encodes the parts of the workflow that are genuinely fixed — intake, three phases, persistence, notification — and each phase is a crew whose agents have real latitude within their phase. Judgment sits where judgment is needed, in bounded units whose cost you can measure, and the skeleton is code. A good migration heuristic: run the hierarchical crew, log the manager's delegation decisions across a few dozen runs, and look at which ones never varied. Those are edges you should be writing as flow steps; you are paying a model to re-derive them every run. The ones that did vary are the places to keep the model in charge. ## Operational notes Put a run correlation id — the flow state's generated id — into whatever you log around each `kickoff` call, so a support ticket resolves to one execution and its per-crew outputs. Keep crew construction out of module import time if the crew reads state-dependent configuration, so each step builds the crew it actually needs. And be deliberate about what a step forwards: the most common regression is a step passing an entire previous `CrewOutput.raw` into the next crew's inputs, which quietly doubles the prompt of every downstream call.