Din komplette guide til agent harness

Hvert AI-system du bruker — uansett om det er en chatbot, en kodingsagent, eller en saksbehandlingsplattform — består av to ting: en språkmodell og alt som omgir den. Det siste kalles en agent harness.

I norsk kontekst finnes det ennå ikke et etablert begrep for dette. Vi foreslår «agentstillas» — infrastrukturen som bærer, støtter og styrer det som bygges — men bruker «agent harness» gjennom denne guiden, som er det bransjeetablerte begrepet i 2026.

Og det er kvaliteten på denne harnessen — ikke modellen — som avgjør om du får et svar som er brukbart, etterprøvbart og pålitelig. Eller noe som «høres riktig ut».

Hva er en agent harness?

En agent harness er den komplette programvareinfrastrukturen som omgir en språkmodell og gjør den til en funksjonell agent. Hvis modellen er prosessoren, er harnessen operativsystemet.

Modellen kan resonnere, generere tekst, og velge verktøy. Men den kan ikke huske hva den sa for fem minutter siden. Den kan ikke lagre resultater. Den kan ikke koordinere med andre modeller. Den kan ikke bestemme hvilke av sine hundre og femti verktøy som er relevante akkurat nå. Den kan ikke dele opp et stort dokument i håndterbare biter. Og den kan ikke vite om svaret den akkurat ga var riktig.

Alt dette er harnessens jobb. Orkestrering. Verktøyhåndtering. Kontekststyring. Tilstandspersistens. Feilhåndtering. Mellomvare. Planstyring. Instruksjonslasting. Dokumentbehandling. Datalag. Listen er lang — og hvert punkt avgjør kvaliteten du opplever.

Hvorfor harnessen avgjør mer enn modellen

Alle bruker de samme modellene. Claude, GPT-4o, Gemini — de er tilgjengelige for alle via API. Prisen er den samme per token. Kapabiliteten er den samme. Det er en vare.

Det som ikke er en vare er hva som skjer mellom brukerens spørsmål og modellens svar. Hvordan konteksten bygges opp. Hvilke verktøy som gjøres tilgjengelig. Hvordan resultater verifiseres. Hvordan lange oppdrag koordineres på tvers av mange kontekstvinduer.

Anthropic publiserte i 2025 et innlegg kalt «Effective harnesses for long-running agents» som dokumenterer hvordan agenter mister oversikt over langvarige oppgaver — og hvordan strukturerte kontekstfiler, fremdriftslogger, og initialiseringsrutiner løser det. LangChain har definert en klar taksonomi: rammeverk gir abstraksjoner, kjøretid gir persistens og feilhåndtering, harness gir det ferdig konfigurerte systemet. Og bransjens konsensus i 2026 er at å forbedre harnessen — ikke å bytte modell — er det som gir størst kvalitetsløft.

Orkestrering: Grafer, ikke prompt-kjeder

Den enkleste formen for AI-agent er en løkke: modellen genererer, ser resultatet, og genererer igjen. Det fungerer for enkle oppgaver. For saksbehandling — der en sak kan kreve juridisk oppslag, eiendomsdata, artsdata, kartanalyse, arkivintegrasjon og dokumentproduksjon, i den rekkefølgen, med avhengigheter mellom stegene — trengs en mer sofistikert orkestrering.

I praksis modelleres dette som en rettet graf. Hver node i grafen er en funksjon: et modellkall, et verktøykall, en betingelse, eller et kall til en annen graf. Kanter mellom nodene definerer flyten. Betingede kanter gjør det mulig å rute basert på tilstand — hvis modellen ber om et juridisk oppslag, rutes forespørselen til en juridisk spesialist; hvis den ber om et dokument, rutes den til en dokumentbehandler.

Grafen er eksplisitt. Den er versjonerbar, testbar og debuggbar. Hvert steg logges med input og output. Og den tillater noe en flat prompt-kjede ikke kan: parallelle steg, betingede forgreninger, og tilbakekobling til tidligere noder.

