Cloud / Agent Search on Gemini Enterprise Agent Platform Interview questions

Agent Search is Google Cloud's managed search and retrieval service on Gemini Enterprise Agent Platform. You point it at websites, documents or structured records, and it gives you Google-quality search, generative answers and citations without running your own search cluster.

Every result is grounded in the data or applications you connected, so it doubles as an out-of-the-box RAG system for agents and apps.

• Ingest: websites, Cloud Storage files, BigQuery tables, third-party connectors
• Query: ranked results, snippets, summaries with citations
• Ground: feed the retrieved context to Gemini or to your own agent

Agent Search was previously Vertex AI Search, and before that it appeared under the name Generative AI App Builder. It was renamed when Google announced Gemini Enterprise Agent Platform on April 22, 2026 as the evolution of Vertex AI.

Older names still show up in code and URLs. The Discovery Engine API, roles/discoveryengine.* IAM roles and generative-ai-app-builder doc paths were not renamed, so expect both vocabularies in interviews and in production code.

A data store is the repository where Agent Search keeps your ingested, indexed content. It is what actually gets searched.

Each data store has one content type, such as website, unstructured documents, structured records, healthcare or media data. You fill it from a website crawl, Cloud Storage, BigQuery, a third-party connector or direct API calls.

A data store on its own holds data. To give users a search or answer experience you normally attach it to an app, and one app can use several data stores.

An app is the searchable experience built on top of one or more data stores. In the API it is called an engine, and the docs use the two terms interchangeably.

The app holds settings that data stores do not: the edition (Standard or Enterprise), advanced LLM features, serving configs, search tuning and, for agentic setups, the answer agent configuration.

Your application never queries raw storage. It calls the app's serving config, and the app handles retrieval, ranking and answer generation.

Agent Search supports several data store types, and the type decides which features you get.

You choose the type when you create the data store, so decide it before you start importing.

Grounding means the answer is built from content actually retrieved from your data, not from what the model remembers. Agent Search returns passages with citations so a reader can verify each claim.

You can also ground Gemini calls directly: point a retrieval tool at an Agent Search data store and the model answers from your documents. That path supports up to 10 Agent Search data sources and can be combined with Grounding with Google Search for public facts.

A practical test: ask a question your documents cannot answer. A well-grounded setup should report that it found nothing relevant, rather than produce a confident reply from model memory.

Both return text lifted directly from your documents instead of text the model generated.

Both are available for unstructured search and need Enterprise edition. You request them through the extractive content spec on the search request.

In practice, use extractive answers for FAQ-style lookups, and segments when you plan to pass context into an LLM prompt. Because the text is verbatim, you can show it in the UI with a link back to the source file without worrying about paraphrase drift.

A generative summary is a short answer the model writes from the top search results, returned alongside the normal result list. Turn it on with a summary spec in the search request.

You can ask for citations, set how many results feed the summary, and choose to skip adversarial or non-summary-seeking queries. If there is not enough supporting evidence, the service skips the summary instead of guessing.

Core generative answers come with Enterprise edition. The advanced generative answer features need the Advanced LLM features add-on.

The Discovery Engine API is the programmatic interface behind Agent Search. Its resource names still use discoveryengine, for example projects/P/locations/global/collections/default_collection/dataStores/D.

It exposes methods for managing data stores and engines, importing documents, searching, answering, ranking and checking grounding. The Python client library is google-cloud-discoveryengine.

IAM roles such as roles/discoveryengine.viewer and roles/discoveryengine.editor control who can read or change these resources.

In interviews, mention that the older name survives mainly in resource paths and client libraries. A common gotcha is searching the docs for Agent Search and finding no sample code, because many samples still import discoveryengine modules and call methods such as search, answer and import_documents.

Website search lets you index public web pages and offer search, summaries and follow-up questions over them. You give the data store the site patterns to include.

It requires Enterprise edition, and that setting cannot be switched off once an app is attached to a website data store.

There are two modes: basic website search and advanced website indexing. The advanced mode adds features such as extractive answers, search summarization and search with follow-ups.

Before indexing, check that the site is crawlable and that your URL patterns cover only the sections you want. A pattern that matches the whole domain can pull in login pages, archives and duplicate content that dilute relevance.

You can do it in the Google Cloud console or through the API.

