How to use Solr (or any search engine) in your agentic workflow

Shikhar Mishra

2 min read

·

Jun 29, 2026

--

Listen

Share

So, Solr 10 has come out, and your agent’s retrieval still sucks?

You applied the classic retrieve 50 documents → rerank to 10 pipeline, but the recall has made you sit in a call with your manager?

Well, maybe just maybe the problem isn’t the embedding model or the reranker you’re using (and it’s definitely never Solr; it’s perfect ). The real issue is that your agentic workflow is heavily biased toward the generation process.

In practice, if you’re using a modern LLM with a well-defined prompt, generation is already solved 9 out of 10 times. The bigger challenge is retrieval.

To improve retrieval, give your agent tools.

But what tools should you give your agent?

Give it tools that are tailored to your document schema.

For example, if your documents are organized by page number, your agent could have access to tools like:

• get_page(page_num)
• get_neighbor_pages(page_num)
• get_page_summary(page_num)
• document_get_pages_overview(document_id)
• get_page_images(page_num)
• get_page_tables(page_num)

These won’t necessarily improve retrieval directly, but they’re incredibly useful for post-retrieval context building.

Improving retrieval

One approach that has worked really well for me is to summarize every page before indexing. Then, generate embeddings for those summaries (for example, page_summary_embedding).

At query time:

1. Perform a KNN search over the page summary embeddings.
2. Retrieve the top 10–20 candidate pages.
3. Instead of reranking immediately, use those pages as a post-filter with Solr’s fq parameter.
4. Finally, run your favorite reranker over this much smaller candidate set to produce the top k results.

This gives the reranker a much cleaner search space while maintaining good recall.

Let the agent choose the retrieval strategy

Another mistake I see is forcing every query through dense vector search.

Instead, expose retrieval itself as a set of tools:

• lexical_query(q)
• vector_query(q)
• hybrid_query(q)

Then let the LLM decide which retrieval strategy best fits the user’s query.

A keyword-heavy query? Use lexical search.

A semantic question? Use vector search.

A mix of both? Hybrid search.

Your retrieval pipeline becomes adaptive instead of hardcoded.

TL;DR

Stop hardcoding retrieval strategies.

Trust your agent to choose the type of search it needs, and give it the tools to build the context it needs — not just generate the answer.