Harness Engineering fra grunnen av: Slik bygger du et arbeidsmiljø AI-agenter kan stole på

TL;DR: Fra gode prompts til et miljø AI-en kan jobbe trygt i

En god prompt kan få en AI til å løse én oppgave. Men når oppgaven varer lenge, skal fortsette i morgen eller må kunne kontrolleres av andre, er prompten bare en liten del av løsningen. Harness Engineering handler om å bygge miljøet rundt modellen: instruksjoner, verktøy, prosjektkontekst, minne, tester, observability og regler for når arbeidet skal stoppe.

Dette er hovedideen i Learn Harness Engineering, et gratis og åpent kurs fra Walking Labs. Kurset har 14 forelesninger og 8 praktiske prosjekter som bygger videre på den samme applikasjonen. Det starter med forskjellen på «prompt-only» og «rules-first», og ender med automatiserte loops og et grafbasert system med parallelle steg, tilbakerulling og menneskelig godkjenning. [1]

For en liten bedrift betyr ikke dette at dere må bygge en avansert plattform. Det betyr at dere bør flytte noe av kunnskapen ut av chatten og inn i et ryddig, versjonert arbeidsmiljø. Da kan en ny AI-økt forstå hva som er gjort, hva som gjenstår og hvordan resultatet skal sjekkes.

Hva er et harness?

Et harness er alt rundt modellen som gjør at den kan arbeide innenfor et mål, en kontekst og noen kontroller. Det er ikke det samme som en stor instruksjonsfil. I kursmaterialet deles et harness inn i fem deler: instruksjoner, verktøy, miljø, tilstand og tilbakemelding. [2]

Tenk på et vanlig kodeprosjekt. Modellen trenger å vite hvordan prosjektet startes, hvilke filer som er viktige, hvilke regler som ikke kan brytes, hvilke kommandoer den kan kjøre og hvordan den avgjør om jobben faktisk er ferdig. Hvis denne informasjonen bare ligger i hodet til én utvikler eller i en gammel chat, må hver ny økt gjette seg frem.

OpenAI beskriver samme prinsipp gjennom uttrykket «repoet er kilden til sannheten»: den kunnskapen agenten ikke kan finne i arbeidsmiljøet, er i praksis utilgjengelig for agenten. Derfor bruker de korte kartfiler som `AGENTS.md` og en strukturert `docs/`-mappe, i stedet for én enorm instruksjon som skal inneholde alt. [3]

De fem byggesteinene

Det er særlig den siste delen som ofte mangler. En agent kan skrive kode som ser riktig ut og likevel ha ødelagt en rute, en mobilvisning eller en viktig arbeidsflyt. «Det ser ferdig ut» er ikke det samme som «det er verifisert».

Hvorfor prompting alene stopper opp

I en vanlig chat er du scheduler. Du gir én beskjed, vurderer svaret og formulerer neste beskjed. Det fungerer fint for et e-postutkast, en oppsummering eller en liten kodeendring.

Problemet kommer når agenten skal jobbe i flere timer eller over flere økter. Den kan miste oversikten, begynne på for mange ting samtidig, glemme hvordan prosjektet startes eller erklære seier etter at bare deler av jobben er gjort. Anthropic beskriver derfor et skille mellom en første initializer-økt og senere arbeidsøkter. Initializer-en setter opp miljø, fremdriftslogg og en liste over funksjoner. Senere økter tar én avgrenset oppgave om gangen og etterlater prosjektet i en ryddig tilstand. [4]

Dette er også grunnen til at kursrepoet bruker en liste over funksjoner med eksplisitt status. Agenten skal ikke selv omskrive kravene for å få dem til å se ferdige ut. Den skal gjennomføre ett punkt, kjøre kontrollene og først endre status når resultatet er verifisert.

Fra kontekst til minne

Kontekst er det agenten trenger å vite akkurat nå. Minne er det som må overleve når dagens samtale avsluttes.

Et praktisk oppsett kan være en kort `AGENTS.md` som fungerer som et kart, en `docs/`-mappe med mer detaljert arkitektur og en `PROGRESS.md` med tre deler: gjort, neste steg og blokkert. Ved slutten av en økt skriver agenten hva som ble endret, hvilke tester som ble kjørt og hva neste agent bør lese først.