1. Open Agent Search and choose Data Stores, then Create data store.
2. Pick the source: website, Cloud Storage, BigQuery or a third-party connector.
3. For websites, decide whether to enable advanced website indexing and pick a location.
4. Name the store and click Create.
5. Attach the store to an app, and turn on Enterprise edition if it holds website data.

If the project hits a quota, request a higher limit and then return to the Data Stores page.

Call documents.import against the data store's default branch and point it at your bucket path.

from google.cloud import discoveryengine_v1 as de

client = de.DocumentServiceClient()
parent = client.branch_path(PROJECT_ID, "global", DATA_STORE_ID, "default_branch")

request = de.ImportDocumentsRequest(
    parent=parent,
    gcs_source=de.GcsSource(input_uris=["gs://my-bucket/docs/*"], data_schema="content"),
    reconciliation_mode=de.ImportDocumentsRequest.ReconciliationMode.INCREMENTAL,
)
operation = client.import_documents(request=request)
operation.result()

Use data_schema="content" for raw files such as PDFs. Structured JSON Lines use a different schema setting.

Large imports run as long-running operations, so wait on the operation result and inspect its error samples. Keep files organized by prefix as well, because a wildcard such as gs://my-bucket/docs/* ingests everything under it, including files you may not intend to expose.

Build a SearchRequest that targets the serving config and add a content search spec with a summary spec.

from google.cloud import discoveryengine_v1 as de

client = de.SearchServiceClient()
serving_config = client.serving_config_path(
    PROJECT_ID, "global", DATA_STORE_ID, "default_config")

request = de.SearchRequest(
    serving_config=serving_config,
    query="What is our refund policy?",
    page_size=10,
    content_search_spec=de.SearchRequest.ContentSearchSpec(
        summary_spec=de.SearchRequest.ContentSearchSpec.SummarySpec(
            summary_result_count=5, include_citations=True)),
)
response = client.search(request)
print(response.summary.summary_text)

summary_result_count controls how many top results the model reads before writing the summary.

Each result in the response also carries the document ID, its fields and any snippets or extractive content you requested. If the summary text is empty, read the skipped reasons, since a skipped summary does not raise an error.

Facets are counts of result values by field, such as brand, category or file type, that let users narrow a result list with a click.

For structured data, a field must be marked as dynamic facetable in the schema before you can request facets on it. You then pass a facet spec in the search request and the response returns each value with its count.

Facets pair well with filters: the user picks a facet value, and your app sends it back as a filter expression.

A serving config is the named endpoint your application calls to query a data store or app. The default one is default_config for search.

It carries the serving-time behavior: boost and ordering controls, synonyms and result-shaping settings. Because those live on the serving config, you can change relevance behavior without touching the ingested data.

Agentic apps expose a different one, default_agent_answer, for streaming answers.

A serving config is also a safe place to experiment. You can create a second config with different boosts, compare it with the default on the same golden queries, and roll the change out by switching which config the application calls.

Two predefined roles cover most work.

Give application runtime identities the narrowest role that works. A service that only issues queries should not hold editor rights.

Grant roles on the project or a narrower resource where possible, and use separate service accounts for ingestion pipelines and for the serving application. That way a leaked query-service credential cannot modify or delete data stores.

Agent Search for Healthcare is a variant for building medically tuned search engines over healthcare data such as FHIR records and clinical content.

It is priced separately from general Agent Search. Use it when general-purpose relevance is not enough because queries involve clinical terms, abbreviations and structured patient or clinical data.

Treat it as a search aid over data you are authorized to use. Compliance, consent and access control stay your responsibility.

Expect extra work around data preparation. FHIR resources must be imported in a supported format, and you should plan de-identification and access policies before indexing anything sensitive. Medical tuning improves relevance, but it does not replace clinical review of the results.

Agent Search for Media provides search and recommendations for media catalogs such as video and audio. It indexes your content metadata and learns from viewing behavior.

Recommendations rely on user events like views and plays. Without events, a recommendation model has nothing to learn from.

Billing is separate for the media data index, media search API requests and media recommendations.

A typical flow is to import catalog metadata, stream user events as people watch or listen, train a recommendation model and then call its serving endpoint. Common recommendation styles include similar items, personalized picks and most-popular lists.

The Ranking API reranks a list of records you already have against a query and returns a relevance score for each.

It does not need an Agent Search data store. You can feed it candidates from any retriever, such as a vector database or keyword engine, and keep the top few for the LLM prompt.

It is useful when recall is fine but the order is poor, because a semantic reranker is usually stronger than the first-stage score.