Spesialiserte agenter med avgrensede kontekster

Å gi én modell alle verktøyene er en oppskrift på dårlig kvalitet — forskning viser at verktøyvalgsnøyaktigheten faller fra 43 % til 2 % når antallet verktøy øker fra fire til femtien. Alternativet er spesialisering.

I en multi-agent-arkitektur har hvert domene sin egen agent med et begrenset verktøysett. En juridisk agent har tre verktøy: planlegg søkestrategi, søk i lovverket, og hent spesifikt dokument. En eiendomsagent har fire: søk adresser, slå opp matrikkeldata, valider, og resolv kommune. En geodata-agent kan ha tjue — men de er alle innenfor geodomenet.

Over disse sitter en koordinator som ser spesialistene, ikke verktøyene. Delegering skjer gjennom to mønstre:

Transfer-mønsteret: Koordinatoren har transfer-verktøy som returnerer en navigasjonskommando — en rute til en annen node i grafen. Den nye noden kaller en hel undergraf (en kompilert spesialistagent) og returnerer resultatet til koordinatoren.

Subagent-mønsteret: Spesialisten pakkes inn i ett verktøy. Verktøyet instansierer spesialistens graf med en ren melding, kjører den til fullføring, og returnerer resultatet som tekst. Koordinatoren ser bare svaret — ikke mellomstegene.

Begge sikrer kontekstisolasjon: spesialisten arver ikke koordinatorens meldingshistorikk. Hvert oppdrag starter med et rent arbeidsminne — bare spørsmålet og relevante verktøy.

Verktøyhåndtering

Et verktøy i agent-kontekst er en funksjon med en presis beskrivelse og et validert skjema som modellen kan kalle. Kvaliteten på verktøydefinisjonen påvirker direkte kvaliteten på bruken.

Presise skjemaer. Hvert parameter beskrives med et typesystem og har en forklaring som gir kontekst. «Matrikkelenhets-ID for eiendommen» er bedre enn «id». «Søkeord for lovtekst, f.eks. plan- og bygningsloven § 29-4» er bedre enn «query».

Scoping. Verktøy eksponeres bare for agenten som trenger dem. Grafen binder kun de relevante verktøyene til modellen — typisk gjennom et eksplisitt kall der agenten får sine tre til femten verktøy, ikke alle hundre og femti.

Dynamisk verktøyvalg. For generelle agenter — som en chat-assistent som kan snakke om alt — brukes mellomvare til å velge verktøy dynamisk. Et sett basisverktøy er alltid tilgjengelig. Spesialist-subagenter aktiveres bare når konteksten krever det. Mellomvare filtrerer verktøylisten før hvert modellkall basert på tilstanden — og sørger for at verktøy injisert av annen mellomvare (som todo-håndtering) bevares.

Kontekststyring

Kontekstvinduet er en begrenset ressurs. En produksjonsharness behandler det som et budsjett.

Oppsummering. Når samtalehistorikken passerer en terskel — for eksempel 120 000 tokens — trigges en automatisk oppsummeringsrutine. En rask modell komprimerer eldre meldinger til et sammendrag. De siste meldingene beholdes intakt. Resultatet prefixes med en markør som gjør det tydelig at dette er en oppsummering, ikke en ny melding.

Meldingsfiltrering. Før hvert modellkall renses meldingshistorikken. Verktøykall uten tilhørende resultat fjernes — de forvirrer modellen. AI-meldinger med ufullstendige verktøykall filtreres bort. Bare komplette par — kall og resultat — beholdes.

Prompt-konstruksjon. Systeminstruksen bygges opp lagvis gjennom en mellomvarekjede. Først settes grunnpromptet. Deretter legges kontekstdokumenter til — referansekatalogen, aktiv plan, regler. Deretter legges verktøy til basert på tilstand. Resultatet er en komplett, tilpasset systeminstruks for akkurat denne forespørselen.

