---
title: The retrieval shift
url: https://revworx.ai/architecture/6/
date: 2026-10-19T08:26:24+00:00
modified: 2026-11-08T03:06:42+00:00
lang: en_US
---

Section 6 · Part one

# The retrieval shift

Section 4 applied the design principle to tools. This section applies it to knowledge. If you invested in a retrieval system in the last three years, the change described here is significant.

Part one

[§1The architecture at a glance](/architecture/1)[§2The interface revolution](/architecture/2)[§3MCP as the integration paradigm](/architecture/3)[§4The load-bearing element](/architecture/4)[§5The adoption signal](/architecture/5)

§6The retrieval shift

[Download the PDF →](/wp-content/uploads/2026/10/composable-reference-architecture.pdf)

In brief

Section 4 applied progressive disclosure to tools; this section applies it to knowledge. An agent that fetches through tool calls reads current state by construction, so retrieval stops being a preprocessing step. Embeddings remain useful as one retrieval tool among several.

The dominant pattern was pre-inference vector retrieval: convert the whole document collection into searchable numeric fingerprints (embeddings), pull the closest matches for each question into the prompt, then reason. Retrieval happened *to* the model, before it thought. That pattern is being displaced by agent-as-retriever, in which retrieval is a behavior of the model expressed through tool calls. The agent searches files, reads records, runs structured queries and calls MCP servers, loading context just in time because it has decided it needs it. Nothing is pre-indexed on the chance it might be relevant.

The business consequence is accuracy. An embedded index must be kept fresh, and a stale one fails quietly: the agent acts confidently on last month's picture of an account. An agent that fetches on demand reads current state by construction, and spends tokens on what the task needs rather than on passages that merely scored well.

Vector search is not retired. Recalling what was said in a call last quarter, or which conversations touched a given objection, is exactly what embeddings do well, and the architecture keeps a vector store, the searchable index of those fingerprints, for that purpose. What changes is the default. Embeddings become one retrieval tool among several, rather than the only route by which context arrives.

Figure 3 on the next page sets the two patterns side by side. The difference to notice is where the decision about what to retrieve is made: in the first, by whoever built the pipeline, in advance; in the second, by the agent, at the moment it is working on your account.

![Figure 3 — Two theories of how an agent acquires context](https://revworx.ai/wp-content/uploads/cra-figure-3-retrieval-patterns.png)

*Figure 3 — Two theories of how an agent acquires context*

For technical evaluators

The tool repertoire for agent-as-retriever is the same one a capable engineer uses: pattern search, file globbing, direct reads, structural and syntax-tree queries, and MCP servers for systems of record. Tool calls cost latency, and we accept that trade deliberately. Each call returns current, scoped data, and the smaller prompt usually more than recovers the time.

Key takeaway

Stop treating retrieval as a preprocessing step. An agent that fetches through tool calls reads current state by construction, and embeddings become one retrieval tool among several.

Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §6. revworx.ai/architecture/6