Hvis du bygger AI-agenter, bygger du loops. Det er ikke et designvalg - det er fysik. Forskellen mellem en agent der virker og en der brænder penge er hvordan du designer det loop.
I december 2024 udgav Anthropic deres guide "Building Effective Agents". Efter at have arbejdet med dusinvis af teams der bygger LLM-agenter, var deres konklusion brutal simpel:
"Agents are typically just LLMs using tools based on environmental feedback in a loop."
Ikke "avancerede multi-agent arkitekturer." Ikke "sofistikerede planlægningsalgoritmer." Bare: LLM + tools + feedback-loop.
De identificerede seks mønstre, og fem af dem er loops:
Prompt chaining - det lineære loop. Et output bliver næste inputs kontekst. Hvert step har en gate der tjekker om vi stadig er på sporet. Det mest stabile mønster.
Evaluator-optimizer - det selv-kritiske loop. En LLM genererer. En anden evaluerer. Loopet fortsætter indtil evaluatoren er tilfreds. Tænk på det som en AI-der-code-reviewer-sig-selv.
Orchestrator-workers - det delegerende loop. En central LLM bryder opgaven ned i delopgaver, sender dem til worker-LLMs, og samler resultaterne. Det mest komplekse - og det dyreste.
Routing - det forgrenede loop. Input klassificeres og sendes til specialiserede workflows. Ikke et loop i sig selv, men hvert workflow er.
Parallelization - når du kører flere loops samtidigt. Enten for at splitte en opgave i uafhængige dele, eller for at få flere perspektiver på det samme problem.
Det sjette mønster - den fuldt autonome agent - er alle fem kombineret.
Her er hvad jeg har lært af at bygge agenter i produktion: loops uden hard stops er farlige.
En agent der kører frit i et "tænk → handl → observer → tænk"-loop uden begrænsninger vil før eller siden:
Jeg byggede mit første agent-loop for tre måneder siden. Det brændte $5 på 20 minutter i en fix → compile error → fix → compile error-spiral. Jeg har siden indbygget tre hårde stops i alle mine loops:
Hvert loop stopper efter N forsøg. Uanset om opgaven er løst eller ej. Jeg sætter typisk N=3 for draft-loops og N=5 for code-loops. Hvis agenten ikke har løst opgaven efter tre forsøg, er det enten fordi opgaven er for svær, eller fordi prompten er for dårlig - og flere tokens ændrer ikke på det.
Hvis scoren ikke forbedres over tre iterationer (delta < 2 point), stoppes loopet. Punktum.
Jeg tracker hver iterations output-kvalitet med eval gates - automatiserede tjek der scorer output på ordantal, struktur, SEO-krav, og sprogkvalitet. Hvis scoren flader ud, er der ingen grund til at fortsætte. Boris Cherny, der designede Hermes Agent-loops, kalder det "no-progress detection." Jeg kalder det "stop med at brænde mine penge."
Hvert loop har et maksimalt token-forbrug. For mit content-loop er det ~150.000 tokens - cirka $0.15 ved DeepSeek-priser. Overskrides budgettet, stoppes loopet - uanset hvor tæt på færdig det var.
Det lyder brutalt. Det er brutalt. Men alternativet er et loop der kører hele natten og efterlader et regning på $30 for et blogindlæg der alligevel ikke er godt nok.
Hvis LLM'er var perfekte, ville ét kald være nok. Du ville sige "skriv en blogpost om loops" og få det færdige resultat.
Men LLM'er er ikke perfekte. De hallucinerer. De overser detaljer. De skriver sætninger der giver mening isoleret men ikke i kontekst. De glemmer instruktioner fra system-prompten efter 10.000 tokens.
Loops løser ikke de problemer - men de gør dem håndterbare. Hver iteration er en chance for at fange fejl, forbedre kvaliteten, og styre mod et bedre resultat.
Min content-loop er bygget præcist sådan: research → 10+ kilder → meta-analyse → draft → fact-check → SEO-validering → publish. Hvert step er en iteration i et større loop. Hvert step har en eval gate. Hvert step har en max-attempts grænse.
Resultatet? Artikler der scorer 85+ på mine SEO-gates, med faktatjekkede kilder og naturligt dansk sprog. Ikke perfekte - men konsekvent bedre end hvad jeg selv ville skrive på samme tid.
Jeg er ikke den eneste der bygger loops.
Ralph (snarktank/ralph, 20.000+ GitHub stars) er en autonom agent der kører i et loop indtil alle PRD-items er fuldført. Den læser produktkrav, implementerer features, kører tests, og itererer baseret på test-resultater.
OpenTracy er en "self-improving AI agent harness" - et evaluator-optimizer loop hvor agenten foreslår ændringer, en eval-suite vurderer dem, og loopet fortsætter indtil kvalitetsmålet er nået.
Claude Code - Anthropics egen coding agent - er i bund og grund et loop: læs kodebasen → forstå opgaven → implementer ændring → kør tests → evaluer resultatet → gentag hvis nødvendigt.
Alle sammen bruger de variationer af det samme mønster. Ingen af dem er "et LLM-kald og så er vi færdige."
Loops har tre primære fejltilstande:
Loop-fiksering. Agenten sidder fast i et lokalt minimum og kan ikke komme videre. Den prøver den samme tilgang igen og igen med små variationer. Løsning: no-progress detection + max iterations.
Error compounding. Små fejl i starten af loopet akkumuleres og forstærker hinanden. Efter 10 iterationer er outputtet værre end efter 2. Løsning: reset-mekanismer og "fresh eyes" evaluator-LLMs.
Context window overload. Loopet tilføjer nyt indhold for hver iteration, men fjerner aldrig noget. Efterhånden som kontekst-vinduet fyldes, forringes LLM'ens evne til at ræsonnere - særligt i midten af vinduet. Løsning: summarization mellem iterationer og bevidst context management.
Da jeg startede med at bygge agenter, troede jeg det handlede om at finde den rigtige prompt. Det gør det ikke.
Det handler om at designe loops der er stabile nok til at køre uden opsyn, men stramme nok til ikke at brænde penge. Det er et optimeringsproblem - ikke et prompt-engineering-problem.
Mit råd til alle der bygger agenter:
Loops er ikke sexede. Der er ingen demo-effekt i "se her, min agent prøvede tre gange og gav så op fordi den ramte sit token-budget."
Men det er den eneste arkitektur der rent faktisk virker i produktion. Alt andet er en demo.
EchoNote bruger AI-agenter til automatisk podcast-transskription. Prøv det på echonote.dk
