Agents don't search like humans.
They issue hundreds of queries per session, need structured extraction over snippet relevance, and care more about p95 latency than the perfect top result.
Keenable built a search API around those constraints with a 100B+ page proprietary index, SQL-like query interface, and continuous benchmarking against agent-like workloads.
The founders (Amazon AGI web grounding, Yandex search lead) are betting that wrapping existing search APIs won't cut it when agents become the primary consumers of web data.
The architecture reveals what changes when you optimize for machine callers instead of human eyeballs.
Why Agent Search Needs Different Plumbing Human search optimizes for the first three results and tolerates 500ms variance.
Agent search runs in tight loops where every query blocks downstream tool calls.
The contract shifts: Query volume: Agents issue 10-100x more queries per task than humans per session Latency budget: p95 matters because agents serialize tool calls; tail latency compounds across multi-step workflows Result consumption: Agents parse structured data, not blue links; relevance scoring for human click-through doesn't align with extraction success Query patterns: Agents use precise filters (date ranges, domain constraints, schema hints) that humans rarely specify Traditional search APIs built for human traffic handle agent workloads poorly.
Rate limits assume sporadic queries.
Pricing tiers penalize high-volume programmatic access.
Relevance models optimize for engagement metrics that don't exist in agent contexts.
The 100B-Page Index Decision Keenable maintains its own crawl and index instead of wrapping Google, Bing, or Brave.
This is expensive but unlocks control over: Crawl strategy: Agents need fresh data on niche domains that human-centric crawlers deprioritize.
A proprietary crawl can target high-churn sources (job boards, pricing pages, event listings) and re-crawl on agent-driven schedules rather than PageRank-weighted intervals.
Index schema: Human search indexes optimize for snippet extraction and keyword matching.
Agent search needs structured fields (publish date, author, price, location) extracted at index time, not query time.
The index becomes a queryable database, not a ranked document store.
Latency control: Owning the index means co-locating query processing with storage.
Third-party API wrappers add network hops and rate-limit unpredictability.
Keenable reports <250ms p95 in US East because the entire stack runs in the same region.
Cost structure: At scale, API wrapper economics break.
If an agent workflow issues 1,000 queries per user session and you're paying $5 per 1K queries to an upstream provider, you're spending $5 per session before any other infrastructure costs.
A proprietary index shifts that to fixed crawl and serving costs that amortize across all queries.
The trade-off: you're now responsible for crawl politeness, duplicate detection, spam filtering, and index freshness.
You need petabyte-scale storage and distributed query processing.
This only makes sense if agent query volume justifies the fixed cost.
SQL-Like Query Interface Keenable exposes a SQL-like syntax for web queries.
Instead of keyword strings, agents construct queries with explicit filters and projections: This changes the orchestration contract.
Traditional search APIs return ranked lists; the agent parses snippets and hopes the LLM extracts the right fields.
SQL-like queries return structured records where the search engine handles extraction.
Orchestration impact: Agents can issue parallel queries with different filters instead of iterating through paginated results.
A pricing comparison agent might run: This parallelizes what would otherwise be sequential LLM calls to parse unstructured snippets.
Failure modes: SQL-like queries fail hard when the schema doesn't match the page structure.
If isn't extracted correctly at index time, the query returns empty results instead of degrading gr