A typical use is two-stage retrieval: fetch a generous candidate set cheaply, rerank it with this API, and pass only the top handful into the prompt. This lowers token cost and tends to improve answer quality.

The Check Grounding API tests whether a candidate answer is supported by a set of facts you provide. It returns an overall support score and can attribute each claim to the supporting fact.

Use it as a guardrail after generation. If the score falls below a threshold you set, show a fallback message or retry with more context instead of sending an unsupported answer.

It works on answers from any model, not only Agent Search responses.

Typical inputs are the answer candidate and a list of fact passages, optionally with a citation threshold. Requesting claim-level citations lets you highlight which sentences are unsupported before the answer reaches the user.

Data connectors sync content from applications such as Confluence, Jira, Microsoft SharePoint and ServiceNow into Agent Search. Employees then search many systems from one place.

Connectors keep the index fresh and respect source permissions, so results are access-controlled. Together with Agent Platform extensions, they connect first-party, Google and third-party apps.

Check the sync schedule and error log after setup, because a revoked token or missing scope stops syncing without any visible symptom for users. Also decide which spaces, projects or sites to include, so the index holds only content people should find.

Commerce search is an industry-specific offering for retailers. It improves on-site search, product recommendations and browsing on their sales channels, and it is offered through Gemini Enterprise for Customer Experience.

General Agent Search is a flexible toolkit you configure for any content. Commerce search is a packaged retail solution, so product-catalog concerns such as merchandising and shopper behavior are built in rather than assembled by you.

Pick general Agent Search for documents and sites, and the commerce offering when the core problem is a shop catalog.

The Advanced LLM features add-on is separate. It layers advanced generative answers on top of either edition.

You pick the model per app and its data stores, and pricing is per query, so the edition choice is also a cost decision.

Check the feature table before choosing. A common mistake is starting on Standard and then discovering that website search or extractive answers needs Enterprise, which means revisiting both setup and cost for the whole query volume.

Agent Search is a developer building block. You create data stores and apps, call the API and embed search in your own product or agent.

Gemini Enterprise is the finished workplace product: an intranet search, AI assistant and agentic platform for knowledge workers, with prebuilt connectors, an agent gallery and web and mobile apps.

In short, you build with Agent Search, while employees use Gemini Enterprise. Gemini Enterprise apps have their own data store setup, described in its connectors documentation.

A simple rule for interviews: if the buyer is a developer who needs an API and control over ranking, answer Agent Search. If the buyer is a business team that wants a ready assistant over company apps, answer Gemini Enterprise.

Agent Search is a Google-managed search engine. Parsing, indexing, ranking and answer generation are handled for you.

RAG Engine is for do-it-yourself pipelines. You choose the chunking, embedding model and vector backend and assemble the stages.

They also combine well: RAG Engine can use Agent Search as its corpus backend.

To compare them fairly, run the same golden queries through both. Agent Search usually wins on time to a working demo, while RAG Engine wins when you must control chunk boundaries, the embedding model or where the vectors live.

Create the search data store and app first, then create a RAG corpus whose backend is that Agent Search resource.

1. Create a search data store and, if needed, an app.
2. Note the full resource name of the engine or data store (the ENGINE_NAME).
3. Create a RAG corpus that sets Agent Search as its retrieval backend.
4. Call the Gemini GenerateContent API with the RAG corpus resource in the request.

When the corpus resource is in the request, retrieval from Agent Search happens automatically, so the application code stays small.

Retrieval is delegated to Agent Search, so ingestion, parsing and permission settings are managed on the Agent Search side. Keep that in mind when debugging: a bad retrieval result usually needs a fix in the data store, not in the RAG corpus.

You attach an Agent Search data store as a retrieval tool, and Gemini retrieves from it before answering.

from google import genai
from google.genai.types import GenerateContentConfig, Retrieval, Tool, VertexAISearch

tool = Tool(retrieval=Retrieval(vertex_ai_search=VertexAISearch(
    datastore="projects/P/locations/global/collections/default_collection/dataStores/D")))

resp = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Summarize our travel policy.",
    config=GenerateContentConfig(tools=[tool]))

The grounding tool supports up to 10 Agent Search data sources and can be paired with Grounding with Google Search. The caller needs viewer rights, and editor rights to create the instance.

