TL;DR
- “Search API” covers four different product layers: raw retrieval, generated answers, managed research, and persistent monitoring. A single feature score hides more than it reveals.
- Exa, Parallel, and Perplexity span several of those layers. AgentCore Web Search stays focused on managed retrieval through an MCP connector.
- The live MCP surfaces include Exa’s hosted tools, Parallel’s Search and authenticated Task servers, Perplexity’s official four-tool server, and AgentCore’s Gateway tool.
- Successful transport still says little about truth. One exact-page fetch returned stale content, and several generated-answer cases added unsupported facts despite returning normally.
The useful comparison between agent-search vendors starts with the layer of the research workflow each product owns. All four products I tested can return usable web results.
Exa combines retrieval, answers, deep search, an asynchronous Agent, Websets, and Monitors. Parallel spans Search, Extract, Responses, Chat, Task, FindAll, and Monitor. Perplexity’s current platform centers on Search, Agent, Embeddings, and an official MCP server; Sonar remains a deprecated migration lane with support documented through September 27, 2026. Amazon Bedrock AgentCore Web Search has a focused boundary: managed public-web retrieval through an AgentCore Gateway.
Treating these as four versions of the same search endpoint produces the wrong architecture.
The market has four layers
| Layer | What comes back | Representative products |
|---|---|---|
| Raw retrieval | Ranked URLs, excerpts, dates, and source metadata | Exa Search and Contents, Parallel Search and Extract, Perplexity Search, AgentCore Web Search |
| Generated answers | Model-written responses grounded in retrieved sources | Exa Answer, Parallel Responses and Chat, Perplexity Agent and Sonar |
| Managed research | Multi-step work with reasoning, tools, structured output, or verified lists | Exa Deep Search, Agent, and Websets; Parallel Task and FindAll; Perplexity Agent presets |
| Monitoring and reusable state | Scheduled searches, change detection, stored runs, or persistent collections | Exa Monitors and Websets; Parallel Monitor, Task Groups, and FindAll |
These layers use different billing units, latency profiles, and quality checks. A raw result list can be graded for ranking and source coverage. A generated answer needs factual and citation review. A research run needs task-completion and lifecycle checks. A monitor needs delivery, deduplication, pause, resume, and cleanup tests.
One leaderboard cannot carry all four.
Raw retrieval is the common foundation
The retrieval layer is the cleanest comparison. The measured evidence covers a fixed 30-query suite plus filters, result counts, content limits, freshness controls, exact-page fetches, and MCP transport.
The products expose different controls:
- Exa Search offers Auto, Fast, Instant, Deep Lite, Deep, and Deep Reasoning modes. Its Search and Contents APIs expose domains, dates, location, categories, freshness, highlights, summaries, subpages, links, and structured output.
- Parallel Search offers Basic, Fast, Advanced, and Turbo modes, with source policy, excerpt budgets, location, live-fetch controls, multi-query search, sessions, and a separate Extract surface.
- Perplexity Search returns ranked structured results, supports multi-query requests, and exposes domain, date, region, language, and content-budget controls.
- AgentCore Web Search exposes query, result count, and request-level domain and publication-date filters through its managed connector. The September 2026 evaluation completed 47 of 47 retrieval cases, including exact result counts and constrained domain and date cases.
The content-budget units remain incompatible. Parallel caps excerpt characters. Exa separates highlights from capped page text. Perplexity budgets extracted page content in tokens. AgentCore returns its connector’s semantic snippet format without a caller-controlled content-size setting.
That matters because the output becomes model context. A provider can return more text while producing a worse input for the next reasoning step.
Exact-page retrieval is a separate product boundary
Parallel Extract and Exa Contents both retrieve known URLs, but they expose different freshness, content-shaping, and metadata controls. A September 2026 check returned different PostgreSQL versions for the same URL even though both calls succeeded and returned nonempty text. The full failure evidence belongs in Part 4; the product-selection point is that search-result quality and fetched-page currency require separate tests.
Generated answers require a separate evaluation
The answer products sit above retrieval and introduce a model into the result.
Exa Answer returned grounded responses across four models, including citations, source text, structured output, and streaming. Parallel Responses completed low, medium, and high reasoning modes with citations, JSON structure, streaming, and continuation. Parallel Chat completed Speed, Lite, Base, and Core. Perplexity’s Agent API completed all five presets with built-in tools. The deprecated Sonar migration lane also completed its grounded-answer and research modes. AgentCore Web Search stops at retrieval; the calling agent or model writes the answer.
Transport success did not predict factual quality in the frozen-answer review. Parallel Responses produced two complete and three partial answers on one fixed fact pattern. Parallel Chat produced two partial and three incorrect answers. Across the graded Perplexity answer configurations, eight were complete and five were incorrect. Exa passed two targeted conditional-write checks; a wider Exa answer-grade set remains open. Part 4 carries the claim-level evidence.
Those samples are too narrow for a vendor ranking. They are enough to establish the evaluation boundary: a 200 response proves that the request completed. It does not prove that the answer is supported.
Managed research extends beyond search
The broadest capability layer sits above generated answers.
Exa Agent runs asynchronous research, list-building, enrichment, and schema-constrained extraction. The live evidence covers all seven effort modes, continuation, event replay, listing, cancellation, structured grounding, and streaming. Exa’s Deep search modes also completed through the Search API. Websets adds verified collections and enrichment, while Monitors adds recurring searches and webhook delivery.
Parallel Task completed every tested standard processor, plus structured output, research-basis citations, polling, result retrieval, and event streaming. An authenticated Task MCP Pro run also completed and returned its research report. Parallel FindAll completed Preview and Base runs for entity discovery and validation. Monitor event-stream and Snapshot lifecycles completed through create, retrieve, update, and cancel.
Perplexity Agent completed Fast through XHigh presets and invoked web search, URL fetch, finance search, people search, and sandbox tools. It also supports background work, structured output, streaming, model fallback, and conversation context. Perplexity’s Embeddings API is a separate product family for semantic search and retrieval pipelines; all four standard and contextual models completed in the live evidence.
These products solve different tasks. Exa Agent, Parallel Task, and Perplexity Agent can all produce research outputs, yet their effort controls, tool models, lifecycle semantics, and billing units differ. FindAll and Websets add entity verification and enrichment. Monitor products add persistent change detection. Calling all of them “deep search” strips away the decisions a builder must make.
MCP exposes real product depth
The hosted MCP servers are live and expose more than a thin search wrapper.
- Exa MCP successfully invoked basic Search, Advanced Search, Fetch, Code Context, and authenticated Agent. One three-result advanced search returned 143,378 characters, which is a practical context-size risk for clients that do not cap tool output.
- Parallel MCP exposes anonymous Search and Fetch plus an authenticated Task server. Calls through both completed, including a Task MCP Pro research run.
- Perplexity MCP exposes four official tools—Search, Ask, Reason, and Research. All four completed in one bounded session.
- AgentCore Web Search uses the Gateway’s MCP endpoint as its native interface. Signed discovery and calls succeeded; an unsigned request returned HTTP 401.
The shared protocol improves discovery and invocation. It does not normalize output size, pricing, authentication, state, or product semantics. MCP tells an agent how to call a tool. The tool contract still determines what the call means.
Capability must be verified at three layers
AgentCore documents domain and publication-date filters. The active endpoint exposes them, and the adapter forwards the native filter object. The September 2026 evaluation returned 40 of 40 compliant constrained results: 20 domain-filtered and 20 date-filtered.
A feature matrix assembled from one client can measure the client’s schema instead of the vendor’s product. Capability claims need three checks:
- The vendor documents the feature.
- The active endpoint and account expose it.
- The adapter forwards it and preserves the response.
Skipping any one of those checks creates a false capability boundary.
The useful selection model
The product choice starts with the output the agent needs:
| Needed outcome | Product layer to evaluate |
|---|---|
| Ranked sources for another model | Raw retrieval |
| A cited answer delivered directly | Generated answers |
| Multi-step research or structured extraction | Managed research |
| Verified entity lists and enrichment | FindAll or Websets-style collection workflows |
| Recurring change detection | Monitor lifecycle |
| Search behind an AWS-managed MCP boundary | AgentCore Web Search |
| Semantic retrieval over an application corpus | Embeddings plus a vector index |
Test the failure that matters for that layer. Retrieval needs ranking, coverage, freshness, and filter checks. Answers need claim-to-source review. Research needs completion, cost, continuation, and cancellation. Monitoring needs delivery, deduplication, updates, and cleanup.
What’s missing
The current evidence is broad in capability coverage and narrow in repeated quality grading. Exa’s Monitors still need a public HTTPS webhook for a full live lifecycle. Parallel scheduled-monitor delivery and FindAll’s higher tiers remain untested. Perplexity Wide Research hit a rate limit, and broader answer grading across all three answer providers is still open. AgentCore’s run establishes focused retrieval behavior in one region, not a generated-answer or managed-research product.
The next useful benchmark will grade the same factual tasks across answer and research products while preserving citations, cost, latency, and lifecycle evidence. That test cannot reuse a raw-search ranking and call it accuracy.
So what
Search for agents is a stack. The retrieval engine, answer model, research runtime, state layer, and transport can come from one vendor or several.
The practical architecture begins by naming those layers. Once retrieval, generated answers, managed research, and monitoring are separated, the product differences become legible—and the tests become honest. The open question is when one integrated vendor stack produces a better system than a best-of-breed pipeline assembled across those layers.
Part 2 of the Search for Agents series.
← Part 1: Search for agents is becoming its own market · Part 3: Search is a pipeline, not a tool → · Part 4: A 200 response does not prove search worked →