You've shipped a Dialogflow ES agent. Six months in, your conversation graph looks like spaghetti. A user says "I want to cancel my order" and the agent matches three intents with near-identical confidence scores. Your fallback flow catches most of it, but not all. You add more training data, tune entity extraction, configure longer output contexts to prevent state collisions. The problem persists. Intent pollution is real—when your intent set grows beyond ~50 intents, context-based routing becomes a debugging nightmare.

This is where the architectural chasm between ES and Conversational Agents widens. Dialogflow ES was engineered for turn-by-turn intent matching with implicit state management via contexts. Conversational Agents (formerly Dialogflow CX) abandons context-as-routing and replaces it with an explicit state machine model: pages, flows, and routes. The difference is not cosmetic. It's a fundamental departure in how conversation control is modeled, tested, and scaled.

This guide maps the gap precisely, grounded in official Google Cloud documentation updated through June 2026.

Terminology Shift: From Context Chains to State Machines

Architectural Deep-Dive: How Inputs Flow Through Each Engine

Dialogflow ES: Intent-Centric Flow

When an end-user provides input (text or audio) to a Dialogflow ES agent:

1. Input Reception & NLU Pipeline

   • Speech-to-Text (STT) converts audio to text (if applicable).

   • NLU classifier runs against all training phrases across all intents in the agent.

   • The classifier outputs a ranked set of intent matches with confidence scores.

2. Context Filtering

   • The runtime filters the matched intents: only intents whose required input contexts are active in $session.context are eligible.

   • If no input context is required, all intents compete for match.

   • Intent with the highest confidence score that passes context filtering is selected.

3. Parameter Extraction

   • Entity extraction runs on the matched intent's parameters.

   • Entities are extracted from the user's input based on the parameter's entity type (system or custom).

   • Extracted parameters are bound to $session.params[param_name].

4. Required Parameter Collection (Slot Filling)

   • If the matched intent has required parameters and any are missing from the user input, the agent prompts for those missing parameters.

   • The agent enters a loop: prompt for parameter → collect response → check if satisfied → repeat until all required parameters are filled.

   • Slot filling happens within a single intent, controlled via the prompt messages and fulfillment definitions for that intent.

5. Intent Fulfillment Execution

   • Once all required parameters are collected (or user provides the parameter in their original input), fulfillment executes.

   • Fulfillment can be:

     • A static response text (simple text or text + media).

     • A webhook call: the request payload contains intent.name, parameters, and session_id.

   • The webhook processes the request and returns a response: agent text, parameters to set, contexts to activate/deactivate.

6. Output Context Management

   • As part of fulfillment (or manually via webhook response), output contexts are set.

   • Each context is stored in $session.context[context_name] with a lifespan (number of turns; default 5).

   • Contexts decay: on each subsequent turn, lifespan decrements. When lifespan reaches 0, the context is removed.

   • The next user input is matched against intents, filtering for those whose input contexts are active.

7. Session Termination

   • The session ends when:

     • The end_interaction flag is set in fulfillment.

     • The user closes the conversation manually.

     • Session timeout is reached (typically 20-30 minutes idle, depending on channel integration).

Runtime Memory & TTL Constraints:

• Contexts live in $session.context, governed by lifespan.

• Parameters live in $session.params, but are only durable while referenced in active intents or output contexts.

• After context decay, parameters referenced by that context become unreachable.

• This forces complex webhook logic: developers must duplicate critical parameters into multiple contexts to ensure they survive context cascades.

Example ES Flow (Pizza Order Agent):

User: "I want to order a large pepperoni pizza."
  ↓
NLU: matches "order_pizza" intent (confidence 0.95).
  ↓
Intent requires: @sys.number (size), @pizza.topping (topping).
  ↓
Extraction: size = "large", topping = "pepperoni".
  ↓
Fulfillment: webhook called with intent="order_pizza", parameters={size: "large", topping: "pepperoni"}.
  ↓
