AI-agent harness: 88 mot 68 prosent, samme modell

Nøkkelpunkter per 18. september 2026:

Samme modell, åtte harnesser: passraten varierte fra 88 til 68 prosent på de samme 25 oppgavene, med lik leverandør og like verktøy (composio.dev).
Kostnadsspennet er større enn kvalitetsspennet: billigste kjøring endte på 9,28 dollar, dyreste på 35,37 dollar for samme oppgavesett (composio.dev).
Verktøykall forutsier ikke suksess: 402 verktøykall ga ikke bedre resultat enn 223 i den kontrollerte sammenligningen (composio.dev).
Harness og vekter kan forbedres vekselvis: Co-Harness finjusterer modellen på kjøringer fra en forbedret harness, og gjentar syklusen (arXiv).
Ferdigheter kan gjøres kjørbare: HASP rapporterer 25 prosent bedre websøk med ferdighetsprogrammer alene, uten ny trening (arXiv).

Hva en AI-agent harness faktisk er

En AI-agent harness er alt som omgir språkmodellen mens den jobber: systemprompten, verktøyene den kan kalle, ferdighetene den kan aktivere, laget som griper inn underveis, og minnet den bærer med seg mellom stegene. Modellen er motoren. Harnessen er resten av bilen. I en kontrollert sammenligning kjørte åtte harnesser samme modell på de samme 25 oppgavene, og passraten varierte fra 88 prosent til 68 prosent (composio.dev). Samme modell, samme leverandør, samme resonneringsnivå, samme verktøy.

For en norsk ledergruppe betyr det at spørsmålet «hvilken modell bruker dere» er for tynt til å avgjøre noe som helst. To leverandører kan svare identisk på modellspørsmålet og likevel levere resultater som ligger langt fra hverandre på ditt eget oppgavesett. Alura mener modellvalg alene er et for tynt beslutningsgrunnlag når forskjellen mellom beste og svakeste harness på samme modell er 20 prosentpoeng. Resten av denne artikkelen handler om hvordan du skiller faktorene fra hverandre, og hvordan du setter opp en test du faktisk kan bruke i et innkjøpsmøte.

Fem-tuppelet som gjør begrepet målbart

Begrepet har vært løst brukt i to år, men forskningen har begynt å definere det presist nok til at det kan måles. Harnessen beskrives som et fem-tuppel av prompt, verktøy, ferdigheter, middleware og minne (arXiv). Poenget med definisjonen er ikke akademisk. Når du kan navngi de fem delene, kan du endre en av gangen og se hva som skjer. Uten den oppdelingen blir «agenten ble bedre» en anekdote som ingen kan etterprøve.

Det gir også en måte å tilskrive feil på. I Co-Harness-rammeverket analyserer en LLM-basert komponent kalt HarnessCritic feilede kjøringer og plasserer feilen på harness-nivå før den foreslår en konkret endring (arXiv). Forskjellen på «modellen er dum» og «prompten mangler et steg» er hele forskjellen mellom å bytte leverandør og å fikse noe på en ettermiddag.

Hvorfor modellnavnet er feil første spørsmål

Modellvalg er det eneste laget de fleste innkjøpere føler seg kompetente til å diskutere. Det er også laget du har minst kontroll over: du kan velge mellom et titalls modeller, men du kan ikke endre noen av dem. Harnessen er det motsatte. Den er billig å endre, den er din, og den forklarer en stor del av variansen når alt annet holdes fast (composio.dev).

I praksis betyr det at en leverandørdemo som viser frem modellnavnet og ikke harnessen, viser frem feil ting. Be heller om å se systemprompten, verktøydefinisjonene og hva som skjer når agenten feiler. Den siste delen er den viktigste, og den er nesten alltid utelatt fra demoen.

Harness, plattform og rammeverk er ikke det samme

Et agent-rammeverk er koden du bygger med. En agentplattform er produktet du kjøper. Harnessen er den konkrete konfigurasjonen som faktisk kjører: hvilke instruksjoner, hvilke verktøy, hvilke inngripener, hvilket minne. To selskaper på samme plattform kan ha helt ulike harnesser, og dermed helt ulik ytelse.

Det er derfor sammenligninger på plattformnivå sjelden er nyttige alene. Vi har skrevet mer om hvordan arkitekturvalgene henger sammen i vår gjennomgang av harness-arkitektur. Det praktiske rådet er enkelt: vurder konfigurasjonen, ikke merkevaren.

