Deliberative Search: When the Engine Reasons Before It Retrieves

This article was revised in October 2026 to describe slorg’s actual pipeline and anouk’s actual scope, and to withdraw latency figures that had not been measured.

The Way Search Usually Works

Open any search engine. Type a query. What happens next follows a pattern that has been essentially unchanged for twenty-five years: retrieve, then rank.

The retrieval step casts a wide net. An index is consulted. Documents matching the query terms (or their embeddings, in modern systems) are pulled into a candidate set. This set is deliberately large, because the retrieval step is optimised for recall: do not miss anything potentially relevant.

The ranking step narrows this set. A scoring function evaluates each candidate and assigns a relevance score. The results are sorted by score and presented to the user, typically ten at a time. The ranking step is optimised for precision: put the best results at the top.

This retrieve-then-rank pipeline is elegant, scalable, and well-understood. It is also limited by a structural assumption: that the query, as typed, is a sufficient specification of what the user wants.

It often is not.

The Problem with Queries

Consider a user who types: “best way to handle errors in a web app.” What do they mean?

They might be a beginner looking for a general introduction to error handling patterns. They might be an experienced developer looking for a comparison of error boundary implementations in React versus Vue. They might be debugging a specific issue and hoping to find someone who has solved it. They might be an architect evaluating error monitoring services.

A traditional search engine treats all of these as the same query. It retrieves documents that contain the words “error,” “handling,” and “web app” (or their semantic neighbours), ranks them by a generic relevance model, and returns the same results to every user. The deeper problem is vocabulary. Retrieval is driven by the words the user typed, and the user who knows what they want but not what it is called will type the wrong words. The engine never gets the chance to supply the vocabulary the user lacked.

The fundamental issue is that retrieval happens before any attempt at understanding. The engine fetches candidates based on surface-level query matching and then tries to sort them into a useful order.

Deliberative Search: Plan First, Retrieve Second

Deliberative search inverts the pipeline. Instead of retrieve-then-rank, it spends its first step on a plan and lets the plan drive retrieval.

Plan. Before any retrieval happens, a language model drafts an answer from what it already knows, and the draft is turned into structure: the entities involved and how they relate. This is the step that supplies vocabulary. A user who asks why their Flask app’s memory keeps climbing may never have typed “reference cycle” or “worker recycling”, but a competent draft will mention them.

Plan-conditioned retrieval. Search keywords are derived from the plan rather than from the raw prompt. Retrieval is still a web search, but it is a search for the things the draft says matter.

Score against the question. Each retrieved result is then judged against the user’s original query — not against the draft. That distinction matters, and we return to it below.

“Deliberative” is a description of the order of operations, not a claim about machine introspection. The model is not reflecting on its own confidence or deciding how hard to think. It is producing a first draft, and the draft is used as a search plan.

How slorg Implements This

slorg is our implementation of this idea. It is a Node.js package, published on npm as slorg, that can be used as a CLI, as a library, or as a REST service, with a SvelteKit interface for viewing the pipeline. Every query runs the same six fixed steps, in order:

1. Draft answer. The model writes a first-pass answer from its training data alone. There is no web access in this step.
2. Knowledge graph. Entities and relationships are extracted from the draft into a structured graph. In practice this is bundled into the same model call as the draft.
3. Keyword extraction. Search terms are derived from the graph nodes, not from the user’s prompt.
4. Multi-engine search. SearxNG queries Google, Bing, Yahoo and DuckDuckGo by default with those keywords. The engine list and result limit are configurable.
5. Content fetch. Each candidate URL is fetched and its readable content extracted. Failures — timeouts, paywalls, dead pages — are tolerated; a page with no content simply scores low in the next step.
6. Relevance scoring. The model scores each result between 0 and 1 against the original query. Results are sorted by score and the top few are returned.

Three of those steps call the model. The response is a structured object that exposes every intermediate artefact: the draft answer, the knowledge graph, the keywords, the scored results with their extracted content, and token usage. The library form looks like this:

import SlorgSearch from 'slorg';

const searcher = new SlorgSearch(process.env.OPENAI_API_KEY);

const results = await searcher.search('Why does memory keep growing in my Flask app?', {
  model: 'gpt-4o-mini',
  maxResults: 5
});

console.log(results.answer);         // step 1 draft
console.log(results.knowledgeGraph); // step 2 graph
console.log(results.keywords);       // step 3 keywords
console.log(results.results);        // step 6 scored results

One practical warning: the repository’s package.json and README currently use the name lorg, but lorg on npm is an unrelated, older logging library. Install slorg.

The configuration surface is small: an OpenAI-compatible endpoint and key, a default model, the list of search engines, and a search limit. Pointing the endpoint at a local OpenAI-compatible server is supported, which matters for anyone who wants the planning steps to stay on their own hardware.

Why a Fixed Pipeline and Not an Agent