Webhook returns: response_text="Confirmed: 1 large pepperoni pizza. Delivery in 30 mins?" + output_context={delivery_context: lifespan=5}.
  ↓
delivery_context activates; next turn, intents requiring delivery_context are eligible.

User: "Make it extra cheese."
  ↓
NLU: matches "modify_pizza" intent (requires delivery_context). ✓
  ↓
Extraction: topping_add = "extra cheese".
  ↓
Fulfillment: webhook modifies order.
  ↓
User: (silent for 3 more turns)
  ↓
delivery_context lifespan expires (was 5, now 0).
  ↓
User: "I want to order another pizza."
  ↓
NLU: matches "order_pizza" intent (no delivery_context required).
  ↓
Order 1 state is lost. Webhook must have persisted to external DB.

Conversational Agents (CX): State Machine Flow

When an end-user provides input to a Conversational Agent:

1. Session Initialization

   • Agent is already in an active state (an active page within an active flow).

   • Default Start Flow's start page is the initial state; first user input triggers this page's entry fulfillment.

2. Input Reception & NLU Pipeline

   • Speech-to-Text (if audio input).

   • NLU classifier runs against intents reachable from the currently active page (not all intents in the agent).

   • All intents defined in the current page's routes are candidates.

   • Additionally, intents from parent flows (if this is a sub-flow page) and intents with is_fallback: true at the flow level are eligible.

3. Route Matching & Evaluation

   • The system evaluates routes in order (priority-based, top to bottom in the page's route list).

   • Each route is a condition-action pair:

     • Route type 1: Intent Route — if a user input matches intent X, evaluate this route.

     • Route type 2: Conditional Route — if a backend condition (parameter values, service responses) is true, evaluate this route.

     • Route type 3: Event Route — if a system event occurs (no-match, no-input, timeout, custom event), evaluate this route.

   • The first route whose condition is true is selected.

4. Parameter Collection & Form Filling

   • If the active page defines a form (a list of required parameters), the agent enters form-filling mode.

   • For each missing parameter, the agent:

     • Displays the configured prompt message for that parameter.

     • Receives user input.

     • Runs entity extraction for that parameter's entity type.

     • Validates the extracted value against the parameter's validation rules (if any).

     • Stores the parameter in $session.params[param_name].

   • Once all required parameters are collected, form filling completes.

5. Route Fulfillment Execution

   • After a route condition is satisfied, the route's fulfillment executes.

   • Fulfillment is optional: a route may have no fulfillment, static fulfillment messages, or a webhook call.

   • If a webhook is configured, the request includes:

     • detectIntentResponse.queryResult.intent (the matched intent, if intent-triggered).

     • detectIntentResponse.queryResult.parameters (session parameters + extracted parameter values).

     • Custom webhook tag (defined on the fulfillment resource).

   • Webhook response contains agent responses, parameter mutations, session state updates.

   • Critically: fulfillment is route-specific, not intent-specific. Different routes from the same page can have different fulfillment logic.

6. Page Transition

   • Each route specifies a target_page (or target flow's start page).

   • After fulfillment, the agent transitions to the target page.

   • The target page becomes the new active page; its entry fulfillment (if any) executes immediately.

   • Example: User on "collect_address" page provides address → matches "provide_info" intent → route targets "confirm_address" page → confirm_address's entry fulfillment runs.

7. Session Parameters Lifecycle

   • All parameters collected via forms or extracted via intents are stored in $session.params.

   • Session parameters persist across all pages and flows in a session.

   • Parameters are immutable via entity extraction alone; only webhook or form-defined fulfillment can mutate parameters.

   • Parameters are cleared only when:

     • Explicitly set to null in fulfillment.

     • Session is terminated.

     • User-invoked parameter reset (rare, typically via a reset event handler).

8. Advanced Routing: Conditions & Event Handlers

   • A conditional route can trigger based on parameter state:

     route: IF @session.params.order_total > 100 THEN target_page = "premium_delivery_options"
     

   • Event handlers intercept specific events:

     • no_match: user input doesn't match any intent on the page.

     • no_input: user doesn't provide input (timeout in voice mode).

     • Custom events: webhook can trigger custom events for granular control.

   • Event routes allow graceful error handling without jumping to a fallback page.

9. Session Termination

   • The page's fulfillment sets end_interaction: true, or a specific "end session" route is triggered.

   • Session terminates; the agent is no longer active for this session_id.

Session Parameter Durability:

• Session parameters are persistent and scoped to a single session_id.

• They survive across all pages, flows, and webhook calls within the session.

• No TTL decay; parameters exist until explicitly cleared or session ends.

• This eliminates the context-chaining complexity: developers reference $session.params.critical_value without worrying about context expiration.

Example CX Flow (Pizza Order Agent):

Session starts in "Default Start Flow" → "start" page (active page = "start").

Entry fulfillment: "What would you like to order?"

User: "I want to order a large pepperoni pizza."
  ↓
Route evaluation on "start" page:
  - Route 1 (intent): IF user intent = "order_pizza" THEN target_page = "collect_order_details"
    ✓ Matched.
  ↓
  - Fulfillment (route-level): None defined; use default.
  ↓
Transition: Active page = "collect_order_details".

Entry fulfillment of "collect_order_details" page:
  - Form: [required_param: size, topping]
  - Parameters filled by extraction or explicit form prompting.
  - \(session.params.size = "large", \)session.params.topping = "pepperoni"

Form-fill complete → Entry fulfillment of this page continues:
  - Webhook: "Confirm order for large pepperoni? (yes/no)"
  - $session.params.order_id = 12345 (webhook response)

User: "Make it extra cheese."
  ↓
Route evaluation on "collect_order_details" page:
  - Route 1 (intent): IF user intent = "modify_order" THEN target_page = "customize_order"
    ✓ Matched.
  ↓
Transition: Active page = "customize_order".

Entry fulfillment of "customize_order" page:
  - Webhook: "Modifying order " + $session.params.order_id + " with extra cheese."
  - Updates backend; $session.params.order_confirmed = true

User: (3 turns pass; user is browsing other options)
  ↓
Session persists; $session.params still contains order_id, size, topping.

User: "Confirm my order."
  ↓
Route evaluation (from wherever the user is):
  - Route matches "confirm_order" intent → target_page = "order_confirmation"
  ↓
Entry fulfillment of "order_confirmation":
  - Webhook: "Confirming order " + \(session.params.order_id + " with size=" + \)session.params.size
  - order_id and size are still available. No context chaining required.

Fulfillment & State Management: The Operational Divide

Dialogflow ES: Fulfillment as Intent Response

In ES, fulfillment is the consequence of intent matching. The fulfillment resource (text, webhook, etc.) is defined on the intent itself. This coupling creates several constraints:

1. Single Fulfillment per Intent

   • An intent has one set of fulfillment responses.

   • If three different user paths all match the same intent, all three get the same fulfillment logic.

   • Workaround: Create separate intents for slight intent-matching variations and manage them via context filtering. This scales poorly.

2. Webhook Responsibility Overload

   • The webhook must extract context from the request and determine what action to take.

   • Intent name alone is insufficient for complex flows; the webhook must inspect parameters and session context to infer application state.

   • Example:

     {
       "intent": {
         "name": "order_pizza",
         "displayName": "order_pizza"
       },
       "parameters": {
         "size": "large",
         "topping": "pepperoni"
       },
       "outputContexts": [
         {
           "name": "projects/p/agent/sessions/s/contexts/delivery_context",
           "lifespanCount": 5,
           "parameters": { "delivery_method": "pickup" }
         }
       ]
     }
     

   • Webhook logic:

     if intent == "order_pizza":
       if "delivery_context" in outputContexts:  # Check context
         # User is modifying a previous order
         return update_order(order_id, parameters)
       else:
         # First-time order
         return create_order(parameters)
     

   • Any deviation from the expected context stack causes incorrect behavior.

3. Context Decay & Complexity

   • Contexts expire mid-conversation.

   • Critical data (order ID, user preferences) must be re-extracted or stored externally.

   • Developers resort to writing every critical parameter to a backend database and re-querying it on each webhook invocation.

   • This creates operational overhead: database round-trips, cache invalidation, session synchronization.

Conversational Agents (CX): Fulfillment as Route Action

In CX, fulfillment is the action on a route, not a property of the intent. This decoupling has profound effects:

1. Multi-Response Routing

   • A page can have 5 routes, each with a different next page and different fulfillment logic.

   • All 5 routes might match the same intent, but the fulfillment (and transition) differs based on route conditions.

   • Example: A page "confirm_address" has two routes:

     Route 1: IF intent = "confirm" AND $session.params.delivery_distance <= 5 THEN fulfillment = "Fast delivery available. Proceed to payment." → target = "payment_page"
     Route 2: IF intent = "confirm" AND $session.params.delivery_distance > 5 THEN fulfillment = "Standard delivery (3-5 days). Proceed to payment?" → target = "payment_page"
     

   • Same intent, different fulfillment, triggered by session state (not separate intent contexts).

2. Cleaner Webhook Signatures

   • Webhook receives intent + parameters + explicit route tag.

   • The route tag (defined on fulfillment) tells the webhook which path was taken.

   • Webhook logic is scoped to the specific route, not global to the intent:

     {
       "fulfillmentInfo": {
         "tag": "order_pizza_new"
       },
       "sessionInfo": {
         "session": "projects/p/locations/l/agents/a/sessions/s",
         "parameters": {
           "size": "large",
           "topping": "pepperoni"
         }
       }
     }
     

   • Webhook:

     if tag == "order_pizza_new":
       return create_order(parameters)  # No context checking needed
     elif tag == "order_pizza_modify":
       return update_order($session.params.order_id, parameters)
     

   • Cleaner separation of concerns.

3. Session Parameters as State Store

   • Session parameters persist across all pages in a session without TTL decay.

   • A parameter set on page A is accessible on page Z without any context chaining.

   • Reduces external database dependencies for transient state:

     Page: "collect_address"
       Form: [address (required)]
       Entry fulfillment: "Where should we deliver?"
       → $session.params.delivery_address = extracted_value
     
     Page: "confirm_delivery" (3 pages later)
       Entry fulfillment: "Delivery to " + $session.params.delivery_address + "?"
       → No webhook query needed; parameter is durable.
     

4. Explicit State Transitions

   • Every page transition is explicit: it's defined in the route's target_page.

   • The conversation graph is transparent: you can trace the exact path the session will take.

   • Debugging is simplified: if a user is on page X, you know exactly which routes are available and what their transitions are.

Table: Fulfillment Model Comparison

NLU Isolation: Scope of Intent Matching

Dialogflow ES: Global Intent Pool

• All intents in the agent are candidates for matching on every turn.

• Input contexts narrow the candidate set, but the classifier still considers all training phrases.

• As the agent grows, intent confusion becomes inevitable:

  • "order_pizza" has 30 training phrases.

  • "order_salad" has 25 training phrases.

  • A user says "I want to order." → Both intents have high confidence; the classifier picks one, often incorrectly.

  • More training data is added to disambiguate, which increases false positives elsewhere.

Conversational Agents (CX): Flow & Page-Scoped NLU

• Intents are defined globally, but matched only in the context of the active page.

• Only intents defined on the current page's routes + fallback intents are candidates.

• This dramatically reduces intent pollution:

  • Page "order_pizza" has routes for intents: order_pizza, modify_order, cancel_order, no_match, no_input.

  • Page "order_salad" has routes for intents: order_salad, modify_order, cancel_order, no_match, no_input.

  • When the user is on "order_pizza" page, only order_pizza, modify_order, cancel_order intents compete.

  • "order_salad" intent is irrelevant and not considered.

  • Intent confusion drops dramatically; accuracy improves without adding training data.

Operational Impact:

• ES agent with 200 intents = high cognitive load, debugging nightmares.

• CX agent with 200 intents split across 10 flows = manageable, testable, maintainable.

Versioning, Environments & Release Management

Dialogflow ES

• Draft Mode: A single draft version of the agent is edited live.

• Versions: Snapshots of the agent can be exported or saved as versions (manual, admin-driven).

• Environments: Each version can be deployed to environments (e.g., dev, staging, prod).

• Limitations: Versioning is cumbersome; no automatic rollback. Publishing to production is manual and error-prone.

Conversational Agents (CX)

• Draft Flow: Changes are made to flow definitions in draft.

• Versions: Agents support versioning at the agent level; versions can be created, tested, and promoted.

• Environments: Agents can be deployed to multiple environments (dev, staging, prod).

• Release Management: Environments can be configured with specific versions.

• Improvements: Cleaner promotion pipeline, rollback support, testing against specific versions.

Implication: CX supports CI/CD workflows more naturally; ES requires custom scaffolding.

The Summary Matrix: Feature-by-Feature Evaluation

When to Use Each Platform: Decision Framework

Use Dialogflow ES When:

1. Simple, Single-Turn Interactions

   • FAQ bots, command-based chatbots (e.g., "What's the weather?" → respond).

   • If the conversation is stateless or requires minimal state, ES is sufficient.

2. Rapid Prototyping

   • You have 2–4 weeks to build and test a bot.

   • ES's simpler UI and fewer concepts reduce onboarding time.

3. Limited Intent Complexity

   • Your agent has fewer than 50 intents and limited overlap.

   • Intent confusion is not an issue.

4. Cost-Sensitive Projects

   • Low traffic (< 100K requests/month).

   • ES's lower per-request cost matters at small scale.

5. Legacy Integrations

   • Your team has existing ES webhooks, integrations, and operational knowledge.

   • Migrating to CX is not justified by the feature gap.

Use Conversational Agents (CX) When:

1. Complex, Multi-Turn Conversations

   • E-commerce checkout, customer support with escalation, appointment booking.

   • The conversation graph has more than ~10 decision points.

2. Enterprise-Grade Reliability

   • Conversation state must be predictable and auditable.

   • You need explicit control over routing, not implicit context chaining.

3. Scaling Intent Count

   • The agent will handle 100+ intents.

   • Flow-scoped NLU prevents intent pollution as the system grows.

4. Team-Based Development

   • Multiple teams own different flows (e.g., billing, support, upsell).

   • Separate flows allow parallel development without merge conflicts.

5. Production Release Workflows

   • You need versioning, staged deployments, and rollback.

   • CX's environment support integrates with CI/CD pipelines.

6. Transient State Management

   • Session parameters simplify data plumbing; no need to persist every value to an external database.

   • Webhooks can focus on business logic, not state synchronization.

Migration Considerations: ES → CX

If you're on ES and considering CX:

One-to-One Mapping

Migration Effort Estimate

• Simple bot (< 20 intents, 1 flow): 1–2 weeks.

• Medium bot (20–100 intents, 3–5 flows): 3–6 weeks.

• Complex bot (100+ intents, 10+ flows): 8–16 weeks.

Key Migration Pitfalls

1. Context → Session Parameter Mapping

   • Not all contexts map 1:1 to pages. A context might span multiple pages; you'll need to map it to session parameters that persist across those pages.

2. Webhook Signature Changes

   • ES webhook expects intent, outputContexts, parameters.

   • CX webhook expects fulfillmentInfo.tag, sessionInfo.parameters.

   • Rewrite webhook logic or add an adapter layer.

3. Intent Retraining

   • CX intents are page-scoped. A single ES intent might split into multiple CX intents per flow.

   • Training data distribution changes; confidence scores may shift.

   • Retrain and re-test all intents post-migration.

4. Testing Strategy

   • ES testing: Simulate intents, check responses.

   • CX testing: Simulate conversation flows, check state transitions and fulfillment.

   • Your test cases need to change to account for pages and routes, not just intents.

The Console Transition: Dialogflow CX → Conversational Agents (2026)

Important Note for Current Deployments:

As of October 31, 2025, Google deprecated the standalone Dialogflow CX console. All users are now routed to the Conversational Agents console, which unifies Dialogflow CX and Vertex AI Agent Builder.

Key Facts:

1. The underlying API and runtime are unchanged: Your existing CX agents continue to run without modification.

2. The authoring experience has changed: You interact with a new console UI that integrates CX and Agent Builder features.

3. Roadmap for 2026: Deeper Gemini integration in the flow builder; generative playbooks become the standard for complex agents.

What This Means:

• If you've already built CX agents, they're compatible with the Conversational Agents console immediately.

• New agents should be built in the Conversational Agents console.

• The term "Dialogflow CX" is still used in documentation and API paths (/dialogflow/cx/) but is now accessed via the Conversational Agents console.

• Dialogflow ES remains stable and unchanged; it's accessed via its own console.

For Migration Planning:

• If you're evaluating CX, build new agents in the Conversational Agents console (not the deprecated Dialogflow CX console).

• The feature set and routing model remain identical to traditional CX; the change is UI-level.

Real-World Scenario: Complex Order Processing Workflow

To ground this comparison, here's how each platform would handle a realistic use case: a multi-step e-commerce order workflow with validation, modification, and payment.

Dialogflow ES Approach

Intents:
  1. order_start (required params: product)
  2. select_quantity (required params: quantity)
  3. select_payment_method (required params: payment_method)
  4. apply_promo_code (required params: promo_code)
  5. modify_order (required params: modification_request)
  6. confirm_order (no required params)
  7. GOOGLE_ASSISTANT_WELCOME (fallback)

Contexts (to control flow):
  input context: none
  output contexts: 
    - order_active (lifespan 10)
    - quantity_selected (lifespan 10)
    - payment_pending (lifespan 10)

Flow:
User: "I want to buy a laptop."
  → NLU matches order_start
  → Fulfillment: Extract product, set @product="laptop"
  → Output context: order_active
  → Webhook: Check inventory for laptop

User: "I want 2 units."
  → NLU matches select_quantity (input context: order_active ✓)
  → Fulfillment: Extract quantity, set @quantity=2
  → Output context: quantity_selected
  → Webhook: Calculate price = 2 × laptop_price

User: "Use code SAVE10."
  → NLU matches apply_promo_code (input context: quantity_selected ✓)
  → Fulfillment: Extract promo_code, validate in webhook
  → Webhook: Apply discount, return updated price

User: "Can I change the quantity to 3?"
  → NLU matches modify_order (input context: quantity_selected ✓)
  → Fulfillment: Extract new quantity
  → Webhook: Call modify-order endpoint
  → Problem: quantity_selected context has already aged; might not be active. Webhook must query the database to infer state.

User: "Confirm my order."
  → NLU matches confirm_order (input context: payment_pending ?)
  → If contexts have decayed, confirm_order might not be recognized. Fallback intent catches it.
  → Webhook must re-fetch order state from database.

Operational Overhead:
- Contexts constantly decay; webhook must handle state re-hydration.
- If a user is slow or takes many turns, contexts expire unpredictably.
- Webhook becomes a state synchronization layer, not just a fulfillment engine.
- Testing is order-dependent: test scripts must follow the exact turn sequence.

Conversational Agents (CX) Approach

Flows:
  1. Default Start Flow
     Pages:
       - start
       - product_selection
       - quantity_selection
       - coupon_application
       - payment_selection
       - order_confirmation
       - order_summary

  2. Order Management Flow (triggered from payment_selection if user requests modifications)
     Pages:
       - modify_order
       - review_modifications
       - apply_modifications

Intents (reusable, defined once):
  - select_product
  - select_quantity
  - apply_coupon
  - select_payment
  - confirm_order
  - modify_order
  - no_match
  - no_input

Pages & Routes:

Page: product_selection
  Entry fulfillment: "Which product do you want?"
  Form: [product (required)]
  Routes:
    - Route 1 (intent: select_product) → $session.params.product = extracted_product → target: quantity_selection
    - Route 2 (event: no_match) → "Sorry, we don't have that product. Try again."

Page: quantity_selection
  Entry fulfillment: "How many units?"
  Form: [quantity (required)]
  Routes:
    - Route 1 (intent: select_quantity) → 
        fulfillment: Webhook tag="calculate_price" → $session.params.price = webhook_response
        target: coupon_application
    - Route 2 (event: no_match) → "Please enter a number."

Page: coupon_application
  Entry fulfillment: "Have a coupon code? (optional)"
  Routes:
    - Route 1 (intent: apply_coupon) → 
        fulfillment: Webhook tag="validate_coupon" → $session.params.discount = webhook_response
        target: payment_selection
    - Route 2 (condition: no coupon) → 
        $session.params.discount = 0
        target: payment_selection

Page: payment_selection
  Entry fulfillment: "Choose a payment method. Current total: " + $session.params.price
  Routes:
    - Route 1 (intent: select_payment) → 
        target: order_confirmation
    - Route 2 (intent: modify_order) → 
        target: Order Management Flow / modify_order page
    - Route 3 (condition: $session.params.price > 1000) → 
        fulfillment: "Note: Orders over $1000 may require additional verification."
        target: payment_selection

Flow: Order Management Flow / Page: modify_order
  Entry fulfillment: "What would you like to modify?"
  Routes:
    - Route 1 (intent: modify_order AND condition: modification_type=="quantity") → 
        fulfillment: Webhook tag="modify_quantity" → updates \(session.params.product, \)session.params.quantity, $session.params.price
        target: review_modifications

Page: review_modifications
  Entry fulfillment: "Review your updated order: " + \(session.params.quantity + "x " + \)session.params.product + " = " + $session.params.price
  Routes:
    - Route 1 (intent: confirm_order) → 
        target: Default Start Flow / payment_selection (back to main flow)

Page: order_confirmation
  Entry fulfillment: Webhook tag="create_order" → $session.params.order_id = webhook_response
  Routes:
    - Route 1 (intent: confirm_order) → 
        target: order_summary

Page: order_summary
  Entry fulfillment: "Order confirmed! ID: " + \(session.params.order_id + ". Total: " + \)session.params.price
  end_interaction: true

Operational Benefits:
- Session parameters (\(session.params.product, \)session.params.price, $session.params.order_id) persist across all pages.
- No context decay; parameters are accessible from any page.
- Webhook is invoked only when specific actions are needed (calculate_price, validate_coupon, modify_order, create_order).
- Fallback handling is explicit: no_match routes on each page define behavior if the user's input doesn't match any intent.
- User can backtrack, pause, or take many turns; session state is stable.
- Testing is independent of turn sequence: you can test each page and route in isolation.
- Different teams can own different flows (Order Management Flow vs. Default Start Flow).

Conclusion: The Architectural Shift

The gap between Dialogflow ES and Conversational Agents is not a feature upgrade; it's a paradigm shift. ES is intent-centric and context-driven, suitable for simple, linear conversations. CX is state-machine-centric and route-driven, built for complex, branching conversations at enterprise scale.

If you're building a bot in 2026, the decision is straightforward:

• < 50 intents, simple flow, rapid prototyping, cost-sensitive → Dialogflow ES.

• > 50 intents, multi-turn logic, team-based development, production release workflows → Conversational Agents (CX).

The ES to CX migration is non-trivial but manageable with clear planning. The architectural clarity CX provides pays dividends as your bot scales.

Resources & References

• Dialogflow CX Documentation

• Conversational Agents Console Overview

• Migrating from Dialogflow ES to Dialogflow CX

• Agent Settings & Advanced NLU

• Dialogflow Release Notes (2026 Updates)

• Voiceflow Review on Dialogflow 2026 Roadmap