Fem deler i harnessen: prompt, verktøy, ferdigheter, middleware og minne

De fem delene er ikke like viktige, og de feiler ikke på samme måte. Prompt og verktøy er synlige og får mest oppmerksomhet. Ferdigheter, middleware og minne er der de fleste reelle produksjonsfeilene oppstår, og der de færreste leverandører viser frem noe konkret. Tabellen under er en arbeidsliste du kan ta med inn i en leverandørsamtale.

Del av harnessen	Hva det er	Typisk feilmodus	Hva du kan endre uten å bytte modell
Prompt	Systeminstruksjon og oppgaveformulering	Agenten hopper over et steg fordi det aldri ble bedt om	Eksplisitte stegkrav, avslutningskriterier, formatkrav
Verktøy	Funksjoner agenten kan kalle	Feil verktøy velges, eller samme kall gjentas	Færre og skarpere verktøy, tydeligere beskrivelser
Ferdigheter	Prosedyrer for gjenkjennbare situasjoner	Agenten improviserer der en fast prosedyre finnes	Kodifiserte ferdigheter som utløses på tilstand
Middleware	Laget som griper inn i agentløkken	Feil oppdages først i sluttsvaret	Inngripen ved feilutsatte tilstander, tidlig stopp
Minne	Det agenten bærer mellom steg og kjøringer	Kontekst mistes, eller gammel kontekst forgifter nye svar	Hva som lagres, hva som hentes, hva som slettes

Prompt og verktøy: det synlige laget

Prompt og verktøy er der de fleste starter, og det er riktig sted å starte. Men de er også der arbeidet stopper for ofte. En agent med tolv verktøy og en tre siders systemprompt er ikke nødvendigvis bedre enn en med fire verktøy og en side. I den kontrollerte sammenligningen hadde antall verktøykall ingen klar sammenheng med suksess, og harnessen med flest kall, 402, var ikke den beste (composio.dev).

Det er et nyttig korrektiv mot en vanlig innkjøpsrefleks: å telle integrasjoner. Antall tilkoblede systemer sier noe om rekkevidde, ikke om treffsikkerhet. En agent som kan nå ti fagsystemer og velger feil i tre av dem, er dyrere enn en som når fire og treffer.

Ferdigheter som kjørbare programmer

Ferdigheter har tradisjonelt vært tekst: en beskrivelse av hvordan agenten bør gå frem. HASP-rammeverket gjør ferdigheter om til kjørbare Program Functions som aktiveres i feilutsatte tilstander og enten endrer neste handling eller injiserer korrigerende kontekst (arXiv). Forskjellen er at en kjørbar ferdighet faktisk utløses, mens en tekstbeskrivelse bare håper å bli lest.

Effekten er målbar uten at modellen endres. Ved inferenstid rapporteres 25 prosent bedre gjennomsnittlig ytelse på websøk sammenlignet med en flerstegs ReAct-agent, og det skjer med ferdighetsprogrammene alene, uten noen ny trening (arXiv). Legger du i tillegg til en komponent som velger riktig ferdighet for situasjonen, stiger nøyaktigheten på websøk-resonnering ytterligere.

Fordelingen av inngripener sier noe om hvor arbeidet ligger. Flertallet av aktiveringene skjedde på handlingsnivå, og resten på kontekstnivå (arXiv). Med andre ord: det hjelper mer å stoppe agenten fra å gjøre feil ting enn å gi den mer tekst å lese.

Middleware og minne: der feilene stoppes

Middleware er det minst glamorøse laget og ofte det mest lønnsomme. Poenget er å oppdage en feilutsatt tilstand mens agenten fortsatt kan korrigere, ikke etterpå. I HASP-kjøringene utløste den mest aktive ferdigheten, oppdeling av sammensatte spørsmål, 322 ganger, mens en ferdighet for utilstrekkelig utforskning utløste 138 ganger (arXiv). Det er 322 anledninger til å unngå et dårlig svar.

Minne er det laget som oftest feiler stille. En agent som husker for lite gjentar arbeid. En som husker for mye drar gammel og feil kontekst inn i nye oppgaver, og feilen ser ut som en modellfeil. Når du evaluerer en plattform, spør spesifikt hva som skrives til minne, hvor lenge det lever, og hvordan det slettes. Svaret er ofte overraskende uklart.

