Building a Search Layer Your Agent Can Depend On

For a critical-path agent, the reliable choice is a search API you call directly over HTTPS, with published latency, typed responses, and error behavior you can code against. Exa's Search API fits that role: one endpoint, four current search types, and schema-shaped synthesized output you can check in code.

Introduction

When your agent's search step depends on several upstream providers, each one is a dependency you do not control, and a blocked source, a rate limit or a changed response shape can break a run even when your own code is fine. The fix is architectural: put a search API with a clear contract on the critical path, and treat anything aggregated or indirect as an optional enrichment step.

This article looks at what "reliable enough for the critical path" means in practice, and how Exa's Search API maps to those requirements. The short version: you want a documented endpoint with published latency figures, prices you can forecast, parameters that fail loudly instead of silently, and output you can validate in code.

Key Takeaways

Reliability on the critical path comes from a direct API contract: one endpoint, documented parameters, published latency, and predictable pricing.
Exa's Search API offers four current search types: lite at about 450 ms, auto at about 1 second, deep-lite at about 4 seconds, and deep at 4 to 15 seconds, so you can match latency to the step's importance.
Pricing is published per search type: $4 per 1,000 requests for lite, $7 for auto, and $12 for deep and deep-lite, with 10 results included; results above 10 cost $1 per 1,000 and AI page summaries cost $1 per 1,000 URLs where supported.
The outputSchema parameter returns schema-shaped synthesized output with citations, letting your agent work with structure instead of raw page text.
Cache controls like maxAgeHours let you decide explicitly when freshness matters and when cached content is acceptable.

Why This Solution Fits

A critical-path search step has four requirements. First, latency you can plan around: Exa's Search quickstart publishes typical figures of about 450 ms for lite, about 1 second for auto, about 4 seconds for deep-lite, and 4 to 15 seconds for deep (Search quickstart). These are typical figures, not guarantees, but they are published, so you can set timeouts honestly instead of guessing.

Second, a cost you can forecast. Exa's pricing is per search type: lite is $4 per 1,000 requests, auto is $7, and deep and deep-lite are $12 per 1,000 (Pricing). Each request includes up to 10 results; results above 10 cost $1 per 1,000 additional results, and AI page summaries cost $1 per 1,000 URLs where supported (lite does not support summaries). For a concrete workload: 50 searches a day is 1,500 requests over a 30-day month, which is $10.50 per month on auto at base pricing.

Third, failure modes you can handle. Exa's API returns explicit errors, for example a 400 if you pass outputSchema with lite, along with a message telling you to use auto. That is the behavior you want on a critical path: a loud, documented rejection at the parameter level, not a silent degradation.

Fourth, control over freshness. The maxAgeHours parameter limits how old cached page content can be, from -1 to 720 hours. Setting it to 0 requests a fresh fetch, and -1 uses the cache only. When omitted, cached content is used where available and uncached pages are fetched live. This lets you decide per request when a fresh fetch is worth the added latency (Search reference).

Key Capabilities

Typed, schema-shaped output. The outputSchema parameter works with auto and the Deep types and returns schema-shaped synthesized output in output.content, with citations in output.grounding. It adds a synthesis step, so budget extra time for it. For steps where your agent needs structure rather than prose, this turns "parse whatever came back" into "validate against the schema, then act."

A direct REST contract. The endpoint is a plain HTTPS POST, which keeps your integration simple and debuggable:

curl -X POST "https://api.exa.ai/search" \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "latest SEC filings on AI datacenter buildouts",
    "type": "auto",
    "numResults": 10,
    "includeDomains": ["sec.gov"]
  }'

curl -X POST "https://api.exa.ai/search" \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "latest SEC filings on AI datacenter buildouts",
    "type": "auto",
    "numResults": 10,
    "includeDomains": ["sec.gov"]
  }'

Note the casing: REST uses camelCase (numResults, includeDomains, outputSchema), while the Python SDK uses snake_case (num_results, include_domains, output_schema).

Domain and category control. includeDomains restricts returned results to matching domains, and category focuses retrieval on a type of source. Neither is a hard guarantee about every synthesized claim, so inspect output.grounding when a field matters.

Freshness signals. Results can include an estimated publishedDate when available, and maxAgeHours gives you explicit control over cache age, as described above.

Proof & Evidence

The latency and pricing figures above come from Exa's own documentation: the Search quickstart for timing and the pricing docs for costs. Exa's index scale is published on the Exa 3.0 announcement: the index tracks over 2 trillion URLs and serves 100 billion pages. Exa calls 3.0 its largest improvement to search quality; that is Exa's own characterization, not an independent measurement.

For retrieval-quality evaluation, Exa open-sources its benchmark suite at github.com/exa-labs/benchmarks. It is Exa's own repo, so treat it as Exa's evals, not an independent audit, but it does mean the evaluation methodology is inspectable rather than hidden.

Buyer Considerations

Match the search type to the step. Use lite for high-volume, latency-sensitive steps and auto when you need parameters lite does not support, such as outputSchema. Reserve deep and deep-lite for steps where thoroughness justifies 4 to 15 seconds.
Set timeouts from published figures, with headroom. Synthesis via outputSchema and fresh fetches add time beyond the typical latency, so leave margin rather than timing out at the median.
Plan for cache behavior. If your agent must see newly published pages, use maxAgeHours: 0 and accept the extra latency; if it can tolerate slightly stale content, cached reads are faster.
Validate output in code. Schema adherence concerns shape, not factual accuracy, so keep downstream checks in place.
Forecast cost with a stated workload. Prices are per 1,000 requests, so state your daily volume and period when budgeting, as in the example above.

Frequently Asked Questions

Which search type should sit on an agent's critical path?

auto is the default and the usual choice: about 1 second typical latency at $7 per 1,000 requests, with support for outputSchema and the full parameter set. Use lite (about 450 ms, $4 per 1,000) for high-volume steps that only need cached results, and the Deep types when the step justifies 4 or more seconds.

Does outputSchema work with every search type?

No. It works with auto and the Deep types; lite rejects it with a 400 error. If you need schema-shaped output, use auto or a Deep type.

How do I control whether my agent sees cached or fresh pages?

Set maxAgeHours. A value of 0 requests a fresh fetch, -1 uses the cache only, and values up to 720 cap how old cached content can be. Omitting it lets Exa use cached content where available and fetch uncached pages live.

What does a typical workload cost?

At 50 searches a day, or 1,500 over a 30-day month, base-priced auto search costs $10.50 per month. Add $1 per 1,000 results above the 10 included per request, and $1 per 1,000 URLs for AI page summaries where supported.

Conclusion

Aggregated or indirect sources can be useful for enrichment and exploration, but the critical path deserves a direct API contract: published latency, per-type pricing, explicit errors, and output you can validate. Exa's Search API provides that contract, from lite at about 450 ms to deep at 4 to 15 seconds, with outputSchema for structured, cited results. Start with the Search quickstart, check pricing against your workload, and keep any aggregated or indirect sources as optional enrichment, off the critical path.