Evidence at a glance
The mechanism in one line
Compress the visual or contextual input before the main reasoning path.
Route or verify the expensive step instead of repeating the full path.
Translate the mechanism into a bounded deployment or evaluation check.
The Task Is No Longer Just Getting the Answer Right
Exa has released Agent Ultra as the highest-effort mode of its hosted Exa Agent API. It targets large-scale list building, entity enrichment, and research questions that require searching thousands of sources. It is not an open-weight model that customers can run themselves. Instead, users access it through the API by setting the effort level to “ultra.”
That positioning changes the optimization target. Conventional answer systems are usually judged by whether they produce a sufficiently correct response. List research is closer to an open-set discovery problem: the user wants as many qualifying companies, papers, or repositories as possible, with additional attributes and supporting links. In this setting, a polished answer that omits many valid entities can be less useful than a less elegant result with broader coverage.
How the Research Work Is Spread Across Agents
The underlying Exa Agent design decomposes a request into subtasks and assigns subagents to research different domains or source sets in parallel. Frontier models are routed to steps that require stronger reasoning, while faster models handle work that does not need them. Ultra keeps this architecture but allows more computation, longer execution, and deeper searching, with the aim of continuing until the task is closer to exhaustion.
“More agents” is therefore not a sufficient explanation of the system. The important engineering choices include how subtasks are divided, how duplicate searches are avoided, how conflicting evidence is reconciled, and how the system decides that coverage is adequate. The supplied material does not disclose those orchestration and stopping policies, so the swarm label alone cannot establish that recall will improve reliably on every task. What is documented is the operating envelope: complex runs typically take about 30 minutes, while very hard runs can take up to three hours.
The Numbers Show an Advantage, Not a Final Verdict
In its launch material, Exa reports that Ultra outperformed Opus 5.5, GPT-6 Astra, and Perplexity Agent at their maximum effort settings across four research benchmarks. The headline results are 81.4% soft recall on WANDR, 93.9% F1 on DeepSearchQA, 58.9% row-level F1 on WideSearch, and an average of 2,451 passing entities per task on Company Find-All. The comparison figures were 72.3%, 77.6%, 51.6%, and 146 respectively, although the competing systems varied by benchmark.
These figures support the claim that Exa is optimizing aggressively for broad coverage and entity discovery. They are not, however, a definitive cross-system verdict. Exa says its WANDR grader follows Perplexity’s open harness but replaces the contents tool and transport logic, while using gpt-6-luna as the judge. It evaluated up to 200 tasks for WANDR and DeepSearchQA and 100 each for WideSearch and Company Find-All, with different providers sometimes graded on different numbers of tasks. All results are vendor-reported and have not yet been independently reproduced.
The Real Costs Are Time, Budget, and Operations
Agent Ultra’s value is inseparable from the fact that it is not designed for instant interaction. It uses the standard Agent run endpoint, supports outputSchema, input.data, and streaming, and has a default maximum cost of $20 per run. Callers can set maxCostDollars from $1 to $100 and maxDurationSeconds from 300 to 10,800 seconds. They can also stop a run early, retain the results collected so far, and pay for usage up to the stopping point.
Those controls make Ultra look more like an orchestrated background research job than a search button inside a chat interface. The SDK’s default polling timeout is one hour even though a run may last three hours, so production systems must extend the timeout or consume streamed events. For teams building diligence maps, enriching account lists, or compiling training-data inventories, exchanging time for recall may be sensible. For applications that require second-level latency, hard per-request budgets, or frequent retries, latency and cost control become the central engineering challenge.
Where It Fits—and Where It Should Not Be Trusted Alone
Exa identifies model providers, financial-services firms, and go-to-market teams as the main user groups. Model teams can search for every paper and repository implementing a technique and verify conditions such as whether weights were released rather than merely exposed through an API. Financial firms can build diligence maps and conduct KYC research across filings and court records. Sales teams can create account lists, enrich rows with judgment fields and cited URLs, or pass in an existing list so that the system expands it without returning known entities.
Yet exhaustive discovery always depends on boundary definitions, not computation alone. What qualifies as a company, which sources prove an attribute, how duplicate entities are merged, and how conflicting or dead links are handled will determine whether the output is usable in a business process. A safer architecture is to place Ultra in the candidate-discovery and evidence-collection layer, then apply deterministic rules, human sampling, or dedicated verification to high-risk conclusions. It can reduce the chance that researchers miss relevant entities, but it cannot take responsibility for the organization’s definitions, evidentiary standards, or final decisions.