Les også: 70 agent-systemer viser at harness slår modellvalg. En gjennomgang av 70 agent-systemer peker på fem designvalg i orkestreringslaget.

Rammeverk for å skille modellvalg, harness og ettertrening

Tre knapper påvirker agentytelsen, og de har helt ulik kostnad, ledetid og eierskap. Blander du dem sammen, ender du med å betale for den dyreste når den billigste ville løst problemet. Det vanligste feilkjøpet vi ser i markedet er en modelloppgradering som skulle vært en promptendring.

Knapp	Hvem eier den	Typisk ledetid	Når den er riktig først
Modellvalg	Leverandøren	Timer til dager	Oppgaven krever resonnering modellen åpenbart ikke mestrer
Harness	Deg	Dager til uker	Feilene er gjenkjennbare og gjentar seg på samme steg
Ettertrening	Deg eller en partner	Uker til måneder	Harnessen er stabil og feilene er fordelt, ikke konsentrerte

Knappene har ulik ledetid og ulik risiko

Modellbytte er raskest å gjennomføre og vanskeligst å reversere konsekvensene av, fordi hele oppførselen endres samtidig. Alt du har kalibrert mot forrige modell må testes på nytt. Det er ikke et argument mot å bytte, men det er et argument for å vite hva du prøver å løse først.

Harness-endringer er billige, lokale og lette å rulle tilbake, forutsatt at du har versjonert dem. Ettertrening er tyngst: den krever data, kjøretid og kompetanse, og den låser deg til et tidspunkt. Til gjengjeld er det den eneste knappen som flytter modellens egen oppførsel.

Rekkefølgen som gir mest per krone

Start med harnessen, fordi den er din og fordi effekten er dokumentert i kontrollerte oppsett (composio.dev). Gå til modellvalg når du har en harness som er god nok til at sammenligningen er meningsfull. Gå til ettertrening sist, når harnessen er stabil og du har nok feilkjøringer til å trene på noe reelt.

Forskningen peker i samme retning, men med en vri: de to siste knappene er ikke uavhengige. Co-Harness veksler mellom å forbedre harnessen og å finjustere modellvektene på kjøringer generert av den forbedrede harnessen (arXiv). Trener du på data fra en dårlig harness, sementerer du dårlig oppførsel i vektene.

Samme modell, ulik harness: 20 prosentpoeng i sprik

Dette er den mest direkte dokumentasjonen som finnes på at harness betyr noe, og den er verdt å lese nøye, inkludert forbeholdene. Åtte harnesser ble kjørt på samme modell via samme leverandør, med samme resonneringsnivå og samme verktøy, på 25 oppgaver knyttet til forretningsapplikasjoner (composio.dev). Det ga 200 scorede resultater.

Måling	Beste observerte verdi	Svakeste observerte verdi
Passrate	88 prosent	68 prosent
Estimert totalkostnad	9,28 dollar	35,37 dollar
Kostnad per vellykkede oppgave	0,46 dollar	1,96 dollar
Median kjøretid	156,2 sekunder	330,5 sekunder
Verktøykall	223	402

Slik var testen satt opp

Kontrollen er det viktigste ved oppsettet. Fordi modell, leverandør, resonneringsnivå og verktøy var identiske på tvers av alle åtte, kan forskjellen i utfall ikke skyldes modellen (composio.dev). Token- og kostnadsmålingene ble gjort på et felles 24-oppgavers utsnitt, og prisestimatene bygger på listepriser hentet 30. juli 2026.

Toppresultatet var 22 av 25 beståtte oppgaver, med en nær konkurrent på 21 (composio.dev). Fem oppgaver ble fjernet fra alle harnesser før scoringen. Det er en detalj de fleste hopper over, men den påvirker hvor mye vekt du kan legge på små forskjeller mellom nummer to og nummer fire.

Hva som skiller topp fra bunn

Den svakeste harnessen traff en fast tidsgrense på 900 sekunder i en av oppgavene og ble avbrutt (composio.dev). Det er ikke en modellsvakhet. Det er en harness-beslutning om hvor lenge agenten får jobbe og hva som skjer når den nærmer seg grensen. En harness som avslutter med et delvis svar, taper mindre enn en som avslutter med ingenting.