Dette er progressiv kontekst. Agenten får ikke hele virksomhetens dokumentarkiv i første melding. Den får et kart, finner den relevante delen og henter mer informasjon når oppgaven krever det. Det gir mindre støy, lavere kostnad og mindre risiko for at en viktig regel drukner i detaljer.

For en SMB kan det være så enkelt som å samle rutiner for tilbud, kundeservice eller interne rapporter i en tydelig mappe med eier, dato og status. Ikke legg inn alt bare fordi det kan være nyttig. Hver fil bør svare på spørsmålet: «Hvilken beslutning eller arbeidsoppgave hjelper dette agenten med?»

Oppgaver, scope og clean handoff

Et harness skal gjøre oppgaven mindre, ikke bare prompten lengre. Be agenten om én funksjon eller ett kontrollert delmål. Skriv hva som skal være sant når oppgaven er ferdig, hvilke filer den kan endre og hvilke tester som må passere.

En god overlevering sier for eksempel: «Innloggingsfeilen er rettet. Testene `npm test` og `npm run build` passerer. Endringen ligger i commit X. Det gjenstår å teste Safari på mobil.» Det er langt mer nyttig enn «jobben er ferdig».

Denne arbeidsformen passer godt sammen med 9 lag i en AI-produksjonsarkitektur, der evaluering, observability, sikkerhet og versjonerte prompts ligger som egne deler av systemet. Harness Engineering er ikke en erstatning for arkitektur; det er en måte å gjøre arbeidsmiljøet lesbart og kontrollerbart på.

Testing er en del av agentens arbeidsmiljø

Testing bør ikke være noe mennesket kommer på etterpå. Agenten bør vite hvordan prosjektet startes, hvilke tester som er relevante og hvordan feil skal vises.

For et nettsted kan det være en kombinasjon av å bygge statiske sider, validere metadata, åpne siden i en nettleser og kontrollere at en bruker faktisk kan gjennomføre en sentral handling. For en intern rapport kan det være å kontrollere summer, datointervall og et lite sett med kjente fasitsvar.

Det er nyttig å skille mellom agenten som lager en endring og agenten eller testen som kontrollerer den. Den samme agenten kan gjøre begge deler i et lite prosjekt, men kontrollen bør ha en ny kontekst og faste kriterier. En modell som nettopp har skrevet en løsning, har lett for å tolke sin egen intensjon som bevis på at løsningen virker.

En enkel kontrollsløyfe for en agent

1. Agenten leser oppgaven og velger ett avgrenset delmål.
2. Den endrer kode eller dokumenter i en separat gren eller arbeidsmappe.
3. Automatiske tester, bygging og linting kjøres.
4. En uavhengig sjekk vurderer resultatet mot kravene.
5. Ved feil går oppgaven tilbake til agenten med konkret tilbakemelding.
6. Ved godkjent resultat lagres endringen, fremdriften oppdateres og agenten stopper.

Når et harness blir til en loop

De første tolv forelesningene i repoet bygger et pålitelig enkeltløp. I forelesning 13 går kurset videre til Loop Engineering: systemet får selv starte neste runde.

En loop bør alltid ha tre ting: et mål, en måte å verifisere målet på og en stoppregel. Det kan være «få alle testene til å passere», men aldri bare «jobb videre til det føles bra». Maker-checker-modellen skiller den som lager endringen fra den som vurderer den. Dette er nært beslektet med Loop Engineering-artikkelen på Kakushin, som også forklarer `/goal`, Gauntlet Loop og hvorfor en selvforbedrende loop må ha grenser.

En trygg første loop kan være en daglig kontroll av en avgrenset GitHub-kø eller en testjobb som lager et forslag til feilretting. Den bør starte med lesetilgang og forslag. Først når dere har sett hvordan den oppfører seg, kan den få mer ansvar.

Når en loop blir en graf

Hvis oppgaven trenger flere roller, parallelle steg eller ulike veier ved feil, blir det naturlig å tegne arbeidsflyten som en graf. Et grafsteg kan være research, implementering, test, menneskelig godkjenning eller rollback. Mellom stegene ligger regler som «test godkjent → publiser» og «test feilet → tilbake til implementering».

