Sådan vælger du det rigtige agent-mønster til din AI
En kompakt håndbog fra Sachin Anand på Towards AI kortlægger 11 designmønstre til agentiske AI-systemer og grupperer dem i fire overordnede kategorier. Det lyder enkelt, men adresserer et reelt behov: konkrete valg, som udviklingsteams kan træffe uden at fare vild i hype. Start simpelt, vælg arkitektur efter opgaven, og læg styring ind fra dag ét. Kilden beskriver eksplicit “11 patterns, grouped into 4 categories” og taler direkte til beslutningstagere, der vil operationalisere agent-teknologi.
Relevansen for danske virksomheder er lige ud ad landevejen. Mange pilotprojekter lander tungere, dyrere og mere ustabile end nødvendigt. Rammeværket flytter fokus tilbage til forretningsprocessen og de tekniske begrænsninger — ikke omvendt.
Hvorfor det betyder noget nu
Agentiske systemer bevæger sig ind i hverdagsopgaver: dataopsamling på tværs af kilder, klargøring af indhold, kvalitetstjek og routing mellem specialiserede del-opgaver. Stærkere sprogmodeller og bedre værktøjer frister til “mere autonomi”. Det kan blive dyrt. Og langsomt. Anands artikel behandler mønstre som genanvendelige arkitekturgreb — ikke endnu en idé om “magiske” agenter.
Mønstertankegangen flugter med den praktiske AI-engineering-litteratur, som lægger vægt på workflows, test-harnesses og monitorering i drift. Bogen “AI Engineering For Production” (planlagt lancering 20. oktober) lover netop kapitler om workflows, agenter og de “harnesses that hold everything together”.
De fire spørgsmål du skal stille først
Anand lægger en firepunkts-check foran alle arkitekturvalg. Før man vælger mønster, spørg om: 1) opgaven er foruddefineret eller åben, 2) latenstidskrav, 3) om budgettet kan bære flere modelkald pr. request, og 4) om der er behov for menneskelig sign-off ved højrisiko eller subjektive beslutninger. Ordene står så klart i kilden, at det nærmest fungerer som en tavlenote til sprintplanlægningen.
Det her konverterer ambition til prioritering: hvad må svarets hastighed koste, hvor skal kvalitetssikringen ligge, og hvornår skal et menneske trykke “godkend”. En vigtig detalje: listen står før mønstrene — som en bremse.
Oversigt over 11 mønstre og 4 kategorier
Artiklen grupperer mønstrene i fire kasser: Core flow, Loop patterns, Coordination patterns og en blandet gruppe med komposit/andre. Den eksplicitte optælling er 11 mønstre i alt, og for hvert introduceres en kort anvendelseslogik. Kilden henviser også til simple diagrammer, hvor A, B, C markerer delopgaver eller agenter i kæden. Det gør forskellen mellem sekvens og parallel let at aflæse.
Kort katalog, én linje pr. mønster, som det fremgår i stoffet: Core flow rummer Single, Sequential, Parallel. Loop patterns dækker Loop, Generator–Critic og Iterative Refinement. Coordination handler om en koordinator, der dirigerer underagenter og ruter forespørgsler til specialister; diagrammet viser en rod-koordinator over underagenter og deres delopgaver. Den sidste gruppe samler sammensatte/andre mønstre, der typisk kombinerer elementer fra de tre første kategorier. Konkrete case-eksempler ville gøre overblikket endnu stærkere.
Core flow i praksis
Kernen er de tre “flow”-valg. Single, Sequential og Parallel giver et klart sprog for latency og pris. Kilden er tydelig: “Start with this pattern” om Single, og skru først op, når behovet viser sig.
Pseudokoden i artiklen illustrerer forskellene:
# Runs each agent in order: Research finishes, then Draft, then Review
SequentialAgent(sub_agents=[ResearchAgent, DraftAgent, ReviewAgent])
# Runs all three agents at the same time, then combines their results
ParallelAgent(sub_agents=[Source1Agent, Source2Agent, Source3Agent])
Hvornår Single, hvornår mere
Single bruger én agent med ét modelkald og ét sæt værktøjer. Forudsigeligt, billigt, velegnet til deterministiske skridt. Sequential lægger skridt oven på hinanden, når rækkefølgen betyder noget — total svartid bliver summen af alle trin. Parallel stykker input sammen fra flere uafhængige kilder — samlet latency nærmer sig den langsomste gren, men modelkald flerdobles.
Tradeoff’et er klart: Parallel kan vinde svartid i brede søgninger, men budgettet løber hurtigt. Sequential holder orden, men føles langsomt for brugeren. Single er baseline. Det overraskede mig lidt, hvor ofte Single rækker, når kravene er skåret rigtigt til — alligevel bygger mange for meget, for tidligt.
Loop og iteration uden runaway-omkostninger
Artiklen beskriver tre loop-mønstre: Loop, Generator–Critic og Iterative Refinement. Fællesnævneren er gentagelse, til kvaliteten er høj nok — men med hegnspæle. “Always set max_iterations. Do not run a loop without a limit.” Det er både et kvalitets- og budgetråd.
Eksempel fra teksten:
# Repeats RefineAgent’s task up to 5 times, then stops even if not perfect
LoopAgent(sub_agent=RefineAgent, max_iterations=5)
Hvornår de tre loop-varianter giver mening
Loop egner sig, når en enkelt agent kan forfine output med en klar stopbetingelse. Generator–Critic adskiller skabelse og evaluering i to agenter, så kritikeren eksplicit måler kvalitet. Iterative Refinement binder en kvalitetsmåling på hver iteration — stop, når tjekket passerer, eller når loftet nås. Uden målbare kriterier kører man i ring og betaler for det.
Driftskonsekvensen er tydelig: definer exit-kriterier, sørg for observabilitet af iterationer, og sæt cost-guardrails — ellers eksploderer regningen uden tilsvarende forbedring af output.
Modularitet og observation–action-cyklus
Artiklen og den korte manual-kommentar, der ledsager læsningen, er samstemmende om to grundelementer: modulopbygning og observation–action-cyklusser. Modulopbygning gør agenter testbare og udskiftelige. Observation–action (sans, beslut, udfør, observer igen) giver naturlige steder at måle, logge og — når det er nødvendigt — indsætte et menneske i løkken.
I drift betyder det, at man kan indføre audits, versionere delagenter og rulle tilbage uden at demontere hele stakken. Og observation–action-mønstret gør det nemt at sætte breakpoints for kvalitet eller compliance.
Koordination og routing i virkeligheden
Koordinationsmønstret lader en “root”-agent styre underagenter og uddelegere delopgaver. Kilden illustrerer med et diagram, hvor rod-koordinatoren ruter til specialister. I praksis er det ofte sådan, man kobler kundeservice, fakturering eller databerigelse på én indgang uden at blande opgaverne sammen.
Grænsen er skarp: Koordination giver overblik og styrbarhed, men lægger også latency ovenpå, fordi forespørgsler skal triageres. Overvej caching af routing-beslutninger og fallback-regler, så fejl i en underagent ikke kaskaderer ud i hele flowet.
Første filter før alt andet
Anand er klar i spyttet: “If a single AI model call can do the job, skip agents entirely.” Det er både et budget- og stabilitetsråd. Ét velspecificeret modelkald med et godt prompt, måske et retrieval-trin, leverer ofte hurtigere og med færre fejlkilder.
For ingeniører betyder det færre komponenter at holde i live og mindre observabilitetsgæld. For forretningen: kortere time-to-value og tættere kobling til et enkelt workflow. Ulempen er risikoen for at undervurdere fremtidige behov og ende med en for lille arkitektur — men den risiko er ofte billigere end at bygge et agent-slotcar fra dag ét.
Drift, sikkerhed og tilsyn
AI-engineering-litteraturen, herunder den varslede bog “AI Engineering For Production”, peger på værktøjer omkring modellerne: harnesses, evaluering, monitorering og deployments. Det er her mønstrene bider i virkeligheden. Et Loop-mønster uden monitorering er en regning uden loft. Et Coordinator-mønster uden auditlogs giver gråzoner ved tilsyn.
For governance er mønstre nyttige, fordi de placerer kontrolpunkter: menneskelig sign-off hvor beslutningen er højrisiko, versionering og audit på modulniveau, logging af observation–action-overgange. I brancher med stærke krav — finans, sundhed, offentlig sektor — kan det være forskellen på godkendt og afvist.
Latency, pris og autonomi
Antag tre delopgaver med ca. 1 sekund modeltid og lige så meget værktøjsventetid pr. trin. Sequential vil typisk lande omkring summen, altså 3 sekunder plus overhead. Parallel samler de tre på den langsomste gren, fx 1–1,5 sekund, men tredobler modelkald (og dermed pris). Single er 1 kald og én svartid på ca. 1 sekund — hvis opgaven kan koges ned til ét veldefineret skridt.
For SLA’er betyder det, at Parallel vinder på svartid i brede dataindsamlinger, men taber på kroner. Sequential vinder på orden og sporbarhed. Single vinder på enkelhed. Beslutningen havner direkte i brugeroplevelsen og budgettet.
Implementeringscheckliste
- Start med Single. Bevis at ét kald ikke er nok, før du eskalerer.
- Instrumentér observation–action-trin. Log før og efter værktøjsopslag.
- Sæt maks-forsøg på alle loops. Definér exit-kriterier med tal.
- Brug Generator–Critic, når kvalitet kan måles af en separat agent (tests, regler, scoringsmodeller).
- Paralleliser kun uafhængige skridt, og budgettér for ekstra modelkald.
- Planlæg menneskelig sign-off hvor beslutningen er høj-stakes eller subjektiv.
- Etabler monitorering og regressionstests, så mønstervalg ikke forringes i drift.
Et blik uden for software
Toyota har ifølge rapportering over for investorer luftet et estimat om cirka 400.000 robotter og årlige udgifter omkring 1 billion yen (omtrent 6,4 milliarder dollar) fra 2028 for at udvide fabriksautomatisering. Det er et estimat, ikke en beslutning. Men signalet er klart: når automatisering skalerer fysisk, stiger kravene til designmønstre, koordination og driftssikkerhed tilsvarende. Samme arkitekturtænkning efterspørges i software-agenter — bare uden skæreolie og stålsplinter.
Pointen er omfanget: store automatiseringsbølger kræver klare mønstre, styring og ansvarskæder. Software slipper ikke udenom.
Hvad artiklen ikke siger
Der mangler stadig mursten i dokumentationen. For det første: flere case-eksempler fra produktion, hvor de 11 mønstre er brugt med målbar effekt. For det andet: originale diagrammer i høj opløsning og evt. referenceimplementeringer. For det tredje: skarpe, kvantitative estimater for omkostningsprofiler i Sequential vs Parallel vs Loop (modelkald pr. brugerflow, ikke bare intuition).
Derudover ville interviews med forfatteren og andre praktikere klæde diskussionen om, hvor ofte rådet “spring agenter over hvis ét kald virker” faktisk forkorter time-to-value i praksis. Og endelig: branchespecifik governance i fx finans og sundhed kræver mere dybde, også om GDPR, auditerbarhed og ansvar.
Faktatjek og kilder
Hovedpåstanden om “11 mønstre i 4 kategorier” fremgår eksplicit hos Anand på Towards AI, sammen med definitionen af agent-designmønstre som genanvendelige arkitekturtilgange og egnethed til åbne, flertrins-opgaver med realtidsadgang til eksterne kilder. Samme artikel oplister de fire forberedende spørgsmål (opgavetype, latency, cost, human sign-off) og anbefalingen om at springe agenter over, hvis ét modelkald kan løse opgaven.
Det eksterne perspektiv fra “AI Engineering For Production” understøtter betydningen af workflows, agenter og de “harnesses” der binder systemerne sammen i produktion. Lanceringsdatoen oplyses som 20. oktober på bogens side; der står samtidig “Available now”, hvilket giver en mindre tidslig uklarhed — lanceringstidspunkt bør bekræftes. Toyota-estimatet om robotter og udgifter refereres via branchemedie med henvisning til tidligere Reuters-dækning; det er markeret som estimat, ikke igangsat program.
Konklusion
Rådet er kort: vælg det mindste mønster, der løser det rigtige problem. Start med Single. Brug Sequential når rækkefølgen er nødvendig. Brug Parallel, når kilderne er uafhængige og tiden er knap — og du kan betale for det. Loop kun med målbare kvalitetskriterier og hårde stop.
Det er ikke teori for teorien skyld. Det er drift.
