In CrewAI Flows, what does typed Pydantic state give you over dict state?

## The two modes A Flow always has state, reachable as `self.state` from any step. What differs is its type. **Unstructured (dict) state** is the default: subclass `Flow`, and `self.state` behaves as a dictionary. Any step can write any key at any time. It is the fastest thing to prototype with and the shape most examples start from. **Structured (Pydantic) state** is opt-in: declare a model and parameterize the base class with it. ``` class ReportState(BaseModel): topic: str = "" draft: str = "" revisions: int = 0 class ReportFlow(Flow[ReportState]): ... ``` Now `self.state` is a `ReportState` instance. Access is by attribute, defaults live in one declaration, and Pydantic validates and coerces on assignment. ## Why the difference matters in a flow specifically State is the *only* channel between steps that are not directly wired. A listener receives its trigger's return value; everything else — the original request, each crew's output, flags a router will branch on — travels on state. That makes state a de facto interface between methods written at different times, and interfaces without schemas rot. The concrete failure with dict state is the silent key. Writing `self.state["summry"]` is legal, so the producer looks fine; the consumer reading `self.state["summary"]` blows up several steps and one crew invocation later, having already spent the tokens. With a model, the assignment itself is the error, at the line that caused it. In a system where each step may cost a dollar and thirty seconds, moving a failure earlier is worth real money. The second benefit is documentation. A reviewer can read the model and know exactly what the flow carries. With dict state they have to grep every step for string keys — and the set is open, so they can never be sure they found them all. ## The run id Both modes carry an auto-generated `id` on the state, a UUID identifying this run. It is what you log alongside crew outputs so a support ticket can be tied back to a specific execution, and it is the handle any state-persistence layer keys on. ## Passing values in `kickoff(inputs={"topic": "batteries"})` applies those values to the state before the start methods run, so a start method can read `self.state.topic` rather than taking parameters. With structured state the values go through the model, so types are validated and coerced instead of being stored blindly; with dict state whatever you pass lands as-is. Prefer inputs over module-level globals: it keeps the flow instantiable in a test with a synthetic state. ## Concurrency on state Parallel branches — two start methods, or two arms both running crews — share one state object. There is no locking and no copy-on-write. The discipline that works is *one writer per field*: give each branch its own field and let the join step read both. Two branches appending to the same list, or incrementing the same counter, is a race with no ordering guarantee, and it will not reproduce reliably. ## Size and cost State is not free context. Whatever you put on state and then interpolate into a crew's inputs becomes prompt tokens. A common anti-pattern is stuffing every intermediate crew output onto state and passing the whole object into the next crew "just in case" — the prompt grows monotonically across the flow, and cost with it. Keep raw payloads out of state, or keep them behind a reference (a file path, a row id) that only the step needing them dereferences. Structured state helps here too, because a model with three fields is a design decision you can review, while a dict with eleven keys accreted without anyone deciding. ## Persistence Because state is a well-defined object with an id, CrewAI can persist it between runs: the `@persist` decorator, backed by `SQLiteFlowPersistence`, saves flow state so a run can be restored rather than restarted. Structured state makes this materially safer — a schema round-trips predictably, whereas an open dict may deserialize into something whose shape a later version of the code no longer expects. ## When dict state is the right call Proof of concept, a three-step flow, a spike you will throw away. The cost of the model is one class; the cost of the dict is deferred to whoever maintains it. The moment a flow has branches, more than a handful of steps, or more than one author, structured state pays for itself.