Tokenbruken varierte også kraftig. Den ene harnessen brukte 15,27 millioner tokens på 24-oppgavesettet (composio.dev). Når totalkostnaden spenner fra 9,28 til 35,37 dollar for det samme arbeidet, er det harnessens forbruksmønster som forklarer forskjellen, ikke prislisten.

Oppgavene ingen klarte

Alle åtte harnessene besto de samme 12 oppgavene og feilet de samme tre svært vanskelige (composio.dev). Det er det mest lærerike funnet i hele oppsettet. En stor del av oppgavesettet skilte altså ikke mellom kandidatene i det hele tatt, og tre oppgaver lå utenfor rekkevidde uansett harness.

Konsekvensen for din egen test er direkte: oppgaver som alle klarer og oppgaver ingen klarer er bortkastet målekapasitet. Det er midtsjiktet som gir signal. Når du bygger testsettet ditt, skal du forvente å kaste ut oppgaver etter første runde, og det er et sunnhetstegn, ikke et feilsteg.

Ettertrening løfter agenten videre når harnessen er på plass

Når harnessen er ryddet, er neste knapp modellens egen oppførsel. Her har det skjedd noe metodisk interessant i 2026: i stedet for å behandle harness og vekter som to separate prosjekter, behandles de som et system som forbedres vekselvis. Forfatterne bak Co-Harness hevder å være først ute med å samevolvere begge deler (arXiv).

Co-Harness: vekselvis harness og vekter

Metoden kjører to runder: harnessen forbedres, modellen finjusteres på kjøringer fra den forbedrede harnessen, og syklusen gjentas (arXiv). Gjennomsnittlig nøyaktighet stiger markert fra utgangspunktet til etter andre runde, målt over to modellstørrelser på tre matematikkbenchmarks.

Den største enkeltforbedringen kom på en av matematikkbenchmarkene for den største modellen (arXiv). Oppsettet rapporteres også å ligge klart foran et harness som mennesker hadde designet og deretter holdt statisk. Det er verdt å notere for enhver som tror harness-arbeid er ferdig når en erfaren ingeniør har skrevet en god systemprompt.

Et beslektet resultat finnes på ferdighetssiden. Etter trening og kontrollert evolusjon rapporterer HASP forbedring over en sterk trent baseline, og på koding er forskjellen i gjennomsnittlig pass@1 mellom inngripen ved inferenstid og ferdighetsbasert trening svært liten (arXiv). Merk hvor liten den siste forskjellen er: treningen ga mindre enn inngripen gjorde.

Regelen som gjør endringene trygge

Den mest overførbare ideen i Co-Harness er ikke treningsmetoden, men akseptkriteriet. En harness-endring tas bare inn dersom den forbedrer den målrettede feilmodusen uten regresjon på andre holdout-atferder (arXiv). HASP bruker en tilsvarende port på ferdighetssiden: kandidater valideres på syntaks, grensesnitt og en testkjøring før de får plass i biblioteket (arXiv).

Dette er direkte anvendbart i en norsk SMB uten forskningsbudsjett. Hver gang noen endrer systemprompten, skal endringen bestå to tester: løser den feilen den var ment å løse, og ødelegger den noe annet. Uten den andre testen vokser prompten med et nytt avsnitt hver uke, og ytelsen går sakte nedover mens alle tror den går oppover.

Bygg et testsett på egne oppgaver før du velger

Dette er den delen du kan starte med på mandag. Alura mener du skal teste på ditt eget oppgavesett før du låser deg til en agentplattform, og holde modell, leverandør og verktøy konstant i testen. Uten den kontrollen måler du ikke harnessen, du måler støy.

Et sett på 25 oppgaver er en fornuftig start og er samme størrelsesorden som den publiserte sammenligningen brukte (composio.dev). Det er lite nok til at et lite team klarer å score manuelt, og stort nok til at forskjeller på flere oppgaver betyr noe. Regn med at du kaster og erstatter en del av dem etter første runde.

Oppgavene skal komme fra faktisk arbeid

Ikke hent oppgaver fra offentlige benchmarks. De er ofte matematikk eller kodeoppgaver, de er sannsynligvis sett under trening, og de ligner ikke på det agenten skal gjøre hos deg. Hent i stedet oppgaver fra arbeid som faktisk ble gjort forrige kvartal, der du vet hva riktig svar var.