Prompt-caching. For systeminstrukser som endrer seg sjelden — og som kan utgjøre tusenvis av tokens — brukes caching med TTL. Den statiske delen av promptet re-prosesseres ikke for hvert kall. Det sparer tokens, reduserer latens, og holder kostnaden nede.

Planer, faser og oppgaver

En sak er ikke en enkelt samtale. Den strekker seg over dager eller uker, med mange deloppgaver og avhengigheter. Harnessen trenger et system for å holde styr på dette.

Planer er strukturerte dokumenter som beskriver hva som skal gjøres. De opprettes som «artifacts» — filer med en spesifikk type — og injiseres automatisk i agentens kontekst via mellomvare. Når agenten starter en ny sesjon, ser den den aktive planen som en del av systempromptets kontekstblokk, wrappet i XML-tagger som gjør det tydelig for modellen at dette er en handlingsplan.

Faser genereres av en dedikert fase-agent. Gitt en instruksjon og et sett med kildefiler, bryter den oppgaven ned i navngitte faser med beskrivelser. Fasene lagres via API og er synlige i brukergrensesnittet. Agenten leser først den ekstraherte teksten fra hvert dokument (hentet fra blob-lagring), og bruker en spesialisert prompt fra en prompt-hub til å generere fase-strukturen.

Oppgaver genereres per fase av en todo-agent. Den mottar en fase, eksisterende plan-oppgaver, og kontekst — og produserer konkrete, avkryssbare oppgaver. En dedikert mellomvare legger til et verktøy som lar agenten oppdatere status på oppgaver direkte fra samtalen. Agenten kan markere en oppgave som fullført, legge til en ny, eller endre beskrivelsen — alt gjennom verktøykall.

Dette er det Anthropic kaller «progress tracking» i sin harness-modell: evnen til å holde oversikt over hva som er gjort og hva som gjenstår, på tvers av kontekstvinduer.

Referansekatalogen

Mange agentsystemer mister kontekst mellom sesjoner. Brukeren har fortalt agenten noe viktig tre meldinger siden, men oppsummeringen har komprimert det bort. Løsningen er et levende kontekstdokument.

I saksbehandling kalles dette typisk referansekatalogen — et strukturert dokument som oppdateres løpende. Det er ikke en analyse, ikke en plan, ikke et vedtak. Det er en oppslagstabell.

Hva det inneholder: Parter og roller. Nøkkelfakta fra kildematerialet — datoer, steder, beløp, gnr/bnr, koordinater. Oversikt over kildefiler. Relevant lovverk oppdaget gjennom søk. Kartlag og geodata. Relevante eksterne datakilder.

Hva det ikke inneholder: Analyser, vurderinger, handlingslister, eller neste-steg. Det er en referanse, ikke en plan.

Format: Korte punktlister, tabeller, faktaoppslag. Scanbart. Maks noen hundre linjer. Hver seksjon skal kunne leses uavhengig.

Injisering og oppdatering: Mellomvare henter dokumentet fra databasen og legger det inn i systempromptets kontekstblokk ved hvert modellkall — så agenten alltid har oppdatert kontekst. Agenten oppdaterer dokumentet etter hvert som den oppdager nye fakta: etter et juridisk oppslag legges lovhenvisninger til, etter et eiendomsoppslag legges matrikkeldata til. Dokumentet vokser organisk gjennom sakens livssyklus.

Anthropic beskriver et parallelt mønster: en fremdriftsfil som logger hva agenten har gjort og hva som gjenstår. Forskjellen for saksbehandling er at referansekatalogen er saksspesifikk og strukturert rundt domenedata — ikke bare progresjon.

Selvoppdagelse

En av de mest kraftfulle komponentene i en saksbehandlings-harness er selvoppdagelse — agentens evne til å systematisk kartlegge sin egen situasjon.

