Snilld

AutoAgent vil gøre agentarbejdet selv

Et nyt open source-bibliotek fra Kevin Gu hos thirdlayer.inc får opmærksomhed, fordi det ifølge kildematerialet kan lade en AI omskrive og forbedre sit eget agent-harness hen over natten. Det lyder smart. Det interessante er noget andet: om det kedelige håndarbejde i agentudvikling er ved at flytte fra mennesket til en meta-agent.

5. april 2026 Peter Munkholm

Et nyt open source-projekt ved navn AutoAgent får lige nu en del opmærksomhed i AI-miljøet. Ifølge den primære kilde er biblioteket bygget af Kevin Gu hos thirdlayer.inc, og pointen er ret skarp: I stedet for at en ingeniør manuelt justerer prompt, værktøjer og agentopsætning igen og igen, lader man en AI gøre det arbejde selv. Kildematerialet hævder også, at AutoAgent i et 24 timers run nåede 96,5 procent på SpreadsheetBench og 55,1 procent som bedste GPT-5-score på TerminalBench. Det er stærke tal, men de kommer fra den primære omtale af værktøjet og bør derfor læses som veldokumenterede, men stadig leverandørnære påstande.

Det er derfor, historien er værd at bruge tid på. Ikke fordi endnu et repo er landet på GitHub. Den slags sker nærmest dagligt. Men fordi AutoAgent peger på et skift i selve arbejdet med agenter: fra håndholdt prompt-tuning og små manuelle forsøg til en sløjfe, hvor systemet foreslår ændringer, tester dem, måler resultatet og kun beholder det, der virker.

Det er harnesset, der bliver optimeret

AutoAgent prøver ikke at forbedre selve grundmodellen. Det er vigtigt. Ifølge kilden arbejder værktøjet i stedet på det, der kaldes et agent harness, altså stilladset omkring en sprogmodel: systemprompten, værktøjerne modellen kan bruge, måden den sendes videre mellem del-agenter på, og hvordan opgaver formes som input. Kort sagt alt det rundt om modellen, som i praksis ofte afgør, om en agent føles skarp eller bare lidt forvirret.

Det er også her mange teams bruger urimeligt mange timer. Vi genkender det ret tydeligt fra virkeligheden. Man ændrer lidt i prompten, tester, læser fejlspor, skifter et værktøj ud, justerer routing, prøver igen. Så igen. Og igen. Den manuelle prompt-tuning-karussel er dyr, ikke bare i penge men i opmærksomhed, og man kan sagtens bruge en hel dag uden at vide, om man reelt er blevet klogere.

Udvikler arbejder med kode og benchmark-kørsler på en bærbar computer.

Sløjfen er simpel, og det er nok meningen

Mekanikken bag AutoAgent er beskrevet ret ligefrem i kildematerialet. En meta-agent får lov til at ændre i harnesset, køre benchmarken, se på scoren, kassere dårlige ændringer og beholde forbedringer. Så starter den forfra. Den slags propose-evaluate-retain-sløjfe er ikke en helt ny tanke i AI, og kilden sammenligner den direkte med Andrej Karpathys idé om autoresearch i modeltræning. Her er forskellen bare, at man ikke tuner vægte og hyperparametre, men agentens arbejdsmåde.

Banner

Det lyder næsten banalt. Og det er tit et godt tegn. For meget af agent engineering er i forvejen en hill-climbing-øvelse forklædt som softwareudvikling. Man leder efter små forbedringer, måler på dem og håber, at summen af de små skridt gør systemet mærkbart bedre. AutoAgent forsøger bare at automatisere netop det stykke arbejde, som mange teams ellers sidder med sent om aftenen.

Hvorfor det her betyder noget mandag morgen

Hvis man bygger interne assistenter, support-agenter, copilots eller workflow-agenter, så er det ikke svært at se appellen. Den dyre del er sjældent at få en model til at svare overhovedet. Den dyre del er at få den til at svare stabilt, bruge de rigtige værktøjer, undgå dumme omveje og holde sig inden for opgaven. Det er dér timerne ryger.

Det interessante er derfor ikke bare automatisering for automatiseringens skyld. Det interessante er, om noget af agentarbejdet kan flyttes op et niveau: væk fra manuel mikrotuning og hen mod design af mål, evals og grænser. Vi har set projekter, hvor en stor del af budgettet forsvandt i præcis de små justeringer, som ingen bagefter kunne forklare særlig rent. Hvorfor virker version B bedre end A? Måske fordi man ændrede tre ting og glemte at måle dem ordentligt. Det er ikke en sjælden historie.

Arkitekturen gør idéen mere konkret

