De fleste AI-teams, der vil forbedre agenters ydeevne, griber efter de samme håndtag: større kontekstvinduer, flere dokumenter og smartere prompter. Denne artikel argumenterer for, at det er det helt forkerte instinkt. Det, der mangler, er ikke flere oplysninger. Det er styring. Et veldesignet styringslag er det, der adskiller en agent, som virker i en demo, fra en, der virker i produktion.
En større hukommelse, flere dokumenter eller et længere kontekstvindue gør ikke en AI-agent klogere – det gør den blot langsommere og dyrere. De reelle gevinster kommer af at lære agenten at vælge, hvad den har brug for, når den har brug for det, i stedet for at behandle alt på én gang.
Driftssikkerheden kommer fra løkken, ikke modellen. Forskellen mellem en agent, der imponerer i en demo, og en, der holder i produktion, er ikke AI'ens kvalitet, men om systemet kontrollerer sit eget arbejde. Agenter, der planlægger, handler, observerer og verificerer hvert trin, opdager deres egne fejl i stedet for selvsikkert at tage fejl.
De fleste AI-agenter er i dag reelt chatbots med ekstra trin. De har ingen mekanisme til at vide, om de er på rette vej, hvornår de skal stoppe, eller hvornår de bør prøve en anden tilgang. Et ordentligt styringslag – klare succeskriterier, struktureret tilstand og valideringskontroller – forvandler noget, der ligner en agent, til noget, du rent faktisk kan stole på.
Hvad fik du til frokost i går?
Du gennemgik sandsynligvis ikke samtlige minder, du nogensinde har haft, indtil du nåede frem til »i går + frokost«. Du sprang direkte til den del af din erfaring, hvor de begreber hører hjemme. Det er en nyttig tankemodel, når man bygger agenter:
Et enormt kontekstvindue er ikke hukommelse.
En bunke hentede dokumenter er ikke forståelse.
En lang tankerække er ikke driftssikkerhed.
Det er ingredienser. Men det, der får en agent til at føles som en agent, er det samme, som gør, at din hjerne ikke afsøger hele dit livsforløb med rå regnekraft: styring.
En nyere undersøgelse – Agentic Reasoning for Large Language Models – sammenfatter og navngiver på fremragende vis den ændring, som mange af os har mærket under udviklingen: fra ræsonnering inde i modellen til ræsonnering gennem interaktion. Dette indlæg er ikke et resumé af den artikel. Det er et forsøg på at omsætte ændringen til praktisk systemdesign:
Hvis du bygger agenter som chatbots med værktøjer, får du fortsat chatbotfejl – blot med dyrere konsekvenser.
I en periode var vores standardopskrift på at »gøre modellen klogere« grundlæggende: bedre prompter, tankerækker, selvkonsistens eller stikprøvebaserede forbedringer og måske lidt søgning.
ReAct blev et vendepunkt, fordi det fik »tanke → handling → observation« til at virke naturligt. Bemærk dog den implicitte begrænsning: Meget af dette ender stadig som »one-shot-inferens, men med flere tokens«. Undersøgelsens formulering er skarpere: Agentbaseret ræsonnering lægger vægt på at skalere interaktion på testtidspunktet – altså at gøre inferens til en iterativ proces, hvor modellen, hukommelsen og miljøet alle forbliver i løkken.
Hvis du har bygget eller brugt agenter, der virker imponerende i demoer, men er skrøbelige i virkelige arbejdsgange, er dette noget for dig.
Lad mig beskrive et mønster, jeg ofte har set – og bestemt også selv har bygget varianter af:
Tag en god chatmodel
Tilføj nogle værktøjer (søgning, databaseforespørgsler og måske kodekørsel)
Tilføj RAG
Tilføj systemprompten “you are an autonomous agent”
Pak det hele ind i en while-løkke, indtil den stopper eller får timeout
Tillykke, du har noget, der ligner en agent. Men det fejler ofte på forudsigelige måder:
Oppustet kontekst: Hver observation tilføjes, og prompterne bliver til arkæologiske lag.
Planløs brug af værktøjer: »forkert værktøj, men brugt med stor selvsikkerhed« bliver standardfejlen.
Ingen stopbetingelser: Den fortsætter, fordi den kan, ikke fordi den bør.
Ingen disciplineret forankring: Den opdager ikke, at den tager fejl, medmindre du tvinger den til det.
Hukommelse = chathistorik: Det svarer i bund og grund til at skrive logfiler og kalde det læring.
Derfor virker »agenter« ofte magiske i demoer og kaotiske i produktion. Vores erfaring med at sætte agentbaserede systemer i produktion afspejler også dette: Når du ikke længere evaluerer en model, men et system, omfatter fejltyperne navigation, disciplineret brug af værktøjer, beskæring af kontekst og design af evalueringer – ikke kun »svarede modellen korrekt?«
Spørgsmålet bliver derfor: Hvad er den målrettede agent?
For at gøre det mindre abstrakt får du her et enkelt eksempel på en arbejdsgang, som de fleste kan forestille sig: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
En typisk implementering, der ligner en agent, ser sådan ud:
Henter straks en masse dokumenter om flyselskabers og rejseudbyderes politikker, selvom de endnu ikke er nødvendige.
Kalder et søgeværktøj, indsætter en lang liste med resultater i prompten og »vælger ét«.
Bestiller for tidligt uden at kontrollere begrænsningerne (ankomsttid, bagage, sæde og politikker).
Hvis det mislykkes, prøver den igen på en lidt anden måde – men uden en klar forståelse af, hvad der ændrede sig, eller hvad den lærte.
Problemet er ikke, at modellen ikke kan ræsonnere, men at systemet ikke styrer arbejdsgangen.
En mere agentbaseret version behandler opgaven som en interaktiv proces med eksplicit tilstand og eksplicitte kontroller:
PLANLÆG: Gentag begrænsningerne, og angiv manglende oplysninger (f.eks. “which airport preference?” / “is 1 stop ok?”).
HANDL: Kald flysøgningen med en struktureret forespørgsel (datointerval, krav til ankomst og budget).
OBSERVÉR: Gem resultaterne i et kompakt tilstandsobjekt (de fem bedste kandidater med pris, ankomst og mellemlandinger) i stedet for en enorm indsat tekstblok.
OPDATER: Justér forespørgslen, hvis kravene ikke opfyldes (f.eks. “arrival before 6pm is too strict—widen time window or raise budget?”).
VERIFICÉR: Kør validatorer (»ankomst < 18.00«, »pris ≤ 900 £«, »overholder politikker«, »sædevalg tilgængeligt«).
STOP: Først når booking-API'en returnerer en bekræftelse, og alle validatorer godkender.
Ændringen er subtil, men afgørende. Hentning sker efter behov, ikke per automatik. Konteksten styres – tilstanden struktureres frem for at hobe sig op – og verifikation indgår i løkken i stedet for at blive overladt til brugeren. Erstat »bestilling af en flyrejse« med »oprettelse af en indkøbsordre«, »udstedelse af en refundering«, »ændring af en produktionskonfiguration« eller »levering af en PR«, og pointen er den samme: Når agenten kan handle, er løkken vigtigere end prompten.
Ovennævnte undersøgelse opdeler agentbaseret ræsonnering i tre lag: et grundlæggende lag (planlægning, brug af værktøjer og søgning), et selvudviklende lag (feedback og hukommelse) og et kollektivt lag (koordinering mellem flere agenter).
Den dybere pointe er dog, at ræsonnering bliver det organiserende princip for planlægning, beslutningstagning og verifikation – ikke blot for at generere en plausibel tankerække. Det lyder abstrakt, indtil du omsætter det til ændringer i din arkitektur. Der er tre centrale pointer at huske:
En god agent bør ikke behandle hentning som noget, der »altid skal gøres«. Hentning er en beslutning, ikke en refleks.
Her er en praktisk tommelfingerregel:
Hvis dit system henter noget i hver tur, har du ikke bygget et hentningssystem – du har indført en kontekstafgift.
Det ses hele tiden i praksis. Når du fejlfinder en produktionshændelse, fylder du ikke konteksten med alle logfiler. Du beslutter ud fra din aktuelle hypotese, hvilke målinger og logfiler der skal hentes som de næste. Det er »agentbaseret hentning«. Her er et mere konkret mønster:
Afgør, om du har brug for at hente noget
Hvis ja: Formulér en forespørgsel, hent, skumlæs og udtræk
Hvis dokumentationen er modstridende: Hent igen
Sammenfat først derefter
Det er også her, »agentbaseret RAG« begynder at adskille sig fra traditionel RAG: Hentning bliver et bevidst ræsonneringstrin og ikke et standardtrin i pipelinen.
I det øjeblik du holder op med at evaluere »en model« og begynder at evaluere »et system«, bliver registrering og sporing af tilstanden vigtigt.
Branchen er efterhånden blevet mere bevidst om observerbarhed i agentarbejdsgange. OpenAI's Agents SDK har eksempelvis indbygget sporing og et Traces-dashboard, der registrerer agentkørsler (genereringer, værktøjskald, overdragelser, sikkerhedsforanstaltninger og brugerdefinerede hændelser), så du trin for trin kan fejlfinde og revidere, hvad der skete.
Det er ikke bare »rart at have«. Det er forskellen på et system, du kan fejlfinde, og et system, du kun kan vurdere på mavefornemmelsen.
Efter min mening er undersøgelsens mest handlingsanvisende del dens direkte tilgang til feedback. Den opdeler feedback i tre former: refleksiv feedback (generér → kritisér → revider), parametrisk tilpasning (læring via finjustering/RL) og validatordrevet feedback (prøv igen, indtil en validator godkender).
De fleste teams bør begynde med validatordrevet feedback, fordi det er kedeligt og effektivt. Hvis du kan skrive en hvilken som helst validator, der udfører enhedstest, kontrollerer et skema, håndhæver forretningsregler/begrænsninger (»ingen refunderinger over X uden eskalering«) eller sikrer faktuel korrekthed (»kildehenvisninger påkrævet«), kan du gøre ikke-deterministisk modeloutput til noget, du rent faktisk kan stole på.
En af de uforudsete ændringer her er enkel: I agentverdenen kommer driftssikkerhed ofte mere fra løkken end fra modellen.
Her er den enkleste løkkedisciplin, jeg har fundet, som pålideligt forbedrer adfærden uden træning:
Arbejd trinvist: Planlæg → Handl → Observér → Opdater,
Opsummér observationen i 1-3 punkter efter hver handling,
Stop, når succeskriterierne er opfyldt, eller budgettet er brugt. Returnér det bedste kendte resultat og de resterende usikkerheder.
Det handler ikke om at få modellen til at bruge flere ord. Det handler om at gøre systemet forståeligt og fremtvinge »kontakt med virkeligheden« ved hvert trin. Et eksempel, som mange udviklere kan genkende, er forankring i et lukket kredsløb som i CI:
Planlæg: Foreslå en liste over ændringer
Handl: Kør test/linting
Observér: Analysér fejl
Opdater: Ret og prøv igen
Her er nogle spørgsmål, der ofte afslører utilsigtede agentdesign:
»Vælger min agent, hvad den skal hente, eller henter jeg altid noget?«
Hvis hentningen sker ubetinget, betaler du med længere svartid, højere omkostninger, udvandet kontekst og større risiko for princippet »skidt ind, skidt ud«.
»Kan min agent opdage, at den tager fejl?«
Hvis din agents eneste feedbacksignal er, at »brugeren bliver irriteret«, udfører du RL ved at udsætte mennesker for frustration. En validatordrevet løkke med nye forsøg er den enkleste måde at give den et realitetstjek på.
»Kan der skrives til hukommelsen, og bliver den bedre med tiden?«
Hvis din »hukommelse« blot tilføjer chathistorik, skriver du i bund og grund logfiler. Undersøgelsens beskrivelse af hukommelse er vigtig: Hukommelsen bliver en dynamisk voksende kontekst, som agenter forfiner med tiden – ikke bare en udskrift.
Logfiler fortæller, hvad der skete, mens hukommelsen fortæller, hvad du skal gøre næste gang. Chathistorik er en udskrift. Hukommelse er en løbende udviklet politik for, hvad der er værd at tage med videre.
Et praktisk udgangspunkt er en lille tabel med »indhøstede erfaringer«, ordnet efter opgavetype, værktøj og fejltype samt oplysninger om, hvad der virkede, og hvad man bør undgå. Målet er ikke at bygge en perfekt vidensgraf. Målet er at skabe en selvforstærkende adfærd: Hukommelse og feedback forvandler agenter fra »tilstandsløse hjælpere« til systemer, der bliver bedre med tiden.
Det er fristende at sætte flere agenter på problemet, men det mangedobler ofte omkostningerne ved koordinering. Et godt mønster for et »levedygtigt minimumsteam«:
Koordinator: opdeler og fordeler
Udfører: foretager værktøjskald og ændringer
Kritiker/evaluator: kontrollerer korrekthed og risiko
Hukommelsesansvarlig: skriver og kuraterer erfaringer
Hvis du ikke kan forklare, hvad hver agent har ansvaret for, har du sandsynligvis ikke brug for flere agenter endnu.
Hvis vi virkelig accepterer paradigmeskiftet, holder vi sandsynligvis op med at proppe alt ind i prompter, behandle fejl som endelige resultater og evaluere agenter som chatbots. Og vi begynder at behandle agenter som det, de er: softwaresystemer, hvor sproget er kontrolplanet – og driftssikkerheden kommer fra løkken.
Tilføj endnu en evalueringsløkke, før du tilføjer endnu en model. Gør hentning betinget, før du henter alt. Sæt én validator i drift, før du sætter ti i drift. Behandl hukommelse som politiske beslutninger, ikke som en database. Og når du går over til flere agenter, så begynd med to agenter – ikke tyve. Det er ikke regler, men de mønstre, der har bestået produktionens prøve.