The most important architectural decision in slorg is what it does not do. It is not an agent. There is no tool-selection loop, no decision about whether to search, and no recovery loop: if step 6 scores everything low, slorg returns low-scored results rather than going back to revise its plan.

That is a deliberate trade. An agent that decides for itself how many times to search is unpredictable in latency and cost, and hard to debug, because no two runs take the same path. Six deterministic steps cost roughly the same on every query and fail in the same place when they fail. In a search product, that predictability is worth more than the flexibility an agent would add.

Why the Score Uses the Original Query

Drafting first has a specific benefit and a specific risk. The benefit is the vocabulary described above. The risk is anchoring: if the draft is confidently wrong, the knowledge graph and keywords inherit the wrong topic, and the retrieved set will be full of results that are relevant to the wrong question. Scoring each result against the user’s original query, rather than against the draft, is the partial mitigation. It is partial. Plan-conditioned search does not eliminate hallucination; what it does is make the plan visible, so a reader can see which draft produced which keywords and judge for themselves.

What It Costs

Deliberation is structurally slower than vanilla search, and we do not pretend otherwise. Each query pays for three model round-trips and a sweep of page fetches. The project’s own estimate for a typical query on the default configuration is roughly five to fifteen seconds of wall-clock time, with the content-fetch step contributing the most variance. The levers that move it are the obvious ones: fewer search results, tighter fetch timeouts, fewer engines, a faster model. Output is not streamed; the structured object arrives once step 6 completes.

That latency rules slorg out for a whole class of search. For site search, e-commerce facets, or anywhere the user types a product name and expects an instant list, a fast inverted index is the correct tool and this approach is strictly worse. slorg targets exploratory questions — the ones where the user cannot name the thing they are looking for.

Where anouk Fits

anouk is a different project with a different job, and it is worth being precise about the relationship. anouk is a lightweight framework for building AI-powered browser extensions: a CLI scaffold, a per-request response cache, a per-provider rate-limit queue and a runtime settings panel, targeting Manifest V3 extensions on Chromium-style browsers. It talks to any OpenAI-compatible provider, and the user supplies their own provider URL, key and model; the extension calls the provider directly, with no backend on the critical path.

anouk does not implement deliberative search, and it does not observe browsing. What it offers is the plumbing for anyone who wants to put a model call where the user already is. A browser extension that sends a highlighted question to a deliberative pipeline and renders the plan alongside the results is exactly the kind of thing anouk makes quicker to build — but the search logic would be the extension author’s, or slorg’s, not anouk’s.

Examples Where Deliberation Helps

Some query patterns suit a plan-first pipeline better than others.

Queries where the user lacks the vocabulary. “My laptop fan runs loud when the lid is closed” is a fine description of a symptom and a poor retrieval query. A draft that names the likely mechanisms gives the search step terms that match how the documentation describes the problem.

Research queries requiring synthesis. “Advantages and disadvantages of microservices for small teams” asks for a balanced picture assembled from several sources. A draft that lays out the axes of the trade-off produces keywords for each axis, rather than one query that returns whichever opinion ranks highest.

Queries where provenance matters. Because every intermediate artefact is returned, the output of a slorg query carries its own paper trail: which draft, which entities, which keywords, which sources, and how each source scored. For a research assistant whose answers must be auditable, that matters more than speed.

Where it does not help. Navigational queries (“gmail login”) and known-item lookups gain nothing from a draft. slorg does not detect these and route around the pipeline; it runs the same six steps on every query. If most of your traffic looks like that, slorg is the wrong tool.

Limitations and Honest Assessment

Deliberative search is not universally better than traditional search.

The draft can be wrong, and a wrong draft steers retrieval toward the wrong question. Scoring against the original query mitigates this but does not remove it.

The pipeline inherits the editorial decisions of the engines behind it. Anything Google, Bing, Yahoo and DuckDuckGo decline to surface, slorg cannot surface either. And retrieval through public search engines is not private.

The approach is more expensive than traditional search. Every query costs three model calls plus the scoring of every fetched page. Whether that is worth paying depends on the query mix; for exploratory questions it may be, for high-volume lookups it is not.

We have not published a measurement of slorg’s result quality against a retrieve-then-rank baseline. The claims in this article are about how the pipeline is built and what it exposes, not about how much better its answers are. That comparison is the experiment worth running next.

The Broader Point

Search has been dominated by the retrieve-then-rank paradigm for so long that it can feel like the only possible approach. A plan-first pipeline shows that it is not: by spending the first round-trip on the model rather than on the index, the search can be conditioned on a structured guess at what the user means rather than on the words they happened to type.

slorg is an early, deliberately narrow implementation of that idea — six fixed steps, every artefact visible, no agent loop. Whether plan-conditioned retrieval produces better answers often enough to justify its cost is an empirical question, and the transparency of the pipeline is what makes it answerable.