En detalje i kildematerialet er faktisk vigtigere, end den ser ud til. Repoet beskrives som bevidst simpelt. Filen agent.py rummer hele harnesset under test i én fil, inklusive konfiguration, værktøjsdefinitioner, agentregister og routing eller orkestrering. Mennesket sætter primært retning i en anden fil, program.md, mens meta-agenten læser instruktionen, inspicerer agent.py, kører benchmark, finder fejl og skriver relevante dele om.

Det gør ansvarsdelingen tydelig. Mennesket siger, hvad slags agent der skal bygges. Maskinen roder med hvordan. Der er også ifølge kilden en logfil, results.tsv, som holder styr på eksperimenterne på tværs af iterationer. Det lyder næsten gammeldags på den gode måde: ikke noget magisk lag med ti dashboards og lilla knapper, bare en systematisk log over, hvad der blev prøvet, og hvad der faktisk gav en bedre score.

To udviklere gennemgår målinger og arkitektur for et agent-harness.

Benchmarktal er interessante, men de er ikke drift

Så til den nødvendige skepsis. Ja, 96,5 procent på SpreadsheetBench og 55,1 procent som bedste GPT-5-score på TerminalBench lyder imponerende. Og vi har kildegrundlag for at gengive dem. Men benchmarksejre er ikke det samme som robust drift i en virksomhed med rodede data, skæve processer, compliance-krav og medarbejdere, der bruger systemet på helt andre måder end benchmarkforfatteren havde tænkt.

Banner

Derfor er det vigtigt at skille to ting ad. For det første: Kildematerialet dokumenterer, at AutoAgent påstår de resultater i et 24 timers run. For det andet: Det er endnu ikke det samme som bred, uafhængig validering af generel overlegenhed. Hvis man vil bruge tallene som bevis for, at AutoAgent slår andre tilgange i almindelig praksis, så mangler der stadig noget: mere direkte benchmark-kontrol, reproduktion uden for den oprindelige omtale og helst test i andre miljøer.

Det løser ikke dårlige mål

Der er også en mere jordnær begrænsning, som let drukner i benchmarkglans. AutoAgent kan optimere mod den måling, det får. Hvis målet er skævt, bliver optimeringen også skæv. Hvis benchmarken belønner mærkelige genveje, eller hvis evals ikke ligner virkeligheden, så får man et system, der bliver bedre til det forkerte. Skrald ind, pænere skrald ud.

Og nej, det løser heller ikke uklare sikkerhedsgrænser, svage værktøjer eller manglende domænedata. Hvis agenten ikke har adgang til de rigtige handlinger, hjælper det kun så og så meget at optimere prompt og routing. Hvis organisationen ikke ved, hvad succes betyder, så kan meta-agenten heller ikke vide det. Det er stadig her mange AI-projekter vælter: ikke fordi modellen kan for lidt, men fordi målet er tåget.

Arbejdet flytter sig, det forsvinder ikke

Hvis ideen holder, peger den mod en ændring i AI-rollerne. Ikke at AI-ingeniøren forsvinder, men arbejdet kan godt forskyde sig. Mindre tid på manuel tuning af prompts og agentflow. Mere tid på at definere gode evals, vælge rigtige værktøjer, sætte grænser for adfærd og beslutte, hvad systemet overhovedet skal være godt til.

Det er i virkeligheden en ret moden udvikling. Agentarbejde har længe haft et håndværkspræg, nogle gange næsten lidt alkymistisk. En dygtig person kunne få meget ud af små ændringer, men processen var svær at skalere og endnu sværere at forklare. Hvis AutoAgent-lignende sløjfer vinder frem, bliver agentudvikling mindre afhængig af personlig fingerspidsfornemmelse og mere afhængig af, om man kan opstille ordentlige eksperimenter.

Nærbillede af skærm med kode, versionsændringer og resultater fra automatiske tests.

Det vi ville holde øje med nu

Det næste spørgsmål er ikke, om AutoAgent ser smart ud i en artikel. Det gør mange ting. Spørgsmålet er, om mønstret spreder sig. Dukker samme type bygge-test-behold-sløjfer op i andre open source-projekter, er det et tegn på, at vi ikke bare ser en enkelt kreativ implementation, men en reel retning i feltet.

Vi ville også holde øje med reproducerbarheden. Kan andre få lignende resultater uden for det miljø, hvor værktøjet blev præsenteret? Kan det virke på opgaver, der minder om rigtige virksomheders hverdag, ikke kun på benchmarkdesignede scenarier? Og begynder agentteams at måle deres arbejde mere som ML-træning, med tydelige evals og ratchet-loops, i stedet for som lange serier af håndskrevne promptændringer? Det er dér forskellen viser sig. Ikke i overskriften.

Kilder

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?