1. Forstå saken. Agenten starter med å liste filer, lese kildedokumenter, og identifisere: hva handler dette om? Hvem er involvert? Hvilke steder, lover, eller fagfelt berøres?

2. Match tema mot verktøy. For hvert tilgjengelig verktøy stiller agenten: «Kan dette verktøyet fortelle meg noe om denne saken?» Et eiendomsverktøy er åpenbart relevant for byggesaker — men kanskje også for skolesaker (adresse → skolekrets). Et kartverktøy kan avdekke naturvernområder, flomsoner, eller infrastruktur.

3. Discovery-kall. For hvert potensielt relevant verktøy gjøres et utforskende kall — et åpent spørsmål: «Hva finnes av geodata for denne eiendommen?» Parallellisert der det er uavhengige spørsmål.

4. Kompiler referansekatalogen. Alle funn samles med nok kontekst til videre bruk: lovhenvisninger med paragrafnummer, kartlag med navn, datakilder med treff og relevans.

Dette er det motsatte av en bruker som vet nøyaktig hva de trenger og ber om det. Det er en agent som aktivt utforsker mulighetsrommet — og som oppdager relevante forhold brukeren ikke visste om.

Instruksjoner og regler

Ulike organisasjoner behandler saker ulikt. En kommune har sine retningslinjer, et direktorat har sine. Harnessen trenger et system for organisasjonsspesifikk kunnskap.

Instruksjoner er Markdown-dokumenter som beskriver behandlingsrammer, krav og prosedyrer. De lastes inn av en dedikert agent som henter instruksjonen fra API, eventuelt med eksempeldokumenter, og genererer en strukturert behandlingsramme.

Regler injiseres i systempromptets kontekstblokk via mellomvare. De listes med navn og ID, og agenten instrueres om å lese dem med fillesing — aldri med en oppsummeringsagent. Skillet er vesentlig: regler kan ikke oppsummeres uten risiko for at unntak, begrensninger, eller krav faller bort. En oppsummeringsagent er designet for å filtrere. Regler krever ordrett innhold.

Datalag: API-er designet for agenter

Det holder ikke å gi en agent tilgang til et API. API-et må være designet for hvordan agenter fungerer — det vil si: for tokenøkonomi.

To-stegs henting. En veiledningstjeneste med hundre retningslinjer eksponerer først en kompakt indeks — bare ID og tittel. Agenten velger de relevante, og henter detaljer kun for dem. Forskjellen kan være titusener av tokens.

Strukturerte skjemaer. Responsene valideres og struktureres i et forutsigbart format med feltbeskrivelser. Agenten trenger ikke å tolke vilkårlig JSON — den får et maskinlesbart, typesikkert svar.

Domenespesifikke transformasjoner. Et mellomlag transformerer, filtrerer og normaliserer rå API-responser fra eksterne tjenester. Newline-separerte strenger konverteres til arrays. Komplekse nestede strukturer flates ut. Irrelevant informasjon strippes bort. Resultatet er nøyaktig den informasjonen agenten trenger — ikke mer, ikke mindre.

Langvarige operasjoner. Noen domene-operasjoner tar minutter. En arealanalyse kan ta 2–5 minutter. API-et håndterer dette asynkront med status-polling, slik at agenten ikke blokkerer.

Mellomvare: Den usynlige fabrikken

Mellomvare er funksjoner som kjører mellom tilstanden og modellkallet. Usynlige for brukeren, men det er her harnessens magi skjer.

En typisk mellomvarekjede for en saksbehandlingsagent kan se slik ut:

1. Systemprompt-mellomvare — Laster grunnpromptet fra en prompt-hub eller hardkodet instruksjon.

2. Kontekst-mellomvare — Henter referansekatalog, aktiv plan, og regler fra databasen. Bygger kontekstblokken med XML-tagger.

3. Verktøyvalg-mellomvare — Filtrerer verktøylisten basert på tilstand. Bevarer verktøy injisert av annen mellomvare.

