Choose who manages session persistence

Learning objective

Choose between Agent Platform Sessions and application-managed persistence for an agent’s conversation sessions. Make the choice from ownership and system requirements, not from the name of a storage product. This lesson does not decide which data belongs in a session or in long-term memory.

Core idea

A session is an application abstraction; a database is a storage mechanism. Do not collapse these into one architecture decision.

The session abstraction defines the identity and lifecycle of one conversation: create it, retrieve it, append ordered events and state changes, list it, and delete it. A session implementation must preserve those semantics under retries, concurrent requests, process restarts, and retention rules. The ADK session guide calls this boundary the SessionService.

The persistence choice answers a separate question: Who implements and operates that session contract?

• With managed sessions, Agent Platform implements the contract and stores the session through a service API.
• With application-managed persistence, your application or framework implements the contract over storage that you select and integrate as part of the application architecture.

Cloud SQL is a managed database service, but using it for session tables is still application-managed session persistence. Google manages the database service; your team remains responsible for the session schema and behavior.

How it works

Keep the contract above the backend

An Agent Development Kit (ADK) Session represents one conversation thread and contains its events and state. The SessionService manages session creation, retrieval, event append, listing, and deletion.

ADK provides several implementations of the same abstraction:

• InMemorySessionService keeps data in the process and loses it on restart. It proves that having a session object does not imply persistence.
• VertexAiSessionService uses Agent Platform infrastructure through API calls. It provides persistent, managed sessions on Google Cloud.
• DatabaseSessionService stores sessions in relational tables. The database persists the data, but the application owns the session-layer configuration and operational fit. The database provider may still operate the underlying infrastructure. For example, the ADK documentation identifies database schema migration requirements and concurrency behavior for this implementation.

See the official ADK session-service implementations for the supported implementations and their requirements.

Agent Platform Sessions exposes the same lifecycle concepts as a managed service: start and resume conversations, append events, list sessions, and delete them. When you deploy an ADK agent to Agent Platform, session management can be connected automatically. You can also call the managed Sessions API directly from another framework. See the Agent Platform Sessions overview.

Assign responsibility explicitly

Use managed sessions when standard session behavior fits and you want the platform to operate persistence, scaling, and session lifecycle APIs. This reduces custom code and removes session-schema migrations from the application team. The application still owns important responsibilities: authenticating the caller, mapping the caller to the correct user and session IDs, choosing what to store, and applying an appropriate retention policy. For example, managed Agent Platform sessions require an expiration and delete the session and child events after it expires; the default applies only when the application does not set one. See session time to live.

Choose application-managed persistence when a requirement needs control below the session interface. Examples include a mandated database boundary, a custom event schema or query model, portability outside Agent Platform, integration with existing backup and recovery processes, or application-specific transaction and retention behavior. That control brings work: schema design and migration, serialization compatibility, concurrent append correctness, availability, capacity, backup and restore, deletion, access control, and monitoring.

Key distinctions and trade-offs

The product list comes after this choice. Firestore, Cloud SQL, Memorystore for Redis, and Cloud Storage have different data models and durability properties, but none becomes a session service merely because it can store bytes. If you use one directly, you must still supply the session lifecycle, ordering, concurrency, identity scoping, and deletion semantics. Likewise, a managed session service may use storage internally without exposing a storage product as its contract.

Architecture / decision scenario

A customer-support agent runs on Agent Runtime with several replicas. Users must resume a conversation from another device. The team requires a 30-day session lifetime and standard chronological event history. Ticket records already live in Cloud SQL, but no requirement says that conversation events must share that schema or transaction boundary.

Choose Agent Platform Sessions through VertexAiSessionService. It gives every replica the same session lifecycle API and delegates event persistence and session-table management to the platform. Set the required expiration explicitly. Continue to store authoritative ticket records in Cloud SQL and reference their IDs from session state.

Choosing Cloud SQL for sessions merely because the application already uses it would confuse storage reuse with session ownership. Reverse the decision only if a concrete requirement outweighs the managed option—for example, policy mandates that all conversation events remain in an application-controlled database, or a required custom access and query model cannot be expressed by the managed service. The team must then accept responsibility for a correct SessionService implementation and its operations.

Common exam traps

• Assuming “managed database” and “managed sessions” mean the same thing. They describe different layers and different owners.
• Selecting Firestore, Cloud SQL, Memorystore, or Cloud Storage before defining the session lifecycle and consistency requirements.
• Treating InMemorySessionService as durable because it implements the session interface.
• Assuming managed sessions remove all application responsibility. The application still controls identity mapping, data selection, and retention configuration.
• Choosing application-managed persistence for flexibility without accounting for concurrency, migrations, recovery, deletion, and monitoring.
• Treating the session store as Memory Bank or as the system of record for business entities.

What to remember

• A session is a lifecycle contract; a database is one possible implementation.
• Choose managed sessions when standard semantics and lower operational burden fit the requirements.
• Choose application-managed persistence only when control or integration needs justify owning session correctness and operations.
• A managed storage product does not automatically provide managed session semantics.
• Keep authoritative application records and cross-session memory separate from conversation sessions.

Knowledge check

References

• Google, Session: Tracking individual conversations
• Google, Conversational context in ADK
• Google Cloud, Agent Platform Sessions overview
• Google Cloud, Manage sessions with Agent Development Kit
• Google Cloud, Manage sessions using the console or API