← writing

What re:Invent 2026 says about retrieval

I had my agents read all 2,241 sessions. AWS put vector search in every database it owns, and RAG turned into agent retrieval.

Last year evals were everywhere at re:Invent. This year it’s retrieval.

The event has grown beyond being reasonable, so I had my agents read the whole catalog for me: 2,241 sessions and 448 exhibitors. The result is a route through the week for people who build search, vector retrieval and evals, and it lives at hev.dev/reinvent. Here’s what the catalog says before anyone gets on a plane.

AWS put vector search in every database it owns

S3 Vectors, DynamoDB vector indexes, OpenSearch GPU indexing with cuVS, Aurora pgvector hybrid search, semantic caching on ElastiCache, Neptune GraphRAG, and a new product called AWS Context, a governed knowledge graph for agents. Nearly every abstract makes the same pitch: you don’t need a separate vector database.

That’s a real argument now. S3 Vectors alone has six sessions, including a 400-level chalk talk on its internals, and DynamoDB is talking about trillion-scale vector search with the partition key as the tenant boundary.

The vector databases are on the floor, not in the rooms

turbopuffer and Zilliz have booths. Pinecone, Weaviate, Qdrant and LanceDB are missing from the expo this year. The retrieval companies with sponsored talks are Elastic, MongoDB, Redis, Exa, Neo4j, Glean and Braintrust.

So if you want to talk to the people building dedicated search engines, the expo and the hallway are where you’ll find them.

RAG really is dead

The industry now says “agent retrieval”. The OpenSearch team puts it directly: agents fire hundreds of sub-queries per task. That changes the latency budget, the cache and the cost model. A system tuned for one human typing one query is the wrong shape for an agent fanning out a hundred.

Multi-tenant isolation has its own sessions too. Per-tenant indexes, scoped credentials and cache namespacing come up in at least four talks. It’s become a problem people pay to solve, and AWS is answering it in public.

Almost nobody evaluates retrieval itself

On the eval side, the same loop shows up again and again: capture traces in production, turn the failures into a versioned dataset, and gate the next release on it. That’s progress from last year, when evals felt like an observability add-on.

But only two sessions measure retrieval quality directly: Braintrust’s benchmark of Bedrock Knowledge Bases, and a lab that scores RAG answers for groundedness. Relevance judgments, recall against a golden set and ranking metrics barely appear. If you build search, that’s the gap.

Where I’ll be

The track skips the keynotes in favor of small rooms where you can talk to the person at the whiteboard afterward. A few I’m most looking forward to:

  • STG419, Inside Amazon S3 Vectors: architecture and cost. Dmitri Pavlichin whiteboarding the indexing behind 2 billion vectors per index.
  • DAT441, DynamoDB: designed for trillion-scale vector search. Two principal engineers on sharding, scatter-gather and filtered recall.
  • ANT442, Make your vector search faster, more relevant, cheaper. The OpenSearch team in a bring-your-problems format.
  • SEC429, Tenant-isolated agent memory with one IAM policy. The pattern AWS will tell every multi-tenant AI company to copy.
  • INV522, The evaluator is the algorithm, on the eval track.

A warning if you’re planning your own week: reserved seating opened October 6 and nearly every chalk talk is already full. Walk-up lines still work, and reserved seats are released ten minutes before the start.

The full route, both tracks, a map of the venues and every database, observability and eval booth on the floor are at hev.dev/reinvent. I’m also running a limo to a happy hour on Wednesday evening if enough people sign up, so drop your email there if you’re in.

If you want to talk retrieval, evals or production search while we’re there, book 20 minutes. See you in Vegas.

Start typing to search.