Book TOC · Previous · Chapter 3 of 8 · Next

Chapter 3: Custom Agentic Workflows in Code: Models, ADK, Sessions & Memory Bank

Official Exam Guide Subsections Consolidated: 3.1

Chapter Consolidation Telemetry: Synthesizes 43 architectural scenarios across 1 Exam Subsections and 4 Official Considerations into consolidated takeaway pillars, paired with 1 Reference Architecture Mermaid Diagrams and 10 Curated Visual Illustrations.

Chapter Focus: Gemini Flash vs. Pro routing, ADK Sequential/Parallel/Loop/Coordinator patterns, Session state vs. Memory Bank, and context window compaction.

Subsection 3.1: Designing and Building Custom Agentic Workflows in Code: Models, ADK, Sessions, Memory Bank, and CLI Skills

Part III: Developing Custom Agents (~33% of Exam) · 4 Official Considerations · 43 Scenarios Consolidated

Domain Overview and Reference Architecture

Engineering Code-First Agents: Model Economics, Stateless Checkpointing & Dual-Tier Memory

Welcome to Part III: Developing Custom Agents, which carries the single largest weight on the Professional Agentic Architect exam (~33%). In Subsection 3.1, you transition from using low-code builders and coding assistants to writing custom production agentic systems in code using the Google Agent Development Kit (ADK) and open-source frameworks.

Four architectural pillars define this chapter:

1. Model Selection & Routing Economics (3.1a): A production multi-agent system rarely uses a single model for every node. Using a frontier Large Language Model (LLM) like Gemini Pro to classify simple intents at 10,000 QPS wastes budget and violates sub-second latency SLAs. Conversely, using a Small Language Model (SLM) to synthesize a 500-page legal discovery corpus fails on reasoning depth and context length. You must know when to pair SLM routers (Gemini Flash-Lite / Gemma) with LLM planners (Gemini Pro), and when strict regulatory data-residency or air-gapped sovereignty requires self-hosting open-weight models (Gemma, Llama) on GKE from Model Garden versus consuming SaaS Vertex AI endpoints (with Provisioned Throughput for predictable high-volume cost).
2. Building Stateful Agents on Stateless Compute (3.1b): When you deploy a custom ADK or LangGraph agent on Cloud Run, containers scale horizontally and terminate at will. Storing conversation history in local Python memory (dict) guarantees data loss. You must architect externalized checkpointers backed by Cloud Firestore or Memorystore for Redis, and pass large binary blobs via Cloud Storage URIs.
3. Dual-Tier Memory Architecture (3.1c): Architects must strictly separate Short-Term Session State (Managed Sessions, sliding windows, running summaries, strict TTLs) from Long-Term Cross-Session Memory (Agent Platform Memory Bank, which asynchronously distills durable user facts and preferences across sessions with strict multi-tenant namespace isolation).
4. Operating Skills via Agents CLI (3.1d): Governing when Agents CLI runs skills autonomously in Agent Mode (CI/CD pipelines) versus requiring interactive confirmation in Human Mode (high-risk production mutations).

Core Foundational Primitives & Mental Models (Subsection 3.1)

Official Exam Considerations & Consolidated Takeaways (Subsection 3.1)

Consideration 3.1a: Selecting and configuring the appropriate language model (e.g., large language model [llm] vs. small language model [slm], self-hosted vs. software as a service [saas], and open-source software [oss] vs. proprietary llm) considering cost, security, and agent architecture

When evaluating model selection scenarios across LLM vs. SLM, SaaS vs. Self-Hosted, and Proprietary vs. Open-Source (OSS):

• Tiered SLM → LLM Routing: Use a lightweight SLM (Gemini Flash-Lite, Gemini Flash, or a fine-tuned Gemma model) for high-frequency, low-latency tasks like intent routing, PII classification, or simple JSON extraction, and route only complex multi-step reasoning or synthesis tasks to a frontier LLM (Gemini Pro).
• SaaS Managed APIs vs. Self-Hosted OSS on GKE: Default to Vertex AI SaaS endpoints (Gemini LLMs) for zero infrastructure management, native 1M–2M token context windows, and built-in Context Caching. Choose Self-Hosted Open-Weight Models (Gemma, Llama, Mistral from Model Garden) on GKE with GPUs/TPUs only when the scenario mandates air-gapped/disconnected operation, full weight-level control, or strict regulatory rules forbidding external multi-tenant SaaS APIs.
• Pay-As-You-Go vs. Provisioned Throughput: For steady, high-volume enterprise production pipelines requiring guaranteed QPS and predictable monthly cost, purchase Vertex AI Provisioned Throughput rather than relying solely on dynamic pay-as-you-go tokens.

