Parallel Web Systems: Search, Extraction, and Deep Research for Agents

TL;DR Parallel Web Systems separates Search, Extract, and Task APIs into web-access layers with different latency and cost profiles, while Basis maps citations, excerpts, and confidence to output fields.

#parallel-web #web-search #ai-agent #retrieval #deep-research #web-extraction

Table of Contents

Three API layers for three kinds of questions
Minimal workflow: Search first, Extract only when needed
Basis provides traceable evidence, not guaranteed truth
Web content is untrusted input
Choosing among Parallel, Exa, and Bright Data
Fit, non-fit, and the real tradeoff
References

🌏 中文版

Parallel Web Systems is not merely a wrapper that lets an LLM “Google something.” It is a web-access layer for agents, built on its own crawler and index. The platform separates search, page extraction, multi-step research, and continuous monitoring into different APIs. That separation matters: an agent should not launch expensive deep research every time it needs an official version number.

As of publication, the formal product surface includes Search, Extract, Task, FindAll, Monitor, and Chat APIs. This article focuses on the first three, which commonly form an agent research loop.

The company announced a $100 million Series B at a $2 billion valuation, bringing total funding to $230 million.

The same company release claims more than 100,000 developers use the platform. This adoption figure comes from Parallel, not an independent audit.

Three API layers for three kinds of questions

Parallel is not one endpoint. You choose a layer according to how much you already know.

API	Input and output	Use it for
Search	A natural-language objective plus keyword queries; returns ranked URLs and LLM-ready excerpts	Current facts, candidate sources, and named entities
Extract	Known URLs; returns focused excerpts or full Markdown, including JS pages and PDFs	Reading primary pages after search or processing a user-supplied URL
Task	Open questions or structured input; asynchronously returns cited text or JSON	Multi-hop research, enrichment, and cross-source synthesis

Search is a synchronous retrieval primitive. objective describes the actual question and source preferences, while search_queries provides several short keyword entry points. Together they are more controllable than putting the user's entire request into one query. Results include substantial excerpts, letting the model judge source value before deciding whether to call Extract.

Extract does not discover URLs. It converts specified public pages into clean Markdown, returning objective-focused excerpts or complete content. This division keeps Search from fetching every result in full and wasting latency and context. The agent escalates only a few candidate pages when it needs source-level verification.

Task packages search, fetching, and synthesis into a managed research agent. Deep Research may take tens of minutes, so it belongs behind webhooks, SSE, or polling rather than blocking an interactive chat request. It can produce Markdown or populate a JSON Schema. This is where Parallel moves from a search API toward a web knowledge-work API.

Minimal workflow: Search first, Extract only when needed

The Python package is named parallel-web, while the import is parallel. This workflow finds recent official sources, then extracts the first candidate:

from parallel import Parallel

client = Parallel()  # Reads PARALLEL_API_KEY

search = client.search(
    objective="Verify the latest stable SDK version, preferring official release notes",
    search_queries=["SDK release notes", "SDK latest stable version"],
)

candidate = search.results[0]
page = client.extract(
    urls=[candidate.url],
    objective="Find the latest stable version, release date, and breaking changes",
)

print(candidate.url)
print(page.results[0].excerpts)

Production code should not blindly trust results[0]. Filter by domain, publication date, and task requirements; preserve the returned URL; then use Extract to read the original page. When freshness is mandatory, advanced settings control cache age and live fetching. Live fetch adds latency, and you must explicitly decide whether an older indexed copy is an acceptable fallback.

Basis provides traceable evidence, not guaranteed truth

The Task API's Research Basis maps output fields to citations, source excerpts, reasoning, and confidence. Structured results can therefore preserve where each value came from instead of dropping a bag of URLs at the end of a report. A beta feature can produce field-level basis entries for individual array elements.

A citation proves the system read a page. It does not make the page reliable or guarantee that the excerpt supports the rewritten claim. Treat Basis as a provenance layer. For high-risk fields, check that the source is primary, the excerpt contains the number and its comparison condition, and supposedly independent sources are actually independent. confidence: high is a processor judgment, not a probability calibrated to your business loss.

Search and Extract excerpts are also objective-driven compressions. For contract exceptions, research limitations, or pricing fine print, do not rely on excerpts alone. Request full content and retain the original URL for human review.

Web content is untrusted input

Parallel retrieves and organizes content; it does not eliminate prompt injection. An extracted page may say “ignore previous instructions,” impersonate a system message, or ask the agent to upload internal data. Clean Markdown is not safe content.

Place fetched text in an explicit untrusted_web_content field rather than concatenating it into the system prompt. Search tools should accept only objectives and queries, and page text must never redefine tool permissions. Separate research and action agents: the action side receives only required, schema-validated fields, with human approval for email, payment, or database writes.

URLs need policy too. Block localhost, private IP space, cloud metadata endpoints, and unapproved schemes so extraction cannot become an SSRF path. Keep API keys in a backend secrets manager, never browser code or model context. A domain allowlist fits compliance-bound sources; open-ended research needs a softer policy or it will exclude unknown but important sources before retrieval starts.

Choosing among Parallel, Exa, and Bright Data

The products overlap, but they begin at different layers.

Product	Strength	Consider it first when
Parallel	Search, extraction, long-running research, and field-level Basis in one surface	An agent must escalate from retrieval to cited structured research
Exa	Search and contents APIs with semantic/neural retrieval, exposed as direct retrieval building blocks	Your team owns the agent loop and mainly needs strong candidate pages and content
Bright Data	Proxies, anti-bot handling, SERP, browsers, scrapers, and datasets	Blocked sites, geo-specific access, or large-scale collection is the primary challenge

Parallel behaves like an information layer for models; Bright Data is closer to network and collection infrastructure. For heavily protected sites, Bright Data's Unlocker or Browser API may be the better primitive. If you already own the crawler and evidence pipeline, Exa or Parallel Search alone may be more transparent than Task. The shared word “web” does not make these products interchangeable.

Parallel's vendor-run July 2026 BrowseComp evaluation reports 51% accuracy and 216 ms p50 search latency for Turbo.

The same evaluation reports 33.7% and 361 ms for Exa Instant. This is a vendor benchmark: Parallel selected the best observed scores across runs, used GPT-5.4 as both agent and judge, and did not expose exactly identical tools to every engine. Treat it as a candidate signal, not a substitute for tests using your queries, model, geography, and cost profile.

Fit, non-fit, and the real tradeoff

Parallel fits agents that need current public information, traceable citations, structured enrichment, or background deep research. Its integrated surface is valuable when a team does not want to maintain a crawler, ranking, content cleanup, research orchestration, and evidence mapping at once.

It is a poor fit when private-document RAG is the main problem, when a browser agent must interact behind login, or when a search product must fully control crawl schedules and index membership. For a handful of fixed official sites, a controlled HTTP client plus parser may be cheaper and easier to audit.

Adopt it in tiers: Search by default, Extract when the source text is insufficient, and Task only for cross-source synthesis. Then evaluate 100 real questions for answer accuracy, citation support rate, p95 latency, and cost per successful answer. Parallel's value is not turning every web request into a black box. It is letting an agent spend according to question difficulty while carrying evidence back into your system.