Kategori	Eksempel på oppgave	Hva den tester	Vanlig feilmodus
Uthenting	Finn oppsigelsesklausul i en avtale	Presisjon i lang kontekst	Rett type klausul, feil avtale
Sammenstilling	Sammenlign vilkår på tvers av flere leverandører	Struktur og konsistens	Mangler en leverandør uten å si fra
Vurdering	Flagg avvik mot intern policy	Regelanvendelse	Flagger alt, eller ingenting
Flerstegs	Hent data, beregn, skriv notat	Planlegging og verktøybruk	Stopper etter steg to
Feilhåndtering	Oppgave med manglende kildedokument	Ærlighet ved usikkerhet	Finner på et svar

Den siste kategorien er den viktigste og den som oftest mangler. En agent som sier «dokumentet finnes ikke» er mer verdt enn en som produserer et velskrevet svar basert på ingenting. Legg inn minst et par oppgaver der riktig svar er å nekte.

Hold alt annet konstant

Den kontrollerte sammenligningen låste modell, leverandør, resonneringsnivå og verktøy på tvers av alle kandidater (composio.dev). Gjør det samme. Hvis leverandør A kjører en modell og leverandør B en annen, har du ingen mulighet til å si hva som forårsaket forskjellen, og du har brukt to uker på å lære ingenting.

I praksis betyr det at du må be leverandørene om å kjøre på din modellkonfigurasjon. Noen sier nei. Det svaret er også informasjon: en plattform som ikke kan kjøre en annen modell enn sin egen, er et lock-in du bør prise inn.

Scoring som tåler innsyn

Definer bestått og ikke bestått før du kjører, ikke etter. To personer bør score uavhengig på minst en delmengde, slik at du vet om kriteriene faktisk er entydige. Forskningen gjør det samme: i Co-Harness merket to ekspertannotatorer 200 feiltrajektorier med en innbyrdes enighet på κ=0,77 (arXiv).

Du trenger ikke regne kappa i et SMB-prosjekt. Men du trenger å vite at de to som scoret var enige om mer enn tre firedeler av oppgavene. Er de ikke det, er problemet kriteriene dine, ikke agenten.

Due diligence og dokumentgjennomgang som konkret testcase

Dokumentgjennomgang er den vanligste første agent-casen i norske SMB-er, og den er godt egnet som testcase av tre grunner: fasiten finnes, arbeidet er repeterende, og feilene er dyre nok til at noen bryr seg om målingen. En due diligence-prosess med avtaler, styreprotokoller og regnskapsnotater gir også naturlig variasjon i vanskelighetsgrad.

Hvorfor dokumentgjennomgang er en ærlig test

Oppgaven er flerstegs uten å være kunstig: finn dokumentet, finn passasjen, vurder den mot et kriterium, skriv det ned med referanse. Det er nøyaktig den typen oppgave der harnessen avgjør. En agent som mangler en ferdighet for å dele opp sammensatte spørsmål, vil svare på halve spørsmålet og se selvsikker ut mens den gjør det. Nettopp den feilmodusen er den mest utløste i HASP-kjøringene (arXiv).

Legg inn oppgaver der svaret krever to dokumenter som motsier hverandre. Det er her de fleste harnesser kollapser til det første funnet de gjorde. Det er også her en menneskelig jurist bruker mest tid, som betyr at det er her gevinsten ligger hvis agenten klarer det.

Fra feilmodus til harness-endring

Når du har kjørt settet, sorter feilene etter type i stedet for etter alvorlighet. Gjentar den samme feilen seg på samme steg, er det en harness-feil og som regel billig å fikse. Er feilene spredt og ulike, er det oftere en modellgrense. Denne tilskrivningen er hele poenget med HarnessCritic-tilnærmingen (arXiv), og du kan gjøre den manuelt på 25 oppgaver.

En advarsel før du kobler agenten på reelle dokumenter: tilgangsstyring og loggføring må være på plass før første kjøring, ikke etter pilot. Vi har sett hvor ofte dette glipper i vår gjennomgang av sikkerhet i AI-agenter. En agent med lesetilgang til hele filområdet er et compliance-problem uavhengig av hvor god passraten er.

Les også: Tolv AI-agenter per bedrift endrer CRM for norske SMB-er. Organisasjoner kjorer i snitt tolv AI-agenter, og adopsjonen ventes a oke 67 prosent pa to ar.

Kostnad per vellykkede oppgave er styringstallet som betyr noe

