---
title: "Agent Retrieval"
description: "Condensed current best practice for vector databases, embeddings, RAG patterns, and knowledge graphs"
url: "https://agentsurface.dev/docs/agent-retrieval"
index: https://agentsurface.dev/llms.txt
lastVerified: 2026-10-29
lastModified: 2026-10-29T11:29:43.000Z
---

Agent Retrieval is how an agent finds and uses knowledge for its own work - vector search, embeddings, and retrieval-augmented generation. It is part of the Build agents half of the site: a condensed, current-best-practice reference for teams building an agent's retrieval stack. The product-facing side - making your own product's data retrievable by other agents - is covered in [Retrievability](https://agentsurface.dev/docs/retrievability).

## Summary [#summary]

The durable pattern is stable even as vendors and benchmarks move fast: combine sparse keyword retrieval, dense semantic retrieval, metadata filters, reranking, and evaluation. Dense-only vector search is a fine prototype baseline and rarely enough for a production agent that needs exact identifiers, permissions, and citations.

- **Hybrid beats dense-only** for mixed corpora - combine keyword and dense signals unless an eval proves one is enough.
- **Chunking is product logic** - preserve source, section, and version metadata; do not index anonymous text blobs.
- **Reranking improves precision** - retrieve broad, rerank narrow.
- **Graphs are a maintenance commitment** - add one only when relationships are explicit and queried often.
- **Evaluate retrieval, not just generation** - recall, ranking quality, faithfulness, latency, and cost all need gates.

## When Not to Build RAG [#when-not-to-build-rag]

A retrieval pipeline is a maintenance commitment - chunking, indexing, reranking, evals - and it is not always the simplest way to get an agent the knowledge it needs. Consider these before building one:

- **Agentic search tools.** Let the agent call a search tool directly against the live source rather than pre-indexing it. Simpler to build, and it can reach fresher data than a pre-built index, at the cost of per-call latency and search quality depending on the tool. Live search can still lag: the tool may sit on its own index or cache, so carry source timestamps and a freshness policy, as [Freshness and Provenance](https://agentsurface.dev/docs/retrievability/freshness-and-provenance) recommends.
- **The whole corpus in context.** If the corpus is small enough to fit, skip retrieval entirely and put it directly in context. Weigh this against the [context-rot cost](https://agentsurface.dev/docs/agents/memory#context-failure-modes) of a large, mostly-irrelevant block sitting in every call.
- **Code or filesystem search.** For structured or code-shaped content, let the agent search with grep-like tools or a filesystem interface instead of embeddings - exact-match retrieval a vector index is worse at.
- **Entity and relationship extraction.** When what the agent needs is facts about specific entities rather than passages of text, extracting structured facts up front can answer the query directly without a retrieval step at all.

Start with the simplest of these that could work, and reach for a full RAG pipeline only once it demonstrably is not enough.

## Pages [#pages]

- [Vector Databases](https://agentsurface.dev/docs/agent-retrieval/vector-databases) - Pinecone, Qdrant, Weaviate, pgvector, and when to pick each.
- [Embeddings](https://agentsurface.dev/docs/agent-retrieval/embeddings) - Model selection, Matryoshka truncation, multimodal embeddings.
- [RAG Patterns](https://agentsurface.dev/docs/agent-retrieval/rag-patterns) - The pipeline from chunking through reranking to agentic and graph-augmented retrieval.
- [Knowledge Graphs](https://agentsurface.dev/docs/agent-retrieval/knowledge-graphs) - When graph retrieval justifies its maintenance cost compared with vectors.
- [Retrieval Evals](https://agentsurface.dev/docs/agent-retrieval/retrieval-evals) - Recall, ranking, and faithfulness metrics and CI gates.

## Freshness [#freshness]

This corner of the ecosystem moves fast: embedding models, vector database pricing, and framework recommendations change over months. Treat every model name, price, and benchmark figure on these pages as a snapshot verified on the date stamped at the top of each page, and re-verify before a procurement or architecture decision.