Agentic Search Works Best When It Writes Queries, Not Answers

Last updated: June 7, 2026

One of the more interesting Show HN launches today was not a coding tool. It was SNEWPAPERS, a historical newspaper archive built around full-text extraction, semantic search, and an agentic search assistant.

The author says they extracted more than 600,000 newspaper pages from the Chronicling America collection, about 5TB of source material, then built a pipeline for layout segmentation, classification, OCR, semantic indexing, and query assistance.

That is a big data project. But the product lesson is more specific:

Agentic search works best when the agent writes queries, not when it replaces the search system with a paragraph.

That sounds small. It is not.

Most "AI search" products collapse three jobs into one chat box:

1. Understand what the user wants.
2. Retrieve the right evidence.
3. Write the final answer.

That is fine for simple lookups. It gets shaky when the corpus is messy, historical, huge, domain-specific, or full of source ambiguity.

SNEWPAPERS points at a better pattern: let the agent help the user operate the search system, then keep the actual search interface and source documents visible.

The hard part is not the chat#

Historical newspapers are a brutal corpus.

The source pages have columns, broken scans, advertisements, small headlines, multiple article fragments, OCR errors, page furniture, different eras of typography, and weird layout conventions. A keyword search over raw scans produces noise. A pure semantic search can miss exact names, dates, places, or spellings. A chat-only abstraction can hide too much evidence.

The SNEWPAPERS Show HN post describes a multi-model pipeline:

• layout processing
• OCR
• LLM-based classification
• heuristics for segmentation
• OpenSearch
• Postgres
• semantic search
• an agentic search tool that writes useful queries

That last part is the product move.

The assistant is not just answering from a black box. It helps users formulate searches, then the user can inspect the saved queries and continue exploring the results.

That keeps the archive in the loop.

HN pushed on the right UX problem#

The Hacker News comments were positive but practical. One commenter who works with complicated datasets said the hard part is often UI: even experienced search people struggle to see how they would use a large corpus until they can try a focused slice. They suggested making a small public segment immediately searchable without registration, such as one year of Olympic coverage.

That is the right critique.

When the dataset is this large, "we have the archive" is not enough. The product has to give users a starting wedge.

For agentic search, the first interaction matters more than the model quality. A user needs to see:

• what the agent searched for
• why that query was generated
• what filters were applied
• which results came back
• where the source evidence lives
• how to refine the next query

If the agent hides that trail, the user gets a confident answer and no search skill. If the agent exposes the trail, the user gets leverage.

Query-writing agents are underrated#

There is a pattern here that applies beyond newspapers.

For domain search, the best agent is often a query planner:

User intent:
Find early newspaper coverage of bank runs in rural towns.

Agent output:
Search query:
  ("bank run" OR "run on the bank" OR "depositors rushed")
Filters:
  year: 1890-1935
  publication type: local newspaper
  section: news
Follow-up:
  Search by bank name once candidate towns appear.

That is more useful than a prose answer if the user is doing real research.

The agent turns vague intent into a search strategy. The search engine does retrieval. The UI shows sources. The user keeps judgment.

This division of labor is cleaner than "chat with all documents." It also scales better across messy corpora because each layer can be improved independently.

OCR can get better. Layout extraction can get better. The search index can get better. The query planner can get better. The result UI can get better. None of those improvements require pretending the model is the archive.

The RAG lesson#

RAG builders should pay attention.

A lot of RAG apps are designed as answer machines. The user asks a question. The system retrieves chunks. The model writes an answer. Maybe citations appear at the bottom.

That is useful for support docs and narrow knowledge bases.

For exploratory research, it is often the wrong primitive.

Exploratory search needs:

• saved queries
• facets
• date ranges
• entity filters
• source previews
• side-by-side comparison
• result clustering
• provenance
• follow-up search paths

An agent can help drive those controls. It should not erase them.

SNEWPAPERS is interesting because the assistant sits on top of an actual search product. It can help you ask better questions without making the result page irrelevant.

That is the architecture I would copy.

The product risk#

The risk is onboarding.

Large archives need a fast proof moment. If users have to register, invent a query, understand the corpus, and interpret a result set before they feel the product, many will leave before the agent can help.

The HN suggestion of public slices is strong because it narrows the first run:

• one theme
• one date range
• one preloaded query
• one visible search trail
• one obvious refinement

For an archive product, that is not marketing fluff. It is core UX. The product has to teach users what kind of questions the corpus can answer.

Agentic search can help, but only if it starts from concrete examples.

My take#

The durable idea in SNEWPAPERS is not "AI reads old newspapers."

It is that agentic search should make the underlying search system more usable.

The agent should translate intent into queries, propose filters, preserve search history, surface source evidence, and help users iterate. The answer can come later. In serious research products, the trail is often more valuable than the summary.

This is the same pattern developers should use in internal tools, legal search, enterprise knowledge bases, observability, security investigations, and research assistants.

Do not make the model pretend to be the database.

Teach it to operate the database well.

Frequently Asked Questions#

What is agentic search?#

Agentic search uses an AI agent to help users formulate queries, apply filters, and navigate search results instead of replacing the search system with a chat interface. The agent translates intent into search operations while keeping the underlying search engine and source documents visible.

Why should agents write queries instead of answers?#

When the corpus is messy, large, or domain-specific, a prose answer hides too much evidence. A query-writing agent helps users build better searches, inspect results, and refine their approach. The user keeps judgment and the search trail stays visible for verification and follow-up.

What makes historical newspaper search hard?#

Historical newspapers have columns, broken scans, OCR errors, multiple article fragments, different typography conventions, and layout noise. Pure keyword search produces irrelevant matches. Pure semantic search misses exact names and dates. The pipeline needs layout processing, OCR, classification, and structured indexing before search becomes useful.

How does SNEWPAPERS handle this complexity?#

SNEWPAPERS runs a multi-model pipeline: layout processing, OCR, LLM-based classification, heuristics for segmentation, OpenSearch for full-text, Postgres for metadata, and semantic search for intent matching. The agentic assistant sits on top and helps users write better queries against this indexed corpus.

When should RAG apps expose search controls instead of just answering?#

Exploratory research needs saved queries, facets, date ranges, source previews, result clustering, and follow-up paths. Support docs and narrow knowledge bases can use answer-first RAG. Research products, legal search, enterprise knowledge bases, and investigation tools should expose the search trail because the evidence path is often more valuable than the summary.

What is the onboarding risk for large archive products?#

Users need a fast proof moment. If registration, query formulation, and result interpretation all happen before the user feels the value, many will leave. Public slices with preloaded queries, narrow date ranges, and visible search trails lower the barrier and teach users what questions the corpus can answer.

How does this pattern apply to internal tools?#

Internal tools for observability, security investigation, legal discovery, and enterprise knowledge management benefit from the same split. The agent should translate intent into queries and propose filters. The search system should do retrieval. The UI should show sources. The user should keep judgment and be able to iterate.

What is the difference between query-writing agents and chat-with-docs?#

Chat-with-docs collapses query formulation, retrieval, and answer generation into one black box. Query-writing agents separate those jobs: the agent helps ask better questions, the search engine retrieves, and the UI shows evidence. Each layer can improve independently without pretending the model is the archive.

Continue Reading#

• Build Log: How I Shipped a Tool Directory That Feeds Search, Compare, and RSS
• Buzz: Block's Agent-Native Messaging Layer on Nostr
• Unstract: Open-Source AI Document Parsing at Scale