Choose a retrieval ownership model

Learning objective

Choose among Agent Retrieval, Vector Search, RAG Engine, and application-managed retrieval by matching their ownership boundaries to the workload. Retrieval tuning is outside this lesson.

Core idea

Choose by asking which layer should the platform own. These options are not four versions of the same component:

• Agent Retrieval stores data objects, payload data, and vectors together and exposes semantic, text, vector, and hybrid search.
• Vector Search is a managed approximate nearest neighbor (ANN) index service. Your surrounding system prepares embeddings and owns more of the ingestion and RAG workflow.
• RAG Engine is a managed framework for a corpus-oriented RAG pipeline, including ingestion, transformation, embedding, indexing, and retrieval.
• Application-managed retrieval leaves workflow composition and operation to your application, even when individual components are managed.

The decision is about workflow ownership, not whether one component is managed. RAG Engine can use a separately provisioned vector store, and custom code can call a managed search service.

How the options divide responsibility

Agent Retrieval

Choose Agent Retrieval when the application needs a reusable search layer with low index-management overhead. A collection holds JSON data objects, and a collection index enables ANN search over their vector fields. The service can generate embeddings automatically or accept your embeddings. It also supports full-text, semantic, and hybrid search and returns payload fields with results. Google Cloud describes this as a unified storage and retrieval system rather than an index-only service in the Agent Retrieval overview.

This boundary suits applications that need direct query control without operating search infrastructure. It does not own document parsing, prompt construction, generation, or application policy.

Vector Search

Choose Vector Search when vector matching is the specialized infrastructure problem and your team wants explicit control over the ANN index. You prepare embeddings, configure an index, create an index endpoint, and deploy the index. The service supports dense, sparse, and hybrid vector search, as documented in Before you begin with Vector Search.

This boundary fits large workloads and custom embedding pipelines. The application still coordinates source content, embedding generation, payload lookup, prompt assembly, and generation. Compared with Agent Retrieval, Vector Search exposes more index and endpoint lifecycle work.

RAG Engine

Choose RAG Engine when the primary requirement is document grounding and you want a managed RAG workflow rather than only a search service. A RAG corpus connects ingestion, chunking, embedding, indexing, and retrieval. RAG Engine then supplies retrieved context to a generative model. These stages are defined in the RAG Engine overview.

RAG Engine’s default RagManagedDb requires no separate database provisioning. You can instead connect a supported vector database and own its lifecycle and scale. The RAG Engine vector database choices make this separation explicit. Choose RAG Engine for a file corpus and managed ingestion, not merely because the application uses vectors.

Application-managed retrieval

Choose application-managed retrieval to join live transactional rows, combine vector search with graph traversal, use an existing system of record, apply domain-specific query plans, or maintain provider portability.

Your code then owns synchronization, parsing, chunking, embeddings, queries, filters, reranking, context assembly, and failure handling. Components can remain managed. For example, Google’s Vector Search RAG reference architecture uses application services to parse and chunk content, generate embeddings, query Vector Search, construct the augmented prompt, and call the model.

Key distinctions and trade-offs

Use this decision table to identify the narrowest sufficient ownership model:

Retrieval service versus RAG workflow: Agent Retrieval and Vector Search return ranked data. RAG Engine coordinates more of the path from source files to model context. Every option still needs answer evaluation and application authorization.

Managed component versus managed architecture: Using a managed vector database inside custom code does not make the complete retrieval architecture managed. Conversely, RAG Engine can sit over a vector database whose lifecycle you manage.

Control versus ownership cost: More control supports unusual retrieval logic but creates more interfaces, failure modes, and operational work. Prefer the highest-level service that meets hard requirements.

Architecture / decision scenario

A manufacturer is building an agent that answers maintenance questions from manuals and also reports live spare-part inventory.

The manuals need standard document parsing, chunking, embedding, refresh, and context retrieval. The team chooses RAG Engine because it wants the managed pipeline and RagManagedDb is sufficient.

Inventory remains authoritative in a transactional database. “Can I replace this pump today?” needs a manual procedure, a permitted part-number lookup, and current stock. Copying inventory into a document corpus would duplicate changing state. The application therefore manages this retrieval path and combines its database result with RAG Engine context before generation.

The team would use Agent Retrieval for a shared catalog needing stored objects plus several search modes. It would use Vector Search if its own embedding pipeline and explicit ANN index deployment were requirements. One product need not serve every knowledge source.

Common exam traps

• Treating Agent Retrieval and Vector Search as synonyms. Agent Retrieval is a unified data-and-retrieval system; classic Vector Search is an ANN index-as-a-service system.
• Selecting RAG Engine whenever vector similarity appears. RAG Engine manages a broader corpus RAG workflow; vector search also supports recommendation and general similarity workloads.
• Assuming RAG Engine requires its default vector database. It can connect to supported alternatives, with lifecycle responsibility shifting to you.
• Calling an architecture “application-managed” only when every component is self-hosted. Application code can orchestrate managed databases and APIs.
• Choosing maximum customization without a requirement that needs it. Extra control also means extra integration, testing, and operational ownership.
• Assuming a managed retrieval product automatically enforces the application’s end-user authorization or guarantees grounded answers.

What to remember

• Choose by deciding which layer should own the retrieval workflow.
• Use Agent Retrieval for unified data and search with low infrastructure management, and Vector Search for explicit ANN index serving.
• Use RAG Engine for a managed, corpus-oriented path from ingestion to retrieved model context.
• Use application-managed retrieval for custom plans, live joins, existing stores, or portability that managed workflows cannot provide.
• Managed components do not remove your responsibility for authorization, evaluation, and failure handling.

Knowledge check

References

• Google Cloud, Agent Retrieval overview
• Google Cloud, Search for data objects in Agent Retrieval
• Google Cloud, Vector Search overview
• Google Cloud, Before you begin with Vector Search
• Google Cloud, RAG Engine overview
• Google Cloud, Vector database choices in RAG Engine
• Google Cloud Architecture Center, RAG infrastructure using Agent Platform and Vector Search