Skip to lesson

Google CloudProfessional Agentic Architect2026-090 Prerequisites

Place information in the right state layer

Completed by the knowledge check

Learning objective

Distinguish turn state, session state, long-term memory, and external knowledge. This lesson defines the information layers used by agent architectures, not the storage product chosen to implement them.

Core idea

Classify information by its lifecycle and authority before choosing where to store it:

  • Turn state exists to complete one request.
  • Session state maintains continuity across turns in one conversation or workflow instance.
  • Long-term memory carries selected information across sessions.
  • External knowledge remains in an authoritative system outside the agent.

The same fact should not be copied into every layer by default. Wider persistence improves continuity but increases staleness, privacy, authorization, and deletion risk. Store the minimum useful representation and retain provenance.

How it works

Turn state is the working set for the active request: the immediate goal, intermediate plan, current tool results, retry count, and remaining budget. It can be discarded after the turn unless another layer needs a specific result. Turn state is not identical to the model context; the controller may hold structured state that it never sends to the model.

Session state belongs to a session identifier and survives multiple turns. It can contain a selected account, workflow status, preferences that apply to the conversation, and a compact history. The Agent Development Kit (ADK) describes a session as the container for one continuing interaction and exposes session state through a key-value collection; see Sessions and state. Persisted session state supports resumption, but it still has a narrower lifetime than cross-session memory.

Long-term memory contains information deliberately made discoverable in later sessions. Examples include a user’s durable preference, a resolved case summary, or a recurring project constraint. Memory should be curated, scoped to an identity, and retrieved only when relevant. ADK distinguishes session history from a memory service that searches information across sessions in Memory. Memory is not a complete replay of all prior conversations.

External knowledge lives in a source of truth such as a policy repository, product database, ticket system, or document corpus. The agent queries or retrieves it when needed. It has its own owners, update process, permissions, and retention rules. A retrieval index may accelerate access, but the indexed copy is derived data; it does not automatically become authoritative.

Use these questions to place a fact:

  1. Is it needed only to finish the active request? Keep it in turn state.
  2. Must the current workflow or conversation resume with it? Put a structured value in session state.
  3. Will a later, separate session benefit from it, and is retention permitted? Write a curated memory with scope, provenance, and deletion behavior.
  4. Does another system own and update the fact? Keep it as external knowledge and retrieve the current authorized value when needed.

Artifacts form a related but distinct category. A generated report, uploaded image, or large file may be stored outside key-value state and referenced by an identifier. ADK treats artifacts as named, versioned binary data associated with a user or session. The session can store the artifact reference without placing the entire file in every model context.

Key distinctions and trade-offs

History versus state: Conversation history records events or messages. State records the values needed to continue correctly. Replaying history may reconstruct some state, but an explicit state field is easier to validate and query.

Memory versus knowledge: Memory is selected experience associated with an agent or user. External knowledge is independently governed source material. Remembering last month’s product price does not make that value authoritative.

Persistence versus context: Data can be persisted without being sent to the model. Retrieve only the relevant subset into the current context.

Longer retention can improve personalization and recovery. It also increases the chance of using stale facts, crossing tenant boundaries, or retaining sensitive data unnecessarily. Apply expiration, consent, access checks, provenance, and deletion to each persistent layer.

Architecture / decision scenario

A travel agent receives a request to change a flight. The active lookup results and remaining tool budget are turn state. The selected itinerary, traveler confirmation status, and change-workflow step are session state so the user can answer a clarification in the next turn.

The user’s stated preference for an aisle seat may become long-term memory after consent. Live flight inventory and fare rules stay in airline systems as external knowledge and are fetched again before booking. The generated itinerary PDF is an artifact referenced from the session.

The agent does not remember a quoted fare as a durable fact. That value changes and must be revalidated against its source of truth before a consequential action.

Common exam traps

  • Treating the entire prompt or conversation transcript as structured session state.
  • Assuming persisted data is automatically included in model context.
  • Calling all cross-turn data “memory” without separating one session from later sessions.
  • Using memory as the authoritative source for facts owned by an external system.
  • Storing large files in state when an artifact reference is appropriate.
  • Persisting everything for convenience without retention, access, freshness, or deletion controls.

What to remember

  • Turn state completes one request; session state continues one interaction.
  • Long-term memory is curated and retrieved across sessions.
  • External knowledge remains governed by its source of truth.
  • Persistence and model context are separate design choices.
  • Store references to large artifacts and retrieve current authoritative facts before acting.

Knowledge check

References