Hurtigt: hvad skete der
Exa har frigivet Agent Ultra, det højeste effort‑niveau i Exa Agent API. Den er bygget til research, der skal køres til udmattelse: store lister, entitetsberigelse og spørgsmål, der kræver tusindvis af kilder. Løsningen er kun tilgængelig som hosted API og kan kaldes ved at sætte effort til “ultra”. Ifølge den primære dækning slår Ultra Opus 5.5, GPT‑6 Astra og Perplexity Agent på fire research‑benchmarks ved deres maksimale effort‑indstillinger. Det er leverandør‑rapporterede tal og bør læses som sådan.
Det praktiske skifte handler ikke kun om performance. Ultra ændrer også runtime‑profilen: komplekse opgaver ligger typisk omkring 30 minutter, svære helt op mod tre timer. Det skubber produktoplevelsen fra øjeblikkelige svar til asynkrone forløb, hvor køer, budgetter og timeouts er hverdag.
Hvad er Agent Ultra teknisk
Agent‑arkitekturen splitter en opgave i delopgaver. Subagenter arbejder parallelt på flere domæner og ruter mellem hurtige modeller og frontier‑modeller, når et deltrin kræver det. Lette modeller tager det trivielle; de tunge gemmes til de krævende trin. Det minder om de multi‑agent research‑pipelines, der har slået igennem de seneste to år, hvor orkestrering og værktøjsvalg er lige så afgørende som selve sprogmodellen.
Forestil dig et list‑build af “alle amerikanske værktøjer til browser‑automatisering med åbne weights”. En koordinator deler arbejdet i søgetræk, kildekrydstjek, kriterie‑verifikation (fx om weights faktisk er frigivet), deduplikering og berigelse. Hurtige trin kører på smallere modeller, mens verifikation mod primærkilder og kantcases kalder en frontier‑model. Ultra‑tilstanden vælger at køre længere for at dække flere branches og kildebaner.
Runtime og hvad det kræver i driften
Exa angiver, at Ultra som hovedregel afslutter komplekse opgaver på cirka 30 minutter og kan bruge op til tre timer på meget svære opgaver. “Runs longer” lyder uskyldigt, men i praksis betyder det: længere livede forbindelser eller baggrundsjob, eksplicit budgettering pr. run, persistente job‑IDer, og at klienter må polle eller abonnere på events i længere tid. Standard SDK‑polling har typisk en times timeout, så implementeringer skal hæve grænsen eller skifte til streaming for at undgå falske timeouts.
Ved lange forløb bliver checkpointing og genoptagelse centrale. Hvis et run afbrydes i minut 92, gør det en forskel, om man kan fortsætte fra sidste stabile delresultat eller må starte forfra. Kilderne beskriver stop‑kald med beholdte resultater og budgetgrænser, men ikke dyb detalje om interne checkpoints og automatisk genoptagelse. Det bør testes.
Benchmarkene sort på hvidt
På fire research‑harnesses rapporterer Exa, at Ultra rammer følgende mod konkurrenter ved deres maksimale effort: WANDR (soft recall) 81,4 procent mod Opus 5.5 på 72,3, GPT‑6 Astra 26,0 og Perplexity Agent 40,1. DeepSearchQA (F1) 93,9 mod Opus 77,6, GPT‑6 Astra 85,3 og Perplexity 89,7. WideSearch (row‑level F1) 58,9 mod Opus 51,6, GPT‑6 Astra 54,7 og Perplexity 56,0. Company Find‑All (gennemsnitlige beståede entiteter pr. opgave) 2.451 mod Opus 146, GPT‑6 Astra 113 og Perplexity 98.
Exa parrer desuden hver score med en omkostningspåstand: eksempelvis WANDR +12,6 procent over Opus 5.5 ved cirka halv pris pr. opgave, DeepSearchQA +4,7 over Perplexity ved 46 procent lavere pris pr. opgave end GPT‑6 Astra, WideSearch med laveste pris pr. opgave blandt de fire, og Company Find‑All +1.579 procent over Opus 5.5 med laveste pris pr. fundet entitet. Exa præciserer, at disse gevinster er relative, ikke procentpoint.
Hvordan er tallene lavet og hvor er faldgruberne
WANDR er Perplexitys åbne benchmark af 500 brede og dybe dataindsamlingsopgaver; Exa skriver, at deres grader deler evalueringslogik med upstream‑harnesset, men bytter indholdsværktøj, transportlogik og bruger gpt‑6‑luna som dommer. Hvor en leverandør allerede har offentliggjort et tal, gengiver Exa det; ellers kører de selv. DeepSearchQA stammer fra Google DeepMind og består af 900 prompts til flertrins‑søgning. Exa vurderede op til 200 opgaver for WANDR og DeepSearchQA og 100 for WideSearch og Company Find‑All, men der er variation i hvor mange opgaver per udbyder, der faktisk blev gradet.
Pris og budget: stadig lidt tåget, men med brugbare håndtag
Det oplyses, at Ultra køres som metered forbrug under Agent‑standardrater med et default loft på 20 dollar pr. run, og at kunder kan sætte budgettet fra 1 til 100 dollar samt max varighed fra 5 til 10.800 sekunder. Det er nyttige styregreb. Men den præcise afregning pr. compute‑enhed eller pr. kald er ikke beskrevet offentligt i detaljer, så cost‑per‑task må i praksis måles i eget miljø. Det er i øvrigt sådan, de fleste teams alligevel bør gøre.
Vil man hurtigt estimere totalomkostning, så tag en stikprøve på 20–30 opgaver fra jeres faktiske pipeline, sæt budgetloft og varighedsloft, mål udgift pr. gennemført opgave og pr. fundet entitet, og projekter op til månedligt volumen. En “early stop”‑strategi kan betale sig: afbryd runs, der ikke når en minimums‑recall inden et givent minutmærke.
Hvorfor det betyder noget i praksis
Arbejdsformen flytter sig. Opgaver, der før tog sekunder, bliver til batch‑jobs over minutter og timer. Det kalder på køstyring, SLA‑justeringer og product‑UX til asynkrone resultater: kvitteringsskærme, notifikationer, delvise resultater, retry‑knapper. Observability bliver en disciplin for sig: log hændelser per subagent, ruter, kildehits, dedupe‑udfald og dommerbeslutninger. Uden det bliver fejlrettelser dyre.
Hybride pipelines bliver også reglen: hurtige assistenter til dagligt brug og Ultra‑agtige runs til udmattende research. Det betyder to typer latency, to slags fejlhåndtering og forskellig governance i samme produkt.
Risici når man samler tusind kilder
Flere kilder er ikke automatisk mere sandt. Det øger også støj og overlap. Der skal deduplikering til, scoring af kildekvalitet og tydelig provenance på hvert datapunkt. Ellers smelter kilden sammen med påstanden, og man kan ikke revidere noget som helst. Et audit‑lag bør gemme: URL, hentetidspunkt, udtrukket citat, parser, og hvilken agent der traf hvilken beslutning.
Bias og hallucination ændrer form i brede søgninger. Når mange kilder sampled dårligt, kan systemet blive selvsikkert på en forkert majoritet. Derfor er negative kontroller nyttige: kendte fælder, hvor det rigtige svar er “ukendt” eller “ikke fundet”. Hvis agenten ikke kan sige “ved ikke”, løber omkostningerne op uden gevinst.
Konkurrentkontekst i korte træk
Exa positionerer sig direkte mod Opus 5.5, GPT‑6 Astra og Perplexity Agent ved maksimal effort. Disse systemer udvikler sig hurtigt, og runtime‑økonomien påvirkes også af værktøjshåndtering og prompt‑cache. For eksempel gør nyere SDK‑muligheder det muligt at tilføje værktøjer midt i en session uden at invalidere cache i stort omfang, hvilket kan sænke omkostning og latency på lange forløb. Det er ikke en én‑til‑én sammenligning med Ultra, men relevant kontekst for teams, der måler pris over tid.
Pointen er mindre hvem der vinder én runde i dag, mere hvor moden driftsstakken er: kan man styre værktøjer, cache, dommere og ruter uden at sprænge budgetter, når samtalen bliver lang og kompleks.
Implementering trin for trin
Vil man prøve Ultra på seriøse opgaver, så planlæg det som et lille program, ikke et weekendhack. Start med en kontrolleret benchmark: frys 50–100 rigtige opgaver, definér succeskriterier (recall, præcision, pris pr. opgave og pr. entitet), kør A/B mod jeres nuværende tilgang. Brug samme dommer på tværs, helst en neutral LLM eller faste heuristikker.
Byg samtidig infrastrukturen: jobkø, budget‑cap per run, deadlines, stop‑knap. Læg et provenance‑lag på alle resultater og deduplikér aggressivt. Design asynkron UX: status, delresultater, notifikationer. Og lav et compliance‑tjek for datakilder, især hvis I forventer opslag i betalte eller privilegerede arkiver; hvordan håndteres autorisation, og må data gemmes i mellemlagre?
Åbne spørgsmål og hvad der bør testes
Der mangler uafhængig reproduktion af de rapporterede benchmarks. Løsning: åben benchmarkpakke med fast dommer, publicér scripts og logs. Prisdetaljer er delvist kendt via budgetlofter, men ikke pr. compute‑enhed; mål derfor cost‑per‑task i eget miljø. Håndterer Ultra adgang til betalte kilder og juridiske arkiver? Uafklaret; kræver enterprise‑integrationstests med rigtige credentials.
Fejl og timeouts i meget lange forløb er også et hul. Der nævnes stop‑kald med beholdte resultater og konfigurerbare timeoutparametre, men ikke fuld klarhed om automatisk genoptagelse, delvise checkpoints og garanteret idempotens. En stress‑test med induced network drop efter 70–90 minutter vil hurtigt afsløre robustheden.
En note om drift og observability
Langvarige agentforløb har tre nye logningskrav: rutevalg per trin (hvilken model og hvorfor), kildeproveniens per datapunkt og kost per segment. Den sidste er vigtig for produktledelse: man vil vide, om den sidste tredjedel af kørslen faktisk flytter recall med mere end et par promiller. Hvis ikke, skal budgettet skæres, eller stopkriteriet ændres.
På sikkerhedssiden er isolation mellem subagenter og værktøjer et emne, som ikke er dokumenteret i dybden offentligt. Indtil det er afklaret, bør teams køre med konservative udgående forbindelser, tydelige allow‑lister og ingen videregivelse af følsomme kundedata uden eksplicit behov.
Det korte svar
Agent Ultra peger på, at high‑effort agentarkitekturer nu kan bære tunge enterprise‑opgaver, hvor udtømmende dækning er vigtigere end hurtige svar. Tallene ser stærke ud, men de er leverandør‑rapporterede. Værdien ligger i at teste det på rigtige opgaver, måle cost‑per‑task og bygge governance før skalering. Nogle vil blive overrasket over, hvor meget de sidste 10 procent dækning koster. Andre vil sige, at netop de 10 procent er hele pointen.
Man opdager først forskellen, når man sidder med det i hænderne.
