CrewAI 1.15.0 landed on June 25 and the release note that got quoted around was short: support conversational flows. It's the kind of line that invites a wrong summary — "CrewAI crews can hold a conversation now." Read the actual template and that summary evaporates. A crew did not learn to converse. A crew is exactly what it always was: a task DAG that fires once, runs its agents to completion, returns a result, and forgets everything. Nothing about that changed.
What shipped is one layer up, and it rests on a single primitive that CrewAI already had.
The whole trick is @persist#
A CrewAI Flow is normally fire-once too — that's the whole point of the Flows-vs-Crews split: a Flow is the deterministic control layer around your non-deterministic crew. @persist changes one thing: it writes the flow's state to a backend, keyed by an id. Re-invoke the same flow with the same id and it resumes — the prior state is loaded instead of a blank one. That's the entire mechanism behind "conversation." A conversational flow is a persisted flow whose key is a conversation id, and each user message is another entry into the same resumable run.
The official template_conversational_example makes the contract concrete. The first message POSTs to /kickoff with a body as plain as it gets:
{ "current_message": "hello" }You get back a kickoff_id. Every turn after that POSTs to the same /kickoff endpoint, now carrying the id:
{ "current_message": "and what about tomorrow?", "id": "UNIQUE-CONVERSATION-ID" }And the flow uses @persist with that id as the key to keep the history across those calls. The turn history lives in the persisted flow state — not in the agents, and not in some new conversational memory the agents magically gained.
"Conversation" here means a resumable flow keyed by an id. The crew stays stateless; the flow is what remembers.
The part that changes how you build: it's poll, not stream#
Here's the second thing the one-line summary hides. There is no token stream. The client fires a turn and then polls /status/{kickoff_id} until the state comes back SUCCESS, at which point it reads the assistant's message. That's a request/response-with-polling UX, not the live token trickle people now expect from a chat box.
This is not a criticism — polling is the honest shape of a crew, which may spend a full turn fanning out across several agents and tools before it has anything to say. But it means the chat interface you put in front of it shows a pending state and then a whole message. If your product spec says "streaming responses like ChatGPT," conversational flows don't hand you that; you'd be building a different thing on top.
The conflation that will bite you#
CrewAI 1.14 shipped pluggable memory/knowledge/RAG backends. 1.15 shipped conversational flows. They sound like the same feature described twice. They are not, and treating them as one store is the mistake this release quietly sets up.
- Memory (1.14) is retrieval: embeddings, knowledge sources, a RAG lookup the agents can pull from.
- Conversational flow (1.15) is control state: the persisted flow object that makes turn N+1 aware of turn N.
One answers "what does the agent know about the world?" The other answers "where were we in this dialogue?" You will usually want both, and you want them as separate stores — because their lifetimes differ. A conversation's flow state is scoped to that conversation id and should be pruned or expired with it; your knowledge base outlives every conversation. Wire the chat history into your RAG index and you get a slow, self-polluting retriever that surfaces last Tuesday's small talk as if it were a document.
What to actually take away#
If you're reaching for conversational flows, hold three facts:
- You did not get agent memory. You got a resumable flow. The scope, shape, and pruning of that persisted state are your design problem, not a default.
- The client contract is kickoff-then-poll. Design the UI for a pending turn resolving to a full message. Don't promise streaming you can't deliver from this path.
- Keep conversation state and knowledge separate. The persisted flow is control; the memory backend is retrieval. The moment they share a store, both get worse.
Conversational flows are a genuinely useful addition — resumability is the hard part of turning a batch pipeline into something interactive, and it's the same problem the durable-execution engines solve with more machinery. CrewAI put it behind one decorator and one id. Just don't let the phrase "conversational crew" talk you into believing the crew is the thing holding the conversation. It's the same forgetful DAG it always was. The memory is in the key.
