Først: Dette er to deler av samme arbeidsmåte
/goal og en Gauntlet Loop kan sammen få en agent til å arbeide videre mot et definert resultat. Men de er ikke det samme.
| Del | Oppgave | Spørsmålet den svarer på |
|---|---|---|
| /goal eller GOAL.md | Setter målkontrakten: ønsket resultat, avgrensning, kvalitet, rammer og stoppregel. | «Hva forsøker vi å oppnå — og når er vi ferdige?» |
| Gauntlet Loop | Lar en bygger, evaluator og tester forbedre resultatet mot målkontrakten. | «Består dette kravene, eller hva må bli bedre?» |
Tenk på det som en erfaren prosjektleder og en kvalitetssjekk: Målet hindrer at arbeidet blir tilfeldig. Kvalitetssperren hindrer at teamet kaller noe ferdig bare fordi det ser bra ut på første forsøk.
Mål → plan → utførelse → test → forbedring → godkjent eller stopp. Det er den nyttige formen for en agent-loop.
Begrepet Gauntlet Loop brukes her som en praktisk betegnelse på en streng evaluator–optimizer-loop. Det er ikke en universell produktfunksjon som slås på med én knapp. Ulike verktøy kan ha kommandoer som heter "/goal", men selve prinsippet fungerer like godt med et oppgavekort, en ticket eller en enkel GOAL.md-fil.
Hvorfor vanlig «prøv igjen» ikke er nok
En åpen loop kan gi agenten beskjed om å «fortsette til det fungerer». Det høres effektivt ut, men gir ofte tre problemer: Agenten kan miste den opprinnelige hensikten, bruke mer tid og token-kostnad uten synlig framdrift, eller endre for mye på én gang.
En lukket loop har derimot en synlig kontrakt og en kvalitetssperre. Den kjører bare videre når en test eller reviewer forklarer hva som mangler. Når den ikke kommer videre, ber den om avklaring i stedet for å gjette.
| Åpen loop | Målbasert, lukket loop |
|---|---|
| «Forsøk igjen til løsningen virker.» | «Forbedre bare mot definerte kriterier, med maksimalt tre forsøk.» |
| Agenten velger selv hva som er «godt nok». | Ferdigkriterier er skrevet før arbeidet starter. |
| Samme agent bygger og erklærer resultatet ferdig. | Bygger og evaluator har adskilte oppgaver. |
| Uklart hva som feilet og hvorfor. | Hver runde gir et funn, en endring og en ny test. |
| Kan drive videre selv når oppgaven er uklar. | Stopper ved manglende kontekst, risiko eller manglende framdrift. |
Skriv et mål som en agent faktisk kan arbeide mot
En god GOAL.md er kortere enn en kravspesifikasjon, men mer presis enn en løs prompt. Poenget er ikke å beskrive hver tast agenten skal trykke. Poenget er å beskrive utfallet den kan testes mot.
| Felt i målet | Eksempel for en nettsideoppgave |
|---|---|
| Ønsket resultat | «Forenkle kontaktskjemaet så en mobilbruker kan sende en forespørsel uten å zoome eller lese uklar tekst.» |
| Omfang | «Kun kontaktsiden og tilhørende validering. Ikke endre priser, designprofil eller andre sider.» |
| Ferdigkriterier | «Felter har tydelige etiketter, skjemaet fungerer ved 320 px bredde, og brukeren får en begripelig feilmelding.» |
| Kilder og rammer | «Bruk gjeldende designsystem, eksisterende tekster og testdata. Ikke bruk kundeopplysninger.» |
| Tillatte handlinger | «Opprette egen branch, endre angitte filer og kjøre lokale tester.» |
| Stoppregel | «Stopp etter tre mislykkede testsykluser, ved uklar produktbeslutning eller før deploy.» |
| Eier | «Navngitt ansvarlig person godkjenner endringen og publisering.» |
Denne målbeskrivelsen kan ligge i GOAL.md, i et Paperclip-oppgavekort, i Hermes Kanban eller i hvilken som helst arbeidsflate. Navnet på filen er ikke det viktige. At alle roller deler samme mål og rammer, er viktig.
Slik fungerer en Gauntlet Loop i praksis
Anthropic beskriver evaluator–optimizer som et godt mønster når kriteriene er klare og resultatet faktisk kan forbedres gjennom tilbakemelding. Byggeren lager et forslag. Evaluatoren vurderer det mot forhåndsdefinerte kriterier. Ved «trenger forbedring» får byggeren konkret feedback og prøver igjen. [1]
En enkel Gauntlet Loop trenger ikke mange agenter. To adskilte roller er nok i en første pilot.
| Runde | Rolle | Leveranse |
|---|---|---|
| 1. Les målet | Koordinator eller bygger | Gjentar mål, avgrensning, tillatte verktøy og ferdigkriterier. Stopper hvis noe er uklart. |
| 2. Plan | Bygger | Foreslår små, reverserbare steg og hvilke tester som skal kjøres. |
| 3. Utfør | Bygger | Endrer bare godkjent omfang og lagrer hva som ble gjort. |
| 4. Kontroller | Evaluator/tester | Sjekker mål, tester, tilgjengelighet, sikkerhetskrav og avgrensning. Gir «godkjent», «forbedre» eller «stopp». |
| 5. Forbedre | Bygger | Retter det evaluatoren faktisk fant — ikke tilfeldige nye ideer. |
| 6. Avslutt | Ansvarlig menneske | Godkjenner, ber om ny avklaring eller avslutter uten publisering. |
Det kritiske punktet er kvalitetssperren. Den må ligge utenfor byggerens egen preferanse. En agent som både skriver kode og oppfinner testen den selv består, er ingen pålitelig kontroll. Bruk faste tester, en separat reviewerrolle eller begge deler.
Tre oppgaver som passer for første test
| Oppgave | Hvorfor den passer | Forslag til kvalitetssperre |
|---|---|---|
| Rydde et FAQ-utkast | Målet kan være konkret: dekning, tone, ingen ubegrunnede løfter og riktig språk. | Menneskelig review mot et godkjent spørsmål-/svar-sett. |
| Forbedre en avgrenset nettsidekomponent | Endringen kan kjøres i lokal test og sammenlignes før og etter. | Byggtest, mobiltest, tilgjengelighetssjekk og godkjenning før deploy. |
| Oppsummere en definert dokumentpakke | Kildene kan være kjente, og svaret kan kreve referanser til konkret materiale. | Kontroller at alle påstander kan spores til riktig dokument, dato og side. |
Start ikke med å la en agent gjøre bokføring, sende kundeinformasjon, endre produksjonsinfrastruktur eller ta personalbeslutninger på egen hånd. Slike oppgaver kan få AI-støtte, men kontroll- og ansvarsnivået er høyere enn en enkel første Gauntlet Loop.
Når må agenten stoppe?
At en agent kan arbeide videre mot et mål betyr ikke at den bør få arbeide uten grense. En moden loop har minst fire stoppsignaler.
| Stoppsignal | Hva agenten skal gjøre |
|---|---|
| Målet er nådd | Levere resultat og testspor til godkjenning. Ikke finne nye forbedringer på egen hånd. |
| Ingen framdrift | Etter et avtalt antall forsøk: beskrive hva som feiler, hvilke hypoteser som er testet og hva som må avklares. |
| Ramme er truffet | Stoppe når tidsbudsjett, kostnadsbudsjett, filomfang eller tilgangsgrense er nådd. |
| Risiko eller uklarhet | Eskalere før sensitive data, usikker faglig vurdering, ekstern publisering eller endring med høy konsekvens. |
Dette er det som skiller en kontrollert loop fra en agent som «løper løpsk». Stoppreglene er ikke en svakhet. De gjør resultatet lettere å stole på og enklere å forbedre neste gang.
Selvforbedring uten at reglene flytter seg
En loop kan lære av tidligere feil, men den bør ikke få endre sin egen målkontrakt eller kvalitetsterskel uten separat review. Hvis en test feiler, kan den skrive en læring i en kontrollert fil: hva som gikk galt, hvilken test som fanget det og hva som må sjekkes neste gang.
Den kan for eksempel foreslå en oppdatering i RULES.md eller en testliste. Men endringen bør gå gjennom samme type review som øvrige endringer. Ellers kan en «selvforbedrende» agent bare lære seg å skrive regler som gjør det enklere å bestå.
Anti-Trendslop-skillen har et konkret mønster for eval-drevne loops, progressiv kontekst og regler som ikke skal endres av samme agent som utfører arbeidet.
Gauntlet Loop, Loop Engineering og agentteam
Denne artikkelen er en fordypning av Loop Engineering. Loop Engineering forklarer den bredere ideen om arbeidsflyter som måler, forbedrer og stopper på en forsvarlig måte. Her er fokuset smalere: Et konkret mål og en kvalitetssperre før dere legger på flere roller, verktøy og automatiseringer.
Når én loop fungerer stabilt, kan dere la en tavle synliggjøre arbeid og review, eller en kontrollflate fordele roller og følge kostnad. Når agenter styrer agenter: Paperclip, Hermes Kanban og et lite AI-team forklarer hvordan slike roller kan holdes adskilt. OpenClaw 2 viser hvor et arbeidslag med modeller, minne, kanaler og verktøy kan passe inn.
Den korte oppskriften
Begynn med ett mål dere kan forklare uten AI. Skriv ferdigkriterier, tillatt omfang og stoppsignal før første kjøring. La én rolle bygge og en annen rolle eller test kontrollere. Ta vare på funnene som forbedrer neste runde. La et menneske eie beslutningen når løkken passerer fra forslag til konsekvens.
Da bruker dere /goal til å gi agenten retning, og Gauntlet Loop til å gi den utholdenhet uten å fjerne ansvar.
Kilder
[1] Anthropic Claude Cookbook — Evaluator-Optimizer Workflow
[2] Rakesh Gohel — Loop Engineering, Gauntlet Loops og Graph Engineering