Test it with a question your data cannot answer, and check the response's grounding metadata. It lists the retrieved chunks and sources, which is how you show citations in your own UI. If you also enable Google Search grounding, the model can mix private and public sources, so decide whether that is acceptable for confidential topics.

Unstructured stores hold documents such as PDFs and HTML. Agent Search parses, chunks and indexes the text, so relevance comes from content understanding.

Structured stores hold records with named fields, imported from JSON Lines or BigQuery. The schema matters here: you mark each field as retrievable, indexable, searchable or facetable, and that decides what filters, facets and ordering are possible.

If you need both, attach two data stores to one app instead of squeezing everything into one format.

The choice also affects ingestion effort. Unstructured content needs little preparation beyond parsing options, whereas structured content needs a schema decision up front, and changing indexable or facetable flags later can require reindexing.

You set a default parsing config on the data store and can override it per file type. Parsing runs at ingestion, so changing it later means reimporting.

A mixed collection of born-digital and scanned documents often needs OCR on the scanned part only.

For a mixed archive, split content into separate data stores or file prefixes by type so each gets the parser it needs. Parsing happens at ingestion, so a wrong choice shows up as garbled or missing text in search results and in generated answers.

Chunking splits a long document into passages, so retrieval can return the exact section that answers the question instead of a whole 80-page PDF.

With layout-based chunking you set a chunk size and can include ancestor headings so each chunk keeps its context, such as the chapter title above it. Smaller chunks are more precise but may lose surrounding meaning, and larger chunks carry context but dilute the match.

In the search request you can ask for results at the chunk level rather than the document level, which is what an LLM prompt usually wants.

A useful rule of thumb is to start with a moderate chunk size, test with real questions and adjust. Questions that need one fact favor smaller chunks, while questions that need a procedure or a table favor larger ones that keep the steps together.

Filters exclude results entirely, and boosts only push some results up or down.

# filter: only laptops under 1000
filter = 'category: ANY("laptop") AND price < 1000'

# boost: lift in-stock items
boost_spec = {"condition_boost_specs": [
    {"condition": 'availability: ANY("IN_STOCK")', "boost": 0.5}]}

Boost values run from -1 to 1. Filtering needs the field to be indexable, and a filter that matches nothing returns nothing, so prefer a boost when you only want a preference.

Remember that boosts adjust ranking, not eligibility, so a boosted weak match can still sit below a strong match. Check that the field you filter on is marked indexable, and use ANY for set matches and comparison operators for numbers.

The search method returns ranked results, and can add a summary. The answer method is built for question answering: it understands the query, retrieves, and returns a generated answer with citations.

The answer method also supports query understanding such as rephrasing and classifying queries, and can reference a session for follow-ups.

For a chat UI, answer is the natural choice, because it can use query understanding and a session for follow-ups. Many products use both: search to render the result list and filters, and answer to show a summary panel beside it.

Blended search lets a single app query several data stores at once, for example a website store, a document store and a structured store, and return one merged result list.

It suits cases where users should not need to know where an answer lives. The trade-off is that the stores share one app's settings, so choose it when relevance rules can be common across the sources.

Multi-turn conversation across several stores is a related limit. Without agentic retrieval, multi-turn search works only with single data store apps.

Operationally, check that each source has the permissions and freshness you expect, because a blended result list is only as good as its weakest store. If one source is stale or noisy, consider boosting trusted sources or splitting the apps.

The reconciliation mode on documents.import decides what happens to documents already in the branch.

Use incremental for daily deltas. Use full when the source of truth is a complete snapshot, but test first, since a partial file under FULL mode deletes everything missing from it.

Schedule the jobs accordingly. A nightly incremental import of changed files is cheap and safe, while a weekly full import works as a clean-up pass that removes documents deleted at the source. Always check the operation's error count after each run.

Search tuning fine-tunes the ranking behavior of an unstructured data store using your own queries and relevance labels, so results favor your domain's vocabulary. It needs Enterprise edition.

Typical inputs are the document corpus, a set of representative queries and training labels that say which documents are relevant to which query. After training, compare against a held-out set before you switch traffic.

Reach for it when out-of-the-box relevance misses jargon or product codes and simpler fixes, such as better parsing, boosts or synonyms, have not helped.

Keep the evaluation honest by splitting your labeled queries into training and test sets. If the tuned model beats the baseline only on the training queries, it has memorized them and will not help real users.

User events record what people do: searches, views, clicks and purchases. You send them with a stable userPseudoId so one visitor's actions can be linked.