Alura mener kostnad per vellykkede oppgave er et mer styrbart tall enn tokenpris eller total API-kostnad. Tokenprisen setter leverandøren. Totalkostnaden avhenger av hvor mye du kjører. Kostnad per suksess er det eneste tallet som kobler pengebruk til verdi, og det er tallet harness-arbeidet faktisk flytter.

Harness	Estimert totalkostnad	Kostnad per vellykkede oppgave	Observert passrate
Hermes Agent	9,28 dollar	0,46 dollar	Ikke oppgitt
Oh My Pi	Ikke oppgitt	0,52 dollar	Høyest i testen
Claude Code	35,37 dollar	1,96 dollar	Ikke oppgitt

Billigst totalt er ikke billigst per resultat

Harnessen med lavest totalkostnad hadde også lavest kostnad per vellykkede oppgave, 0,46 dollar, mens den med høyest passrate lå på 0,52 dollar per suksess (composio.dev). Forskjellen mellom de to er liten. Forskjellen opp til den dyreste, 1,96 dollar per suksess, er stor nok til å endre en business case.

Regn det ut på ditt eget volum. Skal agenten gjøre noe som i dag tar en erfaren medarbeider et kvarter, er selv den dyreste raden i tabellen billig. Skal den gjøre noe som tar to minutter, snur regnestykket. Det er derfor kostnad per suksess må regnes mot manuell tidsbruk for den konkrete oppgaven, ikke mot et generelt effektiviseringsmål.

Tid er også en kostnad

Median kjøretid varierte fra 156,2 til 330,5 sekunder i den samme sammenligningen (composio.dev). For batch-kjøringer over natten spiller det ingen rolle. For en agent en saksbehandler venter på, er det forskjellen mellom et verktøy folk bruker og et verktøy de omgår.

Kjøretid kan også optimaliseres på harness-nivå. I en av case-studiene ga en endring i hvordan kall ble samlet opp en kraftig reduksjon i veggklokketid (arXiv). Det er en arkitekturbeslutning, ikke en modellbeslutning, og den typen gevinst forsvinner hvis du kun forhandler om tokenpris.

Validering og sporbarhet når en harness-endring settes i drift

Harnessen din vil endre seg. Noen legger til en instruksjon, noen legger til et verktøy, noen justerer minnet. Uten sporbarhet vet ingen hvilken versjon som kjørte da et svar ble feil, og da kan du heller ikke forsvare beslutningen i ettertid. Dette er det praktiske kravet AI Act oversettes til i hverdagen, og det er billig å bygge inn fra start.

Versjoner harnessen som kode

Systemprompt, verktøydefinisjoner og ferdighetsbibliotek hører hjemme i versjonskontroll med en identifikator som logges sammen med hvert svar. At dette er nødvendig blir tydelig av hvor fort harnesser endrer seg: i en autonom evolusjonskjøring ble det produsert 22 harness-versjoner på en enkelt benchmark (arXiv).

Hver versjon skal ha en kort begrunnelse: hvilken feilmodus den adresserte, og hvilke tester som ble kjørt. Det er samme disiplin som i vanlig programvareutvikling, og den er like nødvendig her. Regulatoriske krav til dokumentasjon av agentsystemer er fortsatt under avklaring, noe vi går nærmere inn på i vår gjennomgang av personlige AI-agenter og AI Act.

Logg trajektorier, ikke bare svar

Et sluttsvar forteller ikke hvorfor det ble feil. Logg hele kjøringen: hvilke verktøy ble kalt, i hvilken rekkefølge, hva som ble hentet fra minnet, hvor agenten snudde. All harness-forbedring i forskningen bygger på nettopp dette datagrunnlaget, der feilede kjøringer analyseres og tilskrives et lag (arXiv).

Dette har en konkret konsekvens for plattformvalg: en plattform som ikke gir deg tilgang til trajektoriene, fratar deg muligheten til å forbedre. Sett det som et absolutt krav. Uten kjøringsdata er du henvist til å bytte leverandør hver gang noe går galt, og det er den dyreste formen for feilsøking som finnes. Pålitelighet før hastighet er også temaet i vår artikkel om selvforbedrende agenter.

Markedsobservasjon: hva tallene fra 2026 viser og ikke viser

Alura mener tall fra preprints og leverandørblogger er utgangspunkt for egne tester, ikke fasit, siden de er egenrapporterte og ikke uavhengig replikert. Det gjelder alle tallene i denne artikkelen. De er nyttige fordi de viser retning og størrelsesorden, ikke fordi de forutsier hva du får.

