Agent Retrieval

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.

SummaryCopy Anchor Link

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 RAGCopy Anchor Link

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 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 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.

PagesCopy Anchor Link

1. Vector Databases - Pinecone, Qdrant, Weaviate, pgvector, and when to pick each.
2. Embeddings - Model selection, Matryoshka truncation, multimodal embeddings.
3. RAG Patterns - The pipeline from chunking through reranking to agentic and graph-augmented retrieval.
4. Knowledge Graphs - When graph retrieval justifies its maintenance cost compared with vectors.
5. Retrieval Evals - Recall, ranking, and faithfulness metrics and CI gates.

FreshnessCopy Anchor Link

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.