Search Is a Pipeline, Not a Tool

TL;DR

• Search for agents has five distinct stages: discovery, extraction, verification, synthesis, and monitoring or state.
• A successful search call proves only that discovery returned candidates. It says nothing about page freshness, factual support, answer quality, or whether a monitoring loop will run again.
• The evidence set contains 153 direct cases across four provider deep dives. Each stage needs its own contract, evidence, and failure handling.
• RSS can be a cheap discovery source for recent news, but it does not replace extraction or verification.
• The unresolved problem is confidence transfer: evidence can weaken between stages even when every individual API call succeeds.

Search for agents is a pipeline, not a tool. Discovery finds candidates. Extraction turns pages into usable evidence. Verification checks whether that evidence supports the claim. Synthesis produces the answer. Monitoring and state decide whether the work can continue, repeat, or recover.

Collapsing those stages behind one web_search button makes the architecture look simple. It also makes failures harder to see. A request can return HTTP 200, five plausible links, and a polished answer while still failing the actual job.

The evidence set contains 153 direct cases across four provider deep dives: 41 Exa Search, Contents, and Answer cases; 35 Parallel search, extraction, response, chat, task, and entity cases; 30 Perplexity search, agent, Sonar, and embedding cases; and 47 AgentCore Web Search retrieval cases. Separate MCP and lifecycle checks extend the evidence for transport, continuation, cancellation, and cleanup.

The five-stage architecture

These are different jobs. They also have different economics. Discovery is often priced per query. Extraction can be priced per page. Synthesis adds model and tool costs. Monitoring introduces schedules, webhooks, retained state, and cleanup.

That distinction changes how an agent should be built and tested.

Discovery is candidate generation

Discovery answers one question: where should the agent look?

A dedicated search API is one answer. A managed connector is another. For narrow recent-news work, a structured public feed such as Google News RSS can also provide a useful candidate stream. The cheap pattern is straightforward:

RSS or search query
  -> candidate URLs
  -> relevance and recency filter
  -> extraction from the strongest sources

RSS remains one inexpensive example, not a substitute for broad web search. It is useful when the job is recent, public, and headline-oriented. It is weak for technical documentation, long-tail pages, exact site retrieval, and any task that needs dependable coverage semantics.

AgentCore Web Search returned exactly the requested 1, 5, and 25 results and honored 40 out of 40 tested domain and date constraints. That establishes a strong discovery contract for those cases. Its managed Web Search connector returns ranked snippets and source metadata, but it does not fetch arbitrary URLs. Discovery succeeded; the next stage still needed another component.

Extraction is where the page becomes evidence

A result snippet is not the page. Extraction follows a known URL, retrieves content, and shapes it for the agent’s context window.

Both Exa Contents and Parallel Extract handled HTML, longer text, and multi-page cases in the bounded tests. Exa also returned highlights, summaries, subpages, links, and image links across the bounded cases. Parallel exposed freshness policies and shared sessions.

A same-URL extraction check produced two successful, nonempty responses and one stale copy. The full result belongs in Part 4; the architectural point is that schema validation and freshness validation are different stages.

This is why extraction needs its own evidence record:

requested URL
retrieved URL
retrieval timestamp
content timestamp, when available
cache or freshness policy
content hash
extracted text

Without that record, the agent cannot explain whether a contradiction came from search ranking, cached page content, or later reasoning.

Verification is a separate computation

Verification asks whether the extracted evidence supports the answer. It does not ask whether the API returned citations or whether the prose sounds confident.

The saved-output reviews contain complete, partial, and incorrect answers even when transport and schema checks pass. Part 4 carries the provider counts and fact pattern. The pipeline contract only needs the conclusion: generated answers require a different test from search results.

A practical verification stage should preserve three sets:

1. Claims the evidence directly supports
2. Claims the evidence contradicts
3. Claims for which the evidence is incomplete

That third set matters. A search pipeline should be able to stop with “not established” instead of converting missing support into fluent prose.

Synthesis must prove that the tool ran

Synthesis is where search results become a response, report, table, or structured object. Modern agent products combine models with web search, URL fetch, finance or people search, code execution, and other tools. Perplexity’s Agent API and Exa’s Agent API are examples of that broader surface.

Tool availability is not tool use. The evidence set includes a successful agent response where an enabled specialized tool did not run. That failure mode is examined in Part 4.

That creates another contract boundary. A synthesis run should retain:

• which tools were offered;
• which tools were invoked;
• the arguments and result identifiers;
• the evidence attached to each final claim;
• token, tool, and provider-reported cost where available.

A polished answer without an invocation trace is not proof that grounding happened.

Monitoring turns search into a system

A one-time answer ends after synthesis. A research system needs continuation, schedules, change detection, cancellation, and recovery.

Parallel’s Monitor API exposes event-stream and snapshot lifecycles. Exa’s Monitor API requires a public HTTPS webhook. Those product differences determine what state, delivery, and cleanup evidence the pipeline must retain; Part 4 records the tested outcomes and remaining delivery gap.

This stage is where search acquires state. The minimum durable record is no longer a query and response. It includes a run ID, schedule, cursor or previous-run link, event history, terminal status, retry policy, and cleanup result.

A monitor that was accepted but never delivered an event is not working monitoring. A background run without a retained identifier is not recoverable state. A cancellation request without a terminal read-back is not confirmed cleanup.

The pipeline contract

The clean architecture is a chain of explicit artifacts:

Question
  -> discovery manifest
  -> extracted evidence packet
  -> verification ledger
  -> synthesized answer
  -> state and monitoring record

Each arrow is a contract. Each artifact can be inspected without rerunning the whole system. Each stage can change providers without forcing the rest of the pipeline to adopt the same vendor.

That modularity also makes cost control clearer. Cheap discovery can shortlist candidates before paid extraction. Verification can run only on claims that affect the answer. A research agent can use deeper synthesis selectively. Monitoring can schedule only the queries whose changes matter.

The point is not to assemble the largest stack. It is to know which stage owns each promise.

What’s still missing

The evidence measures contracts, bounded behavior, latency samples, saved-output quality, and lifecycle cleanup. It does not measure how confidence degrades across the entire pipeline.

A discovery stage can miss the best source. Extraction can return stale content. Verification can overlook a contradiction. Synthesis can cite the right page for the wrong sentence. Monitoring can rerun the same weak query perfectly on schedule.

The open thread is how to score that transfer of confidence from one stage to the next. What metric can distinguish discovery diversity that improves the final answer from diversity that adds latency, cost, and more evidence for the verifier to reconcile?

Part 3 of the Search for Agents series. ← Part 2: What Actually Differs Across Search APIs Built for Agents · Part 1: Search for Agents Is Becoming Its Own Market · Part 4: A 200 Response Does Not Prove Search Worked →