Playbooks vs Flows in Dialogflow CX: When to Go Generative and When to Stay Deterministic

In my last post on Dialogflow ES vs CX, the question was which generation of the product fits your conversation. Once you are on CX, a second question shows up quickly, and it is the one I get asked most now: should this part of the agent be a flow or a playbook?

Google has been repositioning Dialogflow CX as part of a broader Conversational Agents platform, where structured logic, generative playbooks, grounded responses and tool-based actions live in the same system. That is good news, because you no longer have to pick one paradigm for the whole agent. It also means the design decision moves from "which product?" to "which building block, for which part of the conversation?"

The Three Levels of "Generative"

Google's own documentation frames this as a spectrum, and I find it a useful starting point:

• Fully generative: playbooks. You describe the agent's goal and instructions in natural language and the model decides how to get there, including what to ask and which tools to call.
• Partly generative: flows with optional generative features, such as generators and generative fallback. You keep the explicit state machine and use an LLM only where you choose to, for example to summarize something or to answer when the user says something unexpected.
• Deterministic: flows, pages and transitions with fixed responses. Nothing is left to the model's judgment.

One detail worth remembering: in all three modes, CX uses language models to understand what the user means. The choice is about who controls the response and the path, not about whether AI is involved.

What Flows Are Good At

Flows give you explicit control. Every page, every transition and every response is something you designed and can trace. That makes them the right fit when:

• The wording or the path is regulated or contractual. Disclosures, consent, identity verification and payment confirmation should not depend on a model's phrasing on a given day.
• The process is a strict sequence. Collect these five parameters in this order, validate each one, then call this backend.
• You must be able to explain exactly why the agent did something. A flow diagram is documentation an auditor or a product owner can read. A playbook's reasoning is harder to inspect.
• Cost and latency must be predictable. Deterministic paths do not need a generative call per turn.

The price is design time. Flows take longer to build and they only handle the situations you anticipated.

What Playbooks Are Good At

Playbooks shine where the conversation is open-ended and rigid branching would never keep up:

• Requests that vary widely in phrasing and order. Users who give information out of sequence, change their mind, or ask two things at once.
• Tasks that combine several tools. The agent needs to decide which lookup to call next based on what it just learned.
• Advisory or exploratory conversations. Product recommendations, troubleshooting, "help me figure out what I need".
• Fast iteration. Changing behavior means editing instructions, not redrawing a state machine.

Playbooks come in different shapes. Task playbooks handle a goal, and routine playbooks are meant for more repeatable procedures. Routine playbooks are now generally available, and playbooks support code blocks for tighter control over behavior, so you are not limited to pure natural-language instructions.

The price here is control. You are trading traceability and predictability for flexibility, which means you need to test far more deliberately (more on that below).

A Decision Framework You Can Reuse

When I look at a section of a conversation, I ask four questions:

1. What is the cost of a wrong or off-script answer? If it is a compliance problem, a financial error or a safety issue, use a flow. If it is a slightly awkward sentence, a playbook is fine.
2. How predictable is the path? A fixed sequence points to a flow. An unpredictable path points to a playbook.
3. Do I need to prove what happened? If yes, prefer the flow, or at minimum put the sensitive step behind one.
4. How often will this change? If the behavior changes weekly, the lower editing cost of a playbook is a real advantage.

If two or more answers point the same way, go that way. If they split, that is usually a sign the section should be broken in two.

The Pattern That Works Best: Hybrid by Design

In practice the best agents I see do not choose. They use each mode where it is strongest:

• A flow at the front door for the things that must be exact: greeting, authentication, consent.
• A playbook for the open-ended middle, such as understanding the problem and gathering context.
• A flow again at the commitment point: confirmation, the actual transaction, the handoff to a human.

Think of it as deterministic guardrails around a generative core. The generative part gets to be flexible, and the parts where mistakes are expensive stay under explicit control. Google's platform is built for exactly this combination, since flows, playbooks, data stores and tools can coexist in the same agent.

Mistakes I Would Avoid

• Making everything a playbook because it is faster to demo. Demos hide edge cases. The first production week will not.
• Making everything a flow out of habit. If you are adding the twentieth branch to cover phrasing variations, that section wants to be a playbook.
• Treating generative fallback as a safety net for a weak design. It is useful for graceful recovery, but if it fires constantly, your intents or flows have a coverage problem that no prompt will fix.
• Ignoring cost. Generative features such as playbooks, data stores, generators and generative fallback are billed as generative requests, on top of the usual CX pricing. Model the cost per conversation before you commit, not after.
• Skipping evaluation. A deterministic flow either matches or it does not. A playbook can be right 90% of the time and badly wrong the rest. Build a set of real conversations, including adversarial ones, and rerun it every time you change instructions or switch models.

So Which One Should You Use?

Use flows where you need control, proof and predictability. Use playbooks where you need flexibility and speed of change. Use both in the same agent, and be deliberate about where the boundary sits.

If you are starting a new conversational project today, I would not ask "flow or playbook?" for the whole agent. I would sketch the conversation, mark the steps where a mistake is expensive, and draw the boundary around them. Everything else is a candidate for generative behavior.

---

I'm a Solution Architect and Full Stack Developer working across React, Node.js, and Google Cloud's conversational AI stack (Dialogflow CX, Vertex AI, ADK). If you are deciding where to draw the line between deterministic and generative in your own agent, feel free to reach out.