They feed personalization and are mandatory for recommendation models, which learn which items go together from behavior. For search they also give you data for tuning and for measuring click-through.

Send events from the first day. Models can only learn from history you recorded.

Event quality matters more than volume. Duplicate events, missing user IDs or events sent from only one channel create a biased picture, so validate the event stream against your own analytics before relying on it for personalization.

Advanced indexing lets you pick a location when you create the data store, which removes the limits of regional stores and keeps search and answering services broadly available.

For ownership-sensitive sites, expect to prove you control the domain before it can be indexed in the advanced mode.

Choose based on the experience you need. If a plain result list is enough, basic is simpler. If you want a chat-style summary over your website with follow-up questions, use advanced indexing and plan for domain verification.

A connector syncs from the source app on a schedule, picking up new and changed items so the index tracks the original. You can see sync state and errors per connector.

It also carries over each item's access control list. At query time results are trimmed to what the signed-in user may open, so an HR page in SharePoint never appears for someone who lacks access in SharePoint.

That makes the identity setup central. If users are not mapped to the source system's identities, you may see empty results or, worse, over-broad access.

To debug, search for a document you know a test user cannot open and confirm it never appears for that user. Then run the same query as a user with access and confirm it does appear, which proves both sides of the permission mapping.

Follow-ups depend on conversation context: the system rewrites a short query like "and in Europe?" into a standalone query using earlier turns, then retrieves and answers as normal.

In a plain app, multi-turn search works only with single data store apps. For several data stores you need agentic retrieval, and to persist context across turns you back the session with an Agent Runtime instance.

In the API you tie turns together with a session, so each request carries a reference to the prior exchange.

On the client, keep the session ID from the first response and send it with every follow-up. Starting a fresh session on each message is the most common reason a chat UI seems to forget what the user just asked.

Build a golden set: 50 to a few hundred real queries, each with the documents that should come back. Run it before and after each change and record the metric.

• Recall@k: did a correct document appear in the top k?
• MRR: how high was the first correct one?
• Answer faithfulness: did Check Grounding support the claims?

Change one thing at a time, such as parser, chunk size, boost or tuning, so you know which change moved the number. Pair offline scores with live click data from user events.

Also sample real traffic: each week, read the queries that returned zero results or no summary and add them to the golden set. That keeps the test set aligned with what people actually ask instead of what the team imagined.

Conceptually, a generative query passes through understanding, retrieval, ranking and generation, and each stage has settings you can control.

flowchart LR
  A["User query"] --> B["Query understanding: rephrase and classify"]
  B --> C{Answerable?}
  C -- No --> S["Skip answer, return results or message"]
  C -- Yes --> D["Retrieve from data store index"]
  D --> E["Rank and select top passages"]
  E --> F["Generate answer from passages"]
  F --> G["Answer with citations"]

1. Understanding: the query can be rephrased and classified, so adversarial or non-answer-seeking queries are ignored.
2. Retrieval and ranking: relevant chunks or documents are pulled from the index and ordered.
3. Generation: the model writes only from the selected passages.
4. Output: the answer carries citations and references, and may include related questions.

If the answer is skipped, the response states a reason, which is the first place to look when debugging.

Agentic retrieval lets an agent plan and run several searches, even across data stores, rather than doing a single retrieval for each query.

With a search app already built, you turn it on by setting enable_agent_invocation=true in the API request. That uses the predefined Google answer agent included with Agent Search.

Without it, multi-turn search works only with single data store apps, so agentic retrieval is how you get follow-ups over several stores. Answers can be streamed back as they are generated.

For example, a question like "compare our 2024 and 2025 travel policies" needs two lookups, one per policy, and an answer that merges them. A single-shot retrieval often returns only one of the two documents, which is exactly the gap agentic retrieval closes.

A custom AI-mode app is an engine configured with its own answer agent.

1. Create the engine with the engines.create REST method and include an engine_config.answer_agent block.
2. Attach the data stores you want the agent to search.
3. Send requests to the engine's default_agent_answer serving config instead of default_config.
4. Use the app ID in the request path, for example APP_ID.

The docs call this the custom AI-mode engine, because "app" and "engine" are interchangeable. Choose this over the predefined agent when you need to shape the agent's behavior yourself.

Because this creates a new engine, plan IAM and quotas for it as well. Test the serving config with a few multi-turn conversations before replacing the endpoint your application uses, and keep the old serving config available as a rollback path.