Kursrepoets prosjekt 08 viser nettopp en slik overgang. Grafen har noder, kanter, delt tilstand, routing, parallelle grener og en mulighet for å stoppe før en risikofylt handling. Det er også her det blir viktig å lagre tilstanden etter hvert steg, slik at en avbrutt kjøring kan fortsette uten å starte helt på nytt. [1]

Dette er den tekniske fordypningen. De fleste småbedrifter trenger ikke en graf for å lage et godt førsteutkast. Men når en agent skal lese, klassifisere, skrive, kontrollere og oppdatere et system, er grafen en nyttig måte å gjøre ansvar og feilhåndtering synlig på. Se også AI-orkestrering: Modellen er ikke hele løsningen.

Hva betyr dette for en liten bedrift?

Start ikke med «vi skal bygge et agentharness». Start med en oppgave som allerede skaper friksjon: å sortere innkommende henvendelser, kontrollere dokumenter, oppdatere en intern statusrapport eller holde orden på en kodebase.

Skriv ned hvor dataene kommer fra, hva agenten skal levere, hva den aldri skal gjøre og hvordan en person kan kontrollere resultatet. Lag deretter én kort instruksjonsfil, én fremdriftsfil og én kommando for verifisering. Det er et lite harness.

Hvis oppgaven fungerer, kan dere legge til mer kontekst, bedre logging, flere tester og en ny arbeidsøkt. Hvis den feiler, har dere et konkret sted å lete. Det er mer verdifullt enn å bytte modell hver gang svaret blir dårlig.

Start her – en 60-minutters harness-sjekk

0–10 minutter: Velg én avgrenset oppgave med lav risiko. Skriv hva som skal leveres, og hva som krever menneskelig godkjenning.

10–25 minutter: Lag en kort `AGENTS.md` eller `CLAUDE.md` med prosjektets mål, viktigste mapper, kommandoen for å starte og tre regler agenten ikke kan bryte.

25–40 minutter: Lag `PROGRESS.md` og en liten sjekkliste med «gjort», «neste» og «blokkert». Be agenten oppdatere den ved slutten av økten.

40–55 minutter: Kjør én automatisk kontroll og én menneskelig kontroll. Test også hva som skjer når agenten får en uklar eller feilaktig instruksjon.

55–60 minutter: Skriv ned hva som feilet. Forbedre den svakeste delen først – mer kontekst, bedre test, tydeligere scope eller strammere tilgang.

Harness Engineering er ikke autopilot

Et godt harness gjør AI mer nyttig fordi det gjør arbeidet mer synlig og etterprøvbart. Det gjør ikke modellen ufeilbarlig. En test kan være for svak, dokumentasjonen kan være utdatert og en agent kan følge en regel som er feil.

Derfor bør human-in-the-loop, tilgangsstyring, logging og mulighet for rollback bygges inn før agenten får sende e-post, endre økonomidata, publisere eller slette. For virksomheter på Sunnmøre er dette ofte den viktigste gevinsten: ikke at AI gjør alt alene, men at flere oppgaver kan gjøres raskere uten at kontrollen forsvinner.

Videre i harness-sporet

Les Kom i gang med AI-agenter hvis dere vil velge en trygg første oppgave. Gå videre til AI-orkestrering når flere modeller, verktøy eller kontrollpunkter skal spille sammen. Loop Engineering bygger på harnesset når agenten skal prøve, kontrollere og forbedre arbeid over flere runder. Trendslop handler om hvordan skills, prosjektfiler og regler kan holde retning og kvalitet over tid. For den mer avanserte enden av skalaen viser Octopus OS hvorfor et harness også må ha tydelige grenser når en agent kan foreslå endringer i arbeidsmiljøet sitt.

Kilder

[1] Walking Labs — Learn Harness Engineering [2] Walking Labs — Lecture 02: What a Harness Actually Is [3] OpenAI — Harness engineering: leveraging Codex in an agent-first world [4] Anthropic — Effective harnesses for long-running agents [5] Walking Labs — Lecture 13: From Manual Prompting to Autonomous Loops [6] Walking Labs — Lecture 14: Graph Engineering