4. Oppsummeringsmellomvare — Komprimerer samtalehistorikk ved overskridelse av token-terskel.

5. Meldingsrens-mellomvare — Fjerner ufullstendige verktøykall og inkonsistente meldinger.

6. Todo-mellomvare — Legger til oppgavehåndteringsverktøy hvis saken har en aktiv plan.

7. Modellvalg-mellomvare — Bytter underliggende modell basert på brukerens preferanse eller oppgavens kompleksitet.

8. Prompt-caching-mellomvare — Aktiverer caching for statiske prompt-deler.

9. Observabilitets-mellomvare — Logger alt for feilsporing og analyse.

Rekkefølgen er vesentlig. Observabilitet må komme først for å fange alt. Prompt-caching bør komme sent for å cache det endelige promptet. Kontekst før verktøyvalg, fordi verktøyene kan avhenge av konteksten.

Dokumentbehandling: Store filer i små vinduer

Kildedokumenter i saksbehandling kan være hundrevis av sider. De passer ikke i ett kontekstvindu. Harnessen trenger en strategi for dette.

Chunking. Dokumentet deles opp i biter basert på modellens kapasitet. Systemet beregner kontekstvinduets størrelse (typisk 60 % av modellens øvre grense), setter chunk-størrelsen til 60 % av det tilgjengelige, og deler dokumentet deretter. Beregningen er dynamisk — den tilpasses modellen som brukes.

Parallell prosessering. Bitene sendes til modellen parallelt (batch), hver med det opprinnelige spørsmålet og sin bit av dokumentet. Modellen behandler dem uavhengig.

Syntese. Når alle biter er behandlet, sammenfattes resultatene i et eget steg. Modellen får alle delsvarene og produserer ett konsolidert svar.

Fan-out/fan-in. For saker med flere kildedokumenter brukes en fan-out-strategi: hvert dokument sendes til sin egen prosesseringsgraf parallelt. Resultatene samles i en fan-in-node som syntetiserer på tvers.

Deterministiske arbeidsflyter

Ikke alt trenger en språkmodell. Hvis stegene er kjente og rekkefølgen er fast, er en deterministisk arbeidsflyt bedre: raskere, billigere, og forutsigbar.

En produksjonsharness har to spor:

AI-sporet — for oppgaver som krever vurdering, tolkning, eller kreativitet. Modellen resonnerer, velger verktøy, og produserer tekst.

Workflow-sporet — for oppgaver som er sekvensielle og regelbaserte. Defineres som en rettet graf med noder for triggere, betingelser, HTTP-kall, og integrasjoner. Kjøres av en workflow-motor som gir varig utførelse, automatisk retry, og garantert fullføring.

Skillet er kritisk. En modell som brukes til noe deterministisk er bortkastet intelligens — den bruker tokens, introduserer variabilitet, og kan feile på noe som burde vært forutsigbart. En arbeidsflyt som prøver å håndtere noe som krever vurdering er for rigid. De beste harnesser vet når de skal bruke hvilken.

Hva dette betyr for kvalitet

Når noen viser deg en AI-demo, viser de deg en modell. Når du bruker et AI-system i produksjon, bruker du en harness.

Modellen er prosessoren. Den er viktig. Men den er den minst differensierte komponenten i systemet. Alle bruker de samme modellene. Prisene konvergerer. Kapabilitetene ligner hverandre.

Det som avgjør om du får et svar du kan stole på — med verifiserte kilder, korrekt lovhjemmel, og dokumentert beslutningsgrunnlag — er alt som omgir modellen. Orkestreringen som delegerer til riktig spesialist. Kontekststyringen som holder signal-støy-forholdet høyt. Plansystemet som holder oversikt over langvarige oppdrag. Referansekatalogen som bevarer fakta mellom sesjoner. Datalagene som gir modellen akkurat den informasjonen den trenger, i akkurat det formatet den kan bruke.

Det er agent harness. Og den er usynlig — helt til den ikke er der.