Persisting context needs an Agent Runtime instance, also called a reasoning engine, to back the sessions.

1. Enable Gemini Enterprise Agent Platform on your Google Cloud project.
2. Create the Agent Runtime instance with the Agent Engine REST API or the Agent Development Kit.
3. Point your Agent Search sessions at it.
4. Plan for quotas: sessions backed by Agent Runtime use the Agent Platform API quotas.

Missing this step is the usual reason a follow-up forgets the previous question. Check quotas as well when you scale a chat UI.

A quick test is to ask a question, then a pronoun-based follow-up such as "what about its pricing?". If the second answer ignores the first topic, the session is not bound to the Agent Runtime instance or the session ID is not being passed. For heavy chat traffic, request higher Agent Platform quotas before launch.

Fix ingestion before you touch ranking, because bad parsing cannot be repaired at query time.

1. Match the parser to the file: OCR for scans, layout parser for documents with tables and headings.
2. Turn on layout-based chunking and keep ancestor headings so passages keep their section context.
3. Return chunks, not whole documents, when the consumer is an LLM.
4. Attach metadata such as product, version and date so filters and boosts can narrow the pool.
5. Rerank the top candidates, and use search tuning if domain terms still miss.

Measure each step on a golden query set. Chunk size in particular is a trade-off and the best value depends on your documents.

Finally, close the loop with user feedback. Track which answers users reject and trace each one back to its chunk. Fixing a handful of bad chunks, a missing heading or a mis-parsed table is often worth more than another round of model-level tuning.

Work from the data inward to the query.

1. Check the import: look at the operation result for errors and confirm the document count in the data store.
2. Check attachment: the data store must be attached to the app you are querying, and website stores need Enterprise features on.
3. Check the schema: for structured data, the field must be searchable or indexable for the query or filter you use.
4. Check the filter: a wrong expression silently returns nothing, so retry without it.
5. Check indexing delay: freshly imported content can take time to become searchable.

If everything is present but ranking is poor, move to parsing, chunking, boosts and tuning.

Keep a short list of the last three changes made to the system. Most "it stopped working" reports trace back to a recent re-import, a schema edit or a filter change, so rolling that back is often the fastest diagnostic.

A missing summary is usually a deliberate skip, and the response tells you why. Common skip reasons include:

• the query was judged adversarial and ignored
• the query was not seeking an answer, such as a bare navigational term
• no relevant content was found, so there was nothing to ground on
• a policy violation was detected

Then check configuration. Summaries need Enterprise edition, advanced features need the Advanced LLM add-on, and your summary spec must actually be set on the request.

Last, look at retrieval itself. If the top results are weak, the summary has no solid evidence and will be skipped.

A good habit is to log the skipped reason with every query. A rising share of no-relevant-content skips points to a content gap, while a rise in classification skips points to unusual query traffic worth reviewing.

Combine identity, data protection and network controls.

Also watch the query path. Pass the end user's identity when results must be per-user, and do not share one broad service identity that sees everything.

Review the audit logs too. Admin activity and data access logs show who changed data stores or queried them, which matters for compliance reviews. Finally, treat every connector credential as a secret and rotate it on a schedule, since a stale token with broad scope is an easy target.

Cost has three drivers: queries by edition, add-ons, and index storage.

• Edition: Standard queries cost less than Enterprise, so use Enterprise only where you need website search, extractive answers or generative answers.
• Add-ons: an advanced generative answer adds a charge on top of the base query, so reserve it for requests that need it.
• Storage: index data is billed and shared across Agent Search, so delete stale stores and avoid duplicate copies.

Cache answers for repeated questions, and watch query volume by app, because one noisy client can dominate the bill.

Set budgets and alerts on the project, and label usage by application. A single noisy test script that calls the answer method in a loop can burn through a month of expected spend in a day, so rate limit non-production clients.

Choose by how much of the pipeline you want to own.

Start with Agent Search when the goal is enterprise search or Q&A on documents and sites. Move to RAG Engine or Vector Search if you hit a need the managed engine cannot meet, such as a bespoke embedding model.

You are not locked in. RAG Engine can use Agent Search as its backend, and the Ranking API can sit in front of any retriever.

In an interview, close with a concrete rule: if the requirements say managed, fast and cited answers, say Agent Search. If they say custom embedding model or own vector store, say RAG Engine or Vector Search.