Run: 020 (exa-consolidation) · Date: 2026-05-08 18:00 PT · Phase 1 author
We use Exa at roughly 40% of its capability. The implementation calls one endpoint (/search) out of six available (/search, /contents, /findSimilar, /answer, /monitors, Websets). On the one endpoint we do use, we pass 8 of 22 available parameters — missing outputSchema (structured extraction in one call), contents.summary (LLM summaries with schema), userLocation (geographic bias), additionalQueries (diversity), systemPrompt (search planning), subpages (crawl About Us / Team pages), extras.links (outbound link discovery), and stream (SSE for real-time UI). The Websets gap is the root cause of the 2% email validation rate documented in SKILL.md — a known architecture bug since maxswarm run #002 that has not been fixed. Four separate Exa client implementations exist with no shared template registry.
I pulled the Exa API docs via web fetch but the /findSimilar reference page returned 404, so I reconstructed its parameters from our codebase and the exa-mastery skill rather than the canonical source. The Websets API documentation was assembled from multiple pages and the exa-labs/openapi-spec GitHub repo, but the full OpenAPI YAML was too large to fetch — there may be parameters or endpoint behaviors I missed. I also did not measure actual latency or cost of the newer search types (instant, deep-reasoning, deep-lite) against our templates; my recommendations to use them are based on Exa's published specs, not our own measured evidence. The outputSchema recommendation is high-confidence but unverified against our specific query patterns — query complexity may affect schema extraction quality.
This run is a direct continuation of run #002 (HR.com buyers Exa mastery), which first identified the Websets architecture bug and the 2% email rate. Run #002 documented the problem; run #020 stress-tested the entire API surface against our implementation and found the gap is wider than #002 reported — not just Websets, but five additional endpoints and fourteen unused parameters. The pattern of "known gap persists across runs" matches what swarm-upgrade Class C (persistent dissent) is designed to catch. Run #014 (enrich-to-salesfinity design) created the YAML recipe system that this run wired to the frontend — the recipes are the delivery mechanism, but the Exa API calls behind them are still operating at the same capability level as pre-#002.
Next time I build an API integration route (like the Exa run endpoint), I will pull the provider's current API docs first and design against the full surface, not mirror the existing Python client — mirroring the existing client locked in its gaps instead of fixing them.
Generated from 020__architect.md — do not edit this HTML directly.