Hva som er rimelig godt dokumentert

At harnessen forklarer en betydelig del av variansen når alt annet holdes konstant, er det sterkeste funnet, fordi oppsettet var kontrollert på de variablene som ellers forvirrer (composio.dev). At inngripen under kjøring hjelper mer enn mer tekst i prompten, støttes av fordelingen mellom handlingsnivå og kontekstnivå i HASP (arXiv).

At harness og modellvekter henger sammen, og at rekkefølgen betyr noe, er metodisk godt begrunnet selv om tallene er egenrapporterte (arXiv). Disse tre observasjonene tåler du å bygge en beslutningsprosess på.

Hva tallene ikke sier

De sier ingenting om dine oppgaver. Benchmarkene i forskningen er matematikk, websøk og koding. AIME 2024 består av 30 oppgaver (arXiv), og den kontrollerte harness-sammenligningen brukte 25. Det er små sett der noen få oppgaver flytter prosenttallet mye. Rangeringen mellom nummer to og nummer fire er innenfor støy.

De sier heller ingenting om hva som skjer over tid. En autonom kjøring på over 200 timer endte lavere enn det styrte oppsettet, selv når det beste resultatet i case-studien telles (arXiv). Autonom selvforbedring er lovende og umoden på samme tid. Behandle den som forskning, ikke som produktfunksjon.

Og de sier ingenting om drift: tilgangsstyring, personvern, hva som skjer når et fagsystem endrer API. Det er der de fleste agent-prosjekter faktisk stopper, ikke på passrate. Antall agenter per bedrift øker raskt, og driftsbyrden øker med dem, noe vi har sett nærmere på i artikkelen om agenter i CRM.

Vanlige feil når selskaper velger agent uten å teste harnessen

Feilene under er ikke hypotetiske. De er mønstre vi ser igjen i innkjøpsprosesser der beslutningen tas på demo og prisliste i stedet for på egne data. Alle er billige å unngå hvis du kjenner dem på forhånd.

Å bytte modell når problemet ligger i konteksten

Den vanligste reaksjonen på en skuffende agent er å oppgradere modellen. Det er også den dyreste, og ofte den minst treffsikre. Hvis feilen gjentar seg på samme steg i samme type oppgave, er det et harness-symptom. Tilskrivning av feil til riktig lag er nettopp det HarnessCritic-tilnærmingen formaliserer (arXiv).

Test det billig: skriv om prompten for det ene steget som feiler, kjør settet på nytt, se om feilen forsvinner. Det tar en time. Et modellbytte tar to uker og ugyldiggjør alle tidligere målinger.

Å måle aktivitet i stedet for resultat

Verktøykall, tokenforbruk og kjøretid er innsatsfaktorer. De er lette å telle og derfor fristende å rapportere. Men antall verktøykall hadde ingen klar sammenheng med suksess i den kontrollerte testen (composio.dev), og en agent som jobber lenge kan være grundig eller fortapt.

Rapporter passrate og kostnad per suksess til ledelsen. Behold aktivitetstallene som feilsøkingsdata for teamet. Blandes de to, ender du med et styringsdokument der ingen kan se om agenten faktisk gjør nytte.

Å kjøpe plattform før feilmodusene er kjent

En agentplattform velges typisk før noen har sett hvordan agenten feiler på reelle oppgaver. Dermed kjøpes det etter integrasjonslister og brukergrensesnitt, ikke etter evnen til å gripe inn i kjøringen. Kravet du bør stille er konkret: kan vi legge inn egne inngripener ved definerte tilstander, og kan vi validere dem før de settes i drift, slik både HASP og Co-Harness gjør (arXiv).

Et beslektet feilkjøp er å akseptere en plattform som ikke lar deg kjøre din egen modellkonfigurasjon. Da kan du aldri gjennomføre en kontrollert sammenligning, og du har gitt fra deg den ene knappen som var billig å vri på.

Ofte stilte spørsmål om AI-agent harness

Spørsmålene under er de som oftest kommer fra ledergrupper når harness-begrepet introduseres i en innkjøpsprosess.

Er harness bare et annet ord for prompt engineering?

