LangChain published two pieces in the last day — *Context Engineering Starts with Retrieval* and a companion on how Deep Agents remember — that are worth reading as an architectural argument rather than a product post. The claim: agent retrieval fails in three distinct ways, and only one of them is a ranking problem.
The three failure modes they name are inefficient searching, oversized results, and irrelevant or stale context. That taxonomy matters because most teams only instrument the first. You tune chunk size, swap in a reranker, measure recall@k — and your agent still burns half its window on a 12k-token document it needed two paragraphs from, or confidently cites a runbook superseded in March.
What Deep Agents actually does differently
The harness leans on filesystem primitives — glob for path matching, grep for literal content search — alongside semantic retrieval, and treats moving context *out* of the active window as a first-class operation rather than an overflow handler. LangChain frames this as the harness's job: apply the right technique at the right moment for the task, instead of baking one retrieval strategy into the chain.
The tradeoff is real and worth stating plainly. Literal search is exact, cheap, and needs no index maintenance, but it only works when the agent can guess the right token or path. Embedding search generalizes across phrasing but hands back approximate, undated, unscoped results. A harness that can choose per-step gets both; a harness that always embeds pays the recall tax on every query, including the ones where the agent already knows the filename.
This matters most to anyone building coding agents or ops agents over a large repo or wiki — environments where the corpus has real structure (paths, directories, naming conventions) that embedding-only retrieval throws away at index time.
The index is becoming infrastructure
Two other threads from the past week support the same conclusion from different directions.
On the security side, a run of recent arXiv work is mapping out how fragile HNSW-backed retrieval is as a trust boundary. *Poisoning the Neighborhood* describes a topology-aware, topic-level attack on large-scale HNSW-RAG that exploits hub-and-satellite graph structure to improve reachability for injected content. *Ghost Vectors* shows soft-deleted embeddings remaining reconstructible by reading on-disk index files directly — never touching the query API, so query-layer defenses never see it. A separate paper on admission-time defenses puts the inline screening cost at roughly 0.29ms against a 2.97ms per-document HNSW insert, and argues coverage still doesn't equal containment.
Meanwhile, HNSW is landing in general-purpose databases: MariaDB has shipped its own index, Percona is building one, and Google engineers have weighed in on MySQL's vector index proposal with ScaNN-based work.
If ANN search is becoming a column type you get from Postgres or MySQL, the differentiator moves up the stack — to the harness deciding what to fetch, how much, and whether to trust it.