Search-Then-Get

A deliberate two-tool split for how an agent pulls memory into context: a search tool returns lean results — file path, line numbers, a relevance score, a short preview (OpenClaw caps at ~700 chars), and citation info — and a separate get tool fetches an exact line range from a chosen file. Search returns just enough to decide what's relevant; get pulls only the specific content actually needed. The point is to keep the context window lean: never load whole files when a preview plus a targeted fetch will do. The chunk-level line-range metadata (stored at index time) is what makes get precise and lets the agent cite exactly where a memory came from.

This is the attention-budget discipline expressed as a tool contract: the shape of the two tools forces progressive disclosure instead of dumping candidate documents into context. It's the same cheap-recall-then-expensive-precision staging as Reranking, but the scarce resource being protected is the context window, not compute. OpenClaw makes the first step a "mandatory recall step" — its prompt tells the agent to search memory before answering about prior work, decisions, dates, people, preferences, or to-dos — so recall happens reliably rather than being skipped. Pairs naturally with Evergreen vs Volatile Context (what's allowed in) and Context Routing (where to look): search-then-get governs how much of a found memory reaches the window.

Claims

Split retrieval into a cheap search that returns previews + citations and a targeted get that fetches exact line ranges. best practice — context: agent memory where loading whole files would blow the context window; "best" because context is spent only on confirmed-relevant content. When files are tiny or few, the split may be unnecessary overhead.
A retrieval tool should return just enough to judge relevance, not the full content. principle — durable: progressive disclosure keeps the context window lean; the window, not storage, is the bottleneck.
Store each chunk's source line range so the agent can cite and fetch exactly where a memory came from. observation — factual: line-range metadata is what makes both citation and the targeted get possible.
Make the recall step mandatory in the tool's prompt so the agent searches before answering memory-shaped questions. best practice — context: agents that otherwise answer from parametric memory; "best" when stale/ungrounded answers are the failure you're guarding against.
Progressive disclosure applies to a shipped knowledge pack, not only a memory store: ship a large "brain" but have a plan-time step select the exact slice loaded per request. best practice — context: a bundled reference library an agent draws on (vs. an indexed memory store); a second source (Buildable) classifies the prompt, emits a reference-loading contract, and loads only the selected references — its own claim is ~10% of the bundled-brain bytes per plan. Same "spend context only on confirmed-relevant content" discipline, applied at plan time over shipped files rather than at query time over an index. See Context Routing.

Reranking — same cheap-then-expensive staging; there the scarce resource is compute, here it's the context window.
Semantic Retrieval — supplies the ranked candidates search previews.
Incremental Indexing — produces the chunks (with line ranges) that get fetches.
Evergreen vs Volatile Context — governs what's allowed into memory; this governs how much of it reaches the window.
Context Routing — tells the agent where to look; search-then-get controls how much it loads.
AI Second Brain — the store these two tools read from.
Distillate: How AI Agents Search Their Memory — Hybrid Retrieval, in Practice (OpenClaw)
Distillate: Buildable — A Local, Build-Verified App-Builder Brain for Coding Agents — progressive disclosure of a shipped knowledge pack via a plan-selected reference-loading contract (~10% of the brain per prompt).

Search-Then-Get

Claims

Related

Linked from