Nei. Prompten er en av fem deler, sammen med verktøy, ferdigheter, middleware og minne (arXiv). De fire andre handler om hva agenten kan gjøre og hva som skjer mens den gjør det, ikke om hva den blir bedt om. Fordelingen av inngripener i HASP, der flertallet skjer på handlingsnivå, illustrerer at mesteparten av arbeidet skjer utenfor prompten (arXiv).

Hvor mange oppgaver må testsettet ha?

Start med 25, som er samme størrelse som den publiserte sammenligningen brukte (composio.dev). Vær klar over begrensningen: i det settet besto alle kandidatene de samme 12 oppgavene og feilet de samme tre. Med et lite sett kan du skille topp fra bunn, men ikke rangere kandidater som ligger tett. Trenger du den presisjonen, må settet vokse.

Kan vi hoppe over ettertrening?

For de fleste SMB-er: ja, i hvert fall til å begynne med. Harness-endringer alene ga 25 prosent forbedring på websøk ved inferenstid uten noen trening (arXiv). Ettertrening krever data, kompetanse og kjøretid, og den bør uansett komme etter at harnessen er stabil, siden trening på kjøringer fra en svak harness låser inn svak oppførsel (arXiv).

Hvordan vet vi at en harness-endring faktisk hjalp?

Ved å kreve to ting samtidig: forbedring på den feilmodusen endringen var rettet mot, og ingen regresjon på et holdout-sett du ikke rørte (arXiv). Uten den andre halvdelen vil prompten vokse i det uendelige, og den totale ytelsen kan falle mens hver enkelt endring ser vellykket ut isolert.

Bør vi vente til markedet har standardisert seg?

Det du bygger nå, testsettet, scoringskriteriene og trajektorie-loggingen, overlever et plattformbytte. Selve harness-konfigurasjonen gjør det ikke. Derfor er ventetid mest fornuftig for innkjøpsbeslutningen og minst fornuftig for målearbeidet. Kommer du til et innkjøpsmøte med 25 scorede oppgaver fra egen drift, forhandler du fra en helt annen posisjon enn med en kravspesifikasjon.

Oppsummering og neste steg

Harnessen forklarer en stor del av forskjellen mellom agenter som fungerer og agenter som ikke gjør det. Det er dokumentert i et oppsett der modell, leverandør, resonneringsnivå og verktøy var identiske, og passraten likevel spriket med 20 prosentpoeng (composio.dev). Det betyr at den viktigste variabelen i et agentprosjekt er en du eier selv.

Ettertrening kommer på toppen, ikke i stedet. Vekselvis forbedring av harness og modellvekter gir rapportert løft i kontrollerte forsøk (arXiv), men rekkefølgen er avgjørende: en stabil harness først, trening etterpå. Og hele veien gjelder akseptkriteriet om forbedring uten regresjon.

Tallene i denne artikkelen er egenrapporterte og ikke uavhengig replikert. Bruk dem til å stille bedre spørsmål, ikke til å velge leverandør. Den eneste målingen som avgjør noe for deg, er den du gjør på egne oppgaver.

Det du kan gjøre denne uken

Velg en prosess der fasiten finnes, for eksempel dokumentgjennomgang i due diligence. Plukk 25 oppgaver fra arbeid som faktisk ble utført, inkludert et par der riktig svar er å nekte. Definer bestått og ikke bestått skriftlig før første kjøring, og la to personer score uavhengig.

Kjør deretter kandidatene med samme modell, samme leverandør og samme verktøy. Rapporter to tall: passrate og kostnad per vellykkede oppgave. Sorter feilene etter hvilket steg de oppsto på, ikke etter hvor alvorlige de var. Da vet du innen kort tid om problemet ligger i modellen eller i harnessen, og det er den eneste diagnosen som gir en handlingsplan.

I Alura bygger vi AI-infrastruktur for norske virksomheter, fra dataplattformer til agentiske systemer i produksjon. Vi er ikke en SaaS-leverandør. Vi er håndverkere som setter sammen byggesteinene som faktisk fungerer for din situasjon.

Bestill en arkitektur-samtale: vi går gjennom din nåværende infrastruktur, identifiserer integrasjonspunkter, og foreslår en pragmatisk vei videre. Uforpliktende, 45 minutter.

Kilder

composio.dev. 8 Best AI Agent Harnesses in 2026: Performance, Cost ...
arXiv. Co-Harness: Co-Evolving Harnesses and Model Weights for LLM Agents
arXiv. Harnessing LLM Agents with Skill Programs