Skip to lesson

Google CloudProfessional Agentic Architect2026-091.1 Configuring agentic workflows and behavior using low-code tools

Model state with pages

Completed by the knowledge check

Learning objective

Model conversational and operational state with pages in a state-based agent. This lesson focuses on page boundaries, not transition routing or error-handler design.

Core idea

A page represents a meaningful state of the interaction: what the user and system are trying to accomplish now, which information is required, and which handlers are relevant. In CX-style agents, the active page acts like the current state in a state machine.

Use pages for milestones, not individual sentences. A page named Collect delivery details can own the address fields and prompts needed for that milestone. It should not become a second database or contain every branch of the business process.

How it works

A Dialogflow CX session has one active flow and one active page. Google Cloud describes the conversation as a state machine in which pages are states and handlers control transitions; see Pages.

A page can coordinate three kinds of information:

  • Entry fulfillment runs when the page becomes active. It can introduce the state or perform setup.
  • Form parameters define information to collect while the page is active.
  • Page-scoped handlers respond to relevant intents, conditions, and events.

Design a page around a business milestone with a clear entry condition and exit condition. For an appointment workflow, useful pages might be Identify patient, Select appointment, Confirm booking, and Completed. The page name should describe the current state, while session parameters carry values such as the patient identifier and chosen time.

When a page becomes active, CX can prefill form parameters from session parameters or matching intent parameters. It then evaluates in-scope handlers, prompts for an unfilled required form parameter when appropriate, sends queued responses, and waits for more input. This documented page lifecycle means form completion and handler behavior depend on the active page.

Keep conversational state and operational state related but distinct:

  • Conversational state includes the active topic, information being requested, and how to respond.
  • Operational state includes durable business facts such as an order status or approved refund.

A page may mirror an operational milestone, but the backend remains authoritative for consequential state. Entering a Payment complete page must follow a confirmed payment result; the page transition does not itself prove that money moved.

Choose page scope carefully. Put a handler on a page when it applies only in that state. Put reusable behavior at a wider flow scope when it should be available across pages. Overly broad scope can trigger behavior in the wrong context; overly narrow scope duplicates handlers and makes common requests unavailable.

Key distinctions and trade-offs

Page versus flow: A page is one state within a flow. A flow groups a larger topic or process and can contain several pages. Do not create a new flow for each prompt.

Page versus parameter: A page names the milestone; parameters hold values. Creating pages such as Has email and Has phone for every boolean combination causes state explosion. Keep orthogonal values in parameters.

Conversation state versus source-of-truth state: The active page helps the conversation proceed. A transactional system owns the actual order, payment, or case status. Reconcile the page after webhook failures or resumed sessions.

More pages make milestones visible and page-scoped behavior precise. Too many pages produce a brittle graph and repetitive transitions. Too few pages create a large state with unrelated forms and handlers. Split when entry behavior, required data, permitted actions, or completion criteria materially change.

Architecture / decision scenario

A bank builds a card-replacement agent. It uses pages for Verify customer, Identify card, Choose delivery, Confirm replacement, and Completed. Session parameters carry the verified customer reference, selected card token, and masked delivery address.

The Confirm replacement page presents the final details, but only a successful backend result permits movement to Completed. If the tool times out, the agent stays in a recoverable state and checks the request status before trying again.

This design makes the conversation easy to inspect while preserving the card system as the authority for whether replacement occurred.

Common exam traps

  • Creating one page per utterance instead of one page per meaningful state.
  • Storing every parameter combination as a separate page.
  • Treating page entry as proof that an external operation succeeded.
  • Placing state-specific handlers at flow scope, where they can trigger on unrelated pages.
  • Assuming form parameters are always empty on entry; session or intent values can prefill matching parameters.
  • Mixing page modeling with route selection. Pages define states; routes and handlers control movement between them.

What to remember

  • Model a page as a state with a clear milestone and exit condition.
  • Use form and session parameters for values rather than multiplying pages.
  • Scope behavior to the narrowest page or flow where it remains correct.
  • Keep external systems authoritative for operational side effects.
  • Split pages when required data, allowed actions, or completion criteria change.

Knowledge check

References