Takeaway 1: Latency and Cost Optimization with SLM Routers (vertex_ai:gemini · vertex_ai:model_garden)

• Core Concept: Hierarchical Model Selection (SLM vs. LLM)
• Scenario Trigger & Requirement: A high-volume platform experiencing high token costs and latency during the triage stage of an agentic workflow. The key requirements are reducing operational cost and response latency while maintaining deep reasoning capability for technical troubleshooting tasks.
• Winning Architecture & Implementation: Deploy a lightweight small language model (SLM) for intent classification and routing, and invoke a frontier large language model (LLM) only for complex multi-step reasoning. Using a hierarchical model architecture is a recommended design pattern for agentic workflows. Small language models (SLMs) or lightweight models (such as Gemini Flash or Gemma) feature significantly lower latency and lower token inference costs, making them ideal for high-volume, structured tasks like query triage, intent detection, and routing.
• Exam Traps to Reject: Sending all initial traffic through a large frontier model is costly and introduces unnecessary inference latency. SLMs alone often lack the reasoning capability required to solve complex technical troubleshooting tasks.

Takeaway 2: Data Sovereignty and Isolation in Regulated Banking (vertex_ai:endpoints · vertex_ai:model_garden · vpc:private_service_connect)

• Core Concept: Self-Hosted Open-Source Models vs. Multi-Tenant SaaS
• Scenario Trigger & Requirement: Two strict compliance constraints: customer PII must never leave the bank's VPC network, and model inference must run on dedicated, non-shared infrastructure without external SaaS API dependencies. You need an architecture that combines self-hosted open-source models with private networking.
• Winning Architecture & Implementation: Deploy an open-source model to a dedicated Vertex AI private endpoint connected to your VPC network. Deploying an open-source foundation model (such as Gemma or Llama) onto dedicated compute infrastructure with Vertex AI private endpoints ensures that inference traffic stays entirely within your Virtual Private Cloud (VPC) network.
• Exam Traps to Reject: Default Gemini endpoints run on shared multi-tenant SaaS infrastructure rather than isolated dedicated instances. Cloud NAT still sends customer PII outside the VPC network to external SaaS providers.

Takeaway 3: Predictable Cost Modeling for Continuous High-Throughput Pipelines (gke · compute_engine:gpus · vertex_ai:model_garden)

• Core Concept: Fixed-Cost Self-Hosted Infrastructure vs. Pay-Per-Token SaaS
• Scenario Trigger & Requirement: A scenario with two key technical constraints: continuous high-throughput traffic (500 requests per second 24/7) and a business requirement for a flat, predictable monthly budget without token-based cost variability. You must choose between pay-per-token managed SaaS APIs and self-hosted infrastructure with reserved capacity.
• Winning Architecture & Implementation: Deploy an open-source language model on Google Kubernetes Engine (GKE) with dedicated GPUs and purchase Committed Use Discounts (CUDs). Hosting an open-source language model on dedicated infrastructure, such as Google Kubernetes Engine (GKE) backed by GPUs, establishes a predictable infrastructure cost baseline.
• Exam Traps to Reject: Scaling to zero is designed for sporadic traffic, not for continuous 24/7 baseline loads. Pay-per-token APIs generate variable consumption charges that do not satisfy flat budget constraints at high throughput.

Takeaway 4: Massive Context Analysis for Legal Discovery Agent (vertex_ai:gemini · vertex_ai:model_garden)

• Core Concept: Proprietary Frontier LLM with Ultra-Large Context Windows
• Scenario Trigger & Requirement: The scenario requires an automated agent to process over 800,000 tokens of legal text in a single execution step while avoiding complex document chunking or RAG pipelines. Key considerations include model context capacity, operational overhead (fully managed vs. self-hosted), and retrieval accuracy over massive document lengths.
• Winning Architecture & Implementation: Select a fully managed frontier model with an ultra-large context window, such as Gemini 1.5 Pro on Vertex AI. Gemini 1.5 Pro provides a native context window of up to two million tokens. This capability allows an agent to ingest large document sets directly into the prompt context without requiring vector chunking heuristics or complex Retrieval-Augmented Generation (RAG) pipelines.
• Exam Traps to Reject: Truncating data to 32,000 tokens discards most of the 800,000 tokens of legal documents. Self-hosting large models introduces high operational overhead, and sliding-window attention fails to preserve long-range cross-document references.

Consolidated Golden Rules (Consideration 3.1a):

• Hierarchical model design routes high-frequency classification tasks to lightweight SLMs to reduce cost and latency.
• Frontier LLMs should be reserved for complex reasoning, planning, and specialized domain troubleshooting.
• Avoid using large, expensive models for tasks that require only simple intent triage.
• Choose self-hosted open-source models deployed to private endpoints when strict regulatory mandates require full compute isolation and internal network boundaries.
• Multi-tenant SaaS model endpoints route requests through managed shared cloud infrastructure.
• Private endpoints ensure traffic between your agent workloads and language models stays within your private VPC network.

Consideration 3.1b: Building custom agents using open-source libraries (e.g., agent development kit [adk])

When architecting code-first agents with the Google Agent Development Kit (ADK) or LangGraph:

• External Checkpointing on Stateless Compute: Serverless containers on Cloud Run do not share memory, and session affinity is best-effort. Always configure an external Checkpointer / Session Service backed by Cloud Firestore or Memorystore for Redis (or deploy directly to Agent Runtime [Agent Engine], which provides built-in managed session persistence).
• Handling Mid-Turn Crashes & Human-in-the-Loop Interrupts: Checkpointing after every graph node allows an agent to pause before a high-risk tool call, wait hours or days for human approval, and resume execution from the exact saved state snapshot on any container instance without re-running completed upstream tools.
• Claim-Check Pattern for Large Artifacts: Never serialize a 50MB PDF or dataset directly into the ADK/LangGraph state object (causes database write bottlenecks and context window explosion). Write the file to Cloud Storage and pass only the lightweight gs://bucket/object URI inside the shared state dictionary!

Takeaway 1: Distributed State Persistence in Multi-Turn Agent Workflows (cloud_run · firestore · memorystore)

• Core Concept: Session and checkpoint persistence with open-source agent frameworks
• Scenario Trigger & Requirement: Deploying an open-source agent framework on Cloud Run, which is a stateless, autoscaling compute service. The key challenge is preserving agent checkpoint state across multi-turn interactions where subsequent requests may arrive at different container instances. The solution must provide low-latency reads and writes and avoid data loss.
• Winning Architecture & Implementation: Configure an external checkpointer backed by Cloud Firestore or Cloud Memorystore to persist conversational checkpoints across turns. Serverless compute platforms such as Cloud Run are inherently stateless and scale up or down dynamically. When building custom multi-turn agents with open-source frameworks (such as LangGraph or Google Agent Development Kit), each turn requires loading the conversation history and intermediate tool-execution state.
• Exam Traps to Reject: Session affinity does not guarantee state persistence because container instances can scale down or restart at any time. Batching state exports at the end of a session causes state loss during intermediate conversational turns.

Takeaway 2: Dynamic OpenAPI Tool Ingestion with Vertex AI Extension Compatibility (vertex_ai:gemini · vertex_ai:tool_calling)

• Core Concept: Tool declaration and dynamic schema translation
• Scenario Trigger & Requirement: The scenario requires dynamically integrating internal REST microservices defined by OpenAPI 3.0 specifications into a custom agent on Vertex AI. The key requirements are dynamically translating endpoints into model-compatible tool declarations and enforcing strict runtime parameter validation to avoid invalid backend API requests.
• Winning Architecture & Implementation: Parse the OpenAPI specifications into FunctionDeclaration objects with JSON Schema parameters, and validate the model arguments against the schema with a runtime validator before executing backend API requests. Converting OpenAPI 3.0 specifications into native FunctionDeclaration objects provides Gemini with structured JSON Schema definitions of endpoints and parameters.
• Exam Traps to Reject: Setting temperature to zero does not provide formal schema enforcement or parameter validation. Text prompts and regular expressions lack structural schema enforcement and bypass native tool calling.

Takeaway 3: Hierarchical Multi-Agent Supervisor Pattern Deployment (vertex_ai:agent_builder · vertex_ai:reasoning_engine)

• Core Concept: Multi-agent orchestration and role decomposition
• Scenario Trigger & Requirement: Two main technical requirements: coordinating specialized worker agents and preventing both circular delegation loops and token bloat. The solution must provide structured routing and state control across agent boundaries.
• Winning Architecture & Implementation: Implement a centralized supervisor agent pattern where worker agents return results directly to the orchestrator instead of communicating with each other. A centralized supervisor (or hierarchical orchestrator) pattern assigns a top-level agent to direct the workflow. The supervisor invokes individual specialized worker agents, collects their outputs, and decides the next step.
• Exam Traps to Reject: Peer-to-peer communication increases token overhead and creates circular handoff loops. Unstructured shared history inflates prompt context size and lacks deterministic termination control.

Takeaway 4: Human-in-the-Loop Interrupt and Resume Patterns (cloud_run · cloud_sql · pubsub)

• Core Concept: Agent interruption and workflow state suspension
• Scenario Trigger & Requirement: The scenario requires an asynchronous human-in-the-loop pattern where an open-source AI agent pauses before executing a high-value transaction, persists state, and resumes from that specific point upon human approval.
• Winning Architecture & Implementation: Configure an interrupt breakpoint before the transaction node to serialize graph state to Cloud SQL by thread ID, send a notification, and resume the graph using the thread ID upon approval. When building human-in-the-loop (HITL) workflows with open-source agent frameworks (such as LangGraph or custom Agent Development Kits), best practice involves setting an interrupt or breakpoint before sensitive actions.
• Exam Traps to Reject: Restarting the agent from the start re-runs past steps and client-side storage is insecure. Continuous polling in a busy loop wastes compute resources and exceeds Cloud Run request timeout limits.

Consolidated Golden Rules (Consideration 3.1b):

• Cloud Run instances are stateless and ephemeral; conversational agent state must never be stored exclusively in container memory.
• Open-source agent frameworks require checkpointer backends to maintain thread state and step execution history across turns.
• Use low-latency, highly available datastores such as Cloud Firestore or Cloud Memorystore for externalized agent state persistence.
• Translate OpenAPI specifications into model-native FunctionDeclaration schemas to support dynamic tool calling.
• Always perform runtime parameter validation before dispatching model-generated tool calls to backend microservices.
• Avoid relying on prompt-based text parsing or low temperature alone for structured API interactions.

Consideration 3.1c: Configuring sessions and memory (e.g., agent platform memory bank and managed sessions)

Distinguish clearly between Session State (Short-Term) and Memory Bank (Long-Term):

• Managed Sessions (Short-Term Conversational State): Tracks the active multi-turn dialogue thread, current tool-call trajectory, and temporary scratchpad variables (session.state). To prevent 200-turn conversations from exceeding token budgets, implement Conversation Summarization + Sliding Window retention.
• Agent Platform Memory Bank (Long-Term Semantic/Episodic Memory): Persists distilled user facts, preferences, and historical summaries across separate sessions (e.g., remembering a customer's preferred seat class or dietary restriction three months later). Use asynchronous state extraction callbacks at the end of a session to distill facts into Memory Bank without adding latency to live user turns.
• Privacy, TTL & Multi-Tenant Isolation: Enforce automated Time-to-Live (TTL) policies on Firestore/Session stores to purge raw logs per GDPR/compliance rules, and strictly scope all Memory Bank queries by authenticated user_id and tenant_id namespaces to prevent cross-tenant memory bleed.

Takeaway 1: Short-Term Conversation History vs. Persistent Long-Term Memory (vertex_ai:agent_builder · vertex_ai:agents)

• Core Concept: Distinguishing Managed Session State from Agent Memory Bank
• Scenario Trigger & Requirement: Two distinct memory requirements: 1) Isolate short-term, turn-level states (payment steps) to the active session. 2) Persist specific entities and user facts (vehicle details) across multiple conversations months apart without overloading prompt tokens.
• Winning Architecture & Implementation: Store current interaction variables in a managed session, and configure an Agent Platform Memory Bank to extract and persist user-level facts across sessions. Using managed sessions for short-term state and an Agent Platform Memory Bank for long-term facts is the recommended architectural pattern.
• Exam Traps to Reject: Memory Bank is for persistent facts rather than temporary workflow states like payment steps. Managed sessions are short-lived and should not be used as persistent storage across months.

Takeaway 2: Strict Session TTL and Privacy Compliance (vertex_ai:agent_builder · vertex_ai:sessions)

• Core Concept: Configuring Session Expiration and Time-To-Live (TTL) Policies
• Scenario Trigger & Requirement: The scenario requires automatically purging active conversational states, variables, and transcripts after exactly 15 minutes of inactivity for privacy and compliance. The core requirement emphasizes reliable server-side enforcement rather than client-dependent state clearing.
• Winning Architecture & Implementation: Set the session time-to-live (TTL) parameter to 900 seconds in the managed session configuration in your code. Vertex AI Agent Builder managed sessions support specifying a time-to-live (TTL) policy directly on the session resource.
• Exam Traps to Reject: Scheduled Cloud Functions add custom maintenance overhead when built-in session TTL settings are already available. Client-side timers fail if the user closes the browser or loses network connection before the timer finishes.

Takeaway 3: Automatic Fact Distillation for User Profiles (vertex_ai:agent_builder · vertex_ai:agents · vertex_ai:memory_bank)

• Core Concept: Automated Memory Bank Ingestion and Extraction
• Scenario Trigger & Requirement: Requires a way to automatically and incrementally extract user facts (sizes, preferences, aversions) from conversational dialogue across sessions. The key constraints are avoiding explicit forms/interruptions and maintaining long-term cross-session memory natively.
• Winning Architecture & Implementation: Enable automated memory extraction on the Memory Bank configuration to continuously synthesize user assertions into long-term memory. Enabling automated memory extraction on the Memory Bank allows the platform to analyze conversation turns asynchronously.
• Exam Traps to Reject: Explicit parameter prompting disrupts natural conversation and goes against passive preference extraction. Regular expressions lack natural language understanding and create unnecessary operational maintenance compared to managed memory services.

Consolidated Golden Rules (Consideration 3.1c):

• Use Managed Sessions to maintain short-term, turn-level conversation state and ephemeral workflow variables.
• Use Agent Platform Memory Bank to persist extracted user facts and preferences across different sessions.
• Avoid stuffing raw chat transcripts into context prompts to optimize token usage and latency.
• Always enforce compliance-driven session expiration using server-side TTL settings rather than client-side logic.
• Managed Sessions store ephemeral turn states and parameters, whereas Memory Bank stores long-term persistent information.
• Session TTL is expressed in seconds (e.g., 900 seconds = 15 minutes) and is evaluated based on inactivity from the last interaction.

Consideration 3.1d: Configuring skills using agents cli (e.g., plugins and agent vs. human mode)

When managing skills and plugins with Agents CLI:

• Agent Mode vs. Human Mode: Use Agent Mode (--agent / headless autonomous mode) when running non-destructive tasks or automated CI/CD evaluation pipelines. Enforce Human Mode (interactive confirmation gate) whenever a skill invokes destructive or production-mutating tools (e.g., dropping database tables, modifying IAM policies, executing financial refunds).
• OpenAPI Plugin Ingestion & Namespace Disambiguation: Agents CLI can ingest standard OpenAPI 3.0 specifications to register external microservices as agent plugins. When multiple registered plugins expose identically named tools (e.g., get_status in both Billing and Shipping plugins), configure explicit tool prefixes / namespaces (billing_get_status, shipping_get_status) and descriptive docstrings so the LLM router never calls the wrong backend.
• Local Emulation & Mocking: Use Agents CLI local emulation with mock tool responses during development so engineers can test agent reasoning loops without hitting live production payment or ERP endpoints.

Takeaway 1: Interactive Human-in-the-Loop Confirmation for High-Risk Skill Invocation (vertex_ai:agents · vertex_ai:reasoning_engine)

• Core Concept: Configuring execution modes (agent vs. human mode) for sensitive skill execution
• Scenario Trigger & Requirement: The scenario requires granular control over agent execution. Autonomous execution is desirable for safe tasks such as read-only invoice lookups, but sensitive, high-impact operations like wire transfers require human-in-the-loop oversight.
• Winning Architecture & Implementation: Set the wire transfer skill execution mode to human mode in the agent skill configuration, while keeping the invoice lookup skill set to agent mode. Configuring the wire transfer skill with human execution mode ensures that the runtime pauses and solicits explicit human approval before executing the tool.
• Exam Traps to Reject: Interception logic inside unrelated tools is anti-pattern and does not use native CLI skill modes. Global human mode pauses all skills rather than selectively gating high-risk actions.

Takeaway 2: Configuring Third-Party OpenAPI 3.0 Plugins via Agents CLI (vertex_ai:agents · secret_manager)

• Core Concept: Registering OpenAPI endpoints and security schemes using CLI tool definitions
• Scenario Trigger & Requirement: The scenario requires integrating an external REST API described by an OpenAPI 3.0 specification into an AI agent using the CLI. The solution must handle API key authentication securely without exposing credentials in source code.
• Winning Architecture & Implementation: Define a tool manifest that references the OpenAPI specification file and configure authentication by referencing a secret stored in Secret Manager. When registering external tools and plugins through the Agents CLI, the recommended and secure approach is to provide the OpenAPI 3.0 specification file and map the required security scheme (such as an API key header) to a secret reference in Secret Manager.
• Exam Traps to Reject: Raw credentials should never be hardcoded into OpenAPI specification files. Plaintext environment variables risk credential leakage and do not integrate with cloud secret management.

Takeaway 3: Local CLI Emulation and Mocking of External APIs (vertex_ai:agents · vertex_ai:reasoning_engine)

• Core Concept: Simulating skill responses during development without incurring live API calls
• Scenario Trigger & Requirement: The scenario requires testing an agentic workflow locally using the CLI while preventing live external API calls to third-party SMS and payment providers, all without modifying the production code.
• Winning Architecture & Implementation: Provide a local mock configuration file to the Agents CLI to stub responses for the gateway skills. Using a local mock configuration file with the Agents command-line interface (CLI) allows you to intercept skill calls and supply deterministic stub payloads.
• Exam Traps to Reject: Blocking firewall egress causes connection failures instead of structured mock responses. Modifying agent source code directly for testing is risky and anti-pattern.

Takeaway 4: Resolving Tool Name Collisions Across Multiple CLI-Registered Plugins (vertex_ai:agent_builder · vertex_ai:reasoning_engine)

• Core Concept: Namespacing and aliasing skills during CLI plugin import
• Scenario Trigger & Requirement: A common tool collision problem where two independent vendor plugins define identically named skills (get_user_profile). The primary constraint is resolving the collision cleanly without modifying external source code.
• Winning Architecture & Implementation: Configure unique namespace prefixes and skill aliases in the agent CLI configuration manifest for each imported plugin. When integrating multiple third-party plugins that have identical function or tool names, defining distinct namespace prefixes or method aliases in your CLI configuration file resolves the ambiguity.
• Exam Traps to Reject: Human-in-the-loop is meant for oversight, not for resolving deterministic naming collisions. Directly modifying upstream third-party plugin schemas breaks updates and creates maintenance overhead.

Consolidated Golden Rules (Consideration 3.1d):

• Enforce human-in-the-loop policies at the individual skill level to secure high-risk actions.
• Keep low-risk and read-only skills in autonomous agent mode to maintain conversational efficiency.
• Avoid global restrictions when fine-grained skill configurations fulfill specific governance requirements.
• External REST services are integrated into agents by providing OpenAPI 3.0 specifications to tool definitions.
• Sensitive credentials like API keys must be referenced via Secret Manager rather than embedded in code or specification files.
• Human-in-the-loop controls are used for operational approvals, not for passing system credentials.

Multi-Constraint Production Architecture Scenarios (Subsection 3.1)

Head-to-Head Architectural Trade-Off Clinic (Subsection 3.1)

Rapid Pattern-Trigger Cheat Sheet (Subsection 3.1)

Curated Official Google Cloud Documentation (Subsection 3.1)

• Vertex AI Agent Builder Overview — Overview of building generative AI agents and programmatic extensions using Google Cloud tooling and frameworks.
• Gemma Open Models Overview — Details lightweight, state-of-the-art open models built from the same research and technology used to create Gemini models, ideal for resource-constrained environments.
• Select a Foundation Model in Vertex AI — Covers criteria for choosing appropriate Gemini and open-source models based on latency, cost, and task complexity requirements.
• Generative AI on Vertex AI overview — Provides detailed information about consuming foundation models as a service through managed APIs in Vertex AI.
• Google Cloud service models and shared responsibility — Explains the shared responsibility model across SaaS, PaaS, and IaaS architectures in Google Cloud.
• Vertex AI Agent Builder Overview — Provides architectural details and capabilities for building enterprise search and conversational agents with managed memory and grounding.
• Vertex AI Agent Builder Sessions Overview — Explains how sessions represent conversations between end users and conversational agents to manage multi-turn state and parameters.
• Explore AI models in Model Garden — Official Google Cloud documentation explaining how to discover, test, and deploy first-party, third-party, and open-source models in Vertex AI Model Garden.
• Agent Registry overview — Centralized catalog to store, discover, and govern tools, skills, MCP servers, and agents.
• Memorystore for Redis Overview — Provides comprehensive architectural details on Memorystore for Redis, emphasizing sub-millisecond latency and in-memory key-value persistence.
• Firestore Overview — Provides an overview of Firestore as a serverless, document-oriented NoSQL database.
• Firestore for LangChain Chat Message History — Details how to persist conversation history and memory in custom GenAI agents using Firestore.

Book TOC · Previous · Chapter 3 of 8 · Next