De fleste AI-team som vil forbedre agentytelsen, griper til de samme virkemidlene: større kontekstvinduer, flere dokumenter og smartere prompter. Denne artikkelen hevder at det er helt feil instinkt. Det som mangler, er ikke mer informasjon. Det er styring. Et godt utformet styringslag skiller en agent som fungerer i en demo, fra en som fungerer i produksjon.
En AI-agent blir ikke smartere av å få større minne, flere dokumenter eller et lengre kontekstvindu – den blir bare tregere og dyrere. Den virkelige gevinsten kommer når agenten lærer å velge hva den trenger, når den trenger det, i stedet for å ta inn alt på én gang.
Påliteligheten kommer fra sløyfen, ikke modellen. Forskjellen på en agent som imponerer i en demo, og en som holder mål i produksjon, er ikke kvaliteten på AI-en – det er om systemet kontrollerer sitt eget arbeid. Agenter som planlegger, handler, observerer og verifiserer i hvert trinn, oppdager egne feil i stedet for å ta feil med stor selvsikkerhet.
De fleste AI-agenter i dag er i praksis chatboter med ekstra trinn. De mangler mekanismer for å vite om de er på rett spor, når de bør stoppe, eller når de bør prøve en annen tilnærming. Et ordentlig styringslag – tydelige suksesskriterier, strukturert tilstand og valideringskontroller – gjør en agentlignende konstruksjon til noe du faktisk kan stole på.
Hva spiste du til lunsj i går?
Du spilte sannsynligvis ikke av alle minnene du noen gang har hatt, til du traff «i går + lunsj». Du gikk rett til den delen av erfaringen din der disse begrepene hører hjemme. Det er en nyttig mental modell når du bygger agenter:
Et enormt kontekstvindu er ikke et minne.
En haug med innhentede dokumenter er ikke forståelse.
En lang tankerekke er ikke det samme som pålitelighet.
Dette er ingredienser. Men det som får en agent til å føles som en agent, er det samme som gjør at hjernen din ikke råsøker gjennom hele livshistorien din: styring.
En nyere undersøkelse – Agentic Reasoning for Large Language Models – oppsummerte (og satte navn på) et skifte mange av oss har merket mens vi bygger: fra resonnering inne i modellen til resonnering gjennom samhandling. Dette innlegget er ikke et sammendrag av artikkelen. Det er et forsøk på å omsette skiftet til praktisk systemdesign:
Hvis du bygger agenter som chatboter med verktøy, får du fortsatt chatbotenes feilmoduser – bare med dyrere feil.
En stund var standardoppskriften vår for å «gjøre modellen smartere» i praksis bedre prompter, tankerekke, forbedringer gjennom selvkonsistens eller utvalgsbaserte metoder, og kanskje litt søk.
ReAct ble et vendepunkt fordi «tanke → handling → observasjon» begynte å føles naturlig. Men legg merke til den underforståtte begrensningen: Mye av dette ender fortsatt som «one-shot-inferens, bare med flere tokener». Undersøkelsen formulerer det skarpere: Agentbasert resonnering legger vekt på å skalere samhandlingen under kjøring – å gjøre inferens til en iterativ prosess der modellen, minnet og miljøet hele tiden inngår i sløyfen.
Hvis du har bygget (eller brukt) agenter som virker imponerende i demoer, men skjøre i reelle arbeidsflyter, er dette for deg.
La meg beskrive et mønster jeg har sett ofte (og definitivt selv har bygget varianter av):
Ta en god chatmodell
Legg til noen verktøy (søk, databasespørring og kanskje kjøring av kode)
Legg til RAG
Legg til systemprompten «you are an autonomous agent»
Pakk alt inn i en while-løkke til den stopper eller får tidsavbrudd
Gratulerer, du har en agentlignende konstruksjon. Men den svikter gjerne på forutsigbare måter:
Oppblåst kontekst: Hver observasjon legges til, og promptene blir til arkeologiske lag.
Vingling mellom verktøy: «feil verktøy, men med stor selvsikkerhet» blir standardfeilen.
Ingen stoppvilkår: Den fortsetter fordi den kan, ikke fordi den bør.
Ingen disiplinert forankring: Den oppdager ikke at den tar feil, med mindre du tvinger den til det.
Minne = chatlogg: Det er i praksis å skrive logger og kalle det læring.
Derfor virker «agenter» ofte magiske i demoer og rotete i produksjon. Vår erfaring med å sette agentbaserte systemer i produksjon gjenspeiler også dette: Når du ikke lenger evaluerer en modell, men et system, omfatter feilmodusene navigasjon, ryddig verktøybruk, beskjæring av kontekst og utforming av evalueringer – ikke bare «svarte modellen riktig?»
Da blir spørsmålet: Hvordan ser den målrettede agenten ut?
For å gjøre dette mindre abstrakt kan vi se på en enkel arbeidsflyt de fleste kan forestille seg: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
En vanlig implementering som «ligner en agent», ser slik ut:
Henter umiddelbart en rekke dokumenter om flyselskaper og reiseregler (selv om ingen av dem trengs ennå).
Kaller et søkeverktøy, limer inn en lang resultatliste i prompten og «velger ett».
Bestiller for tidlig uten å kontrollere begrensningene (ankomsttid, bagasje, sete og regler).
Hvis den mislykkes, prøver den på nytt på en litt annen måte – men uten noen klar forståelse av hva som ble endret, eller hva den lærte.
Problemet er ikke at modellen ikke kan resonnere, men at systemet ikke styrer arbeidsflyten.
En mer agentbasert versjon behandler oppgaven som en interaktiv prosess med eksplisitt tilstand og kontrollpunkter:
PLANLEGG: Gjenta begrensningene og oppgi manglende informasjon (f.eks. “which airport preference?” / “is 1 stop ok?”).
UTFØR: Kall flysøket med en strukturert spørring (datointervall, ankomstkrav og budsjett).
OBSERVER: Lagre resultatene i et kompakt tilstandsobjekt (de fem beste alternativene med pris, ankomst og mellomlandinger), ikke som en enorm innlimt tekstblokk.
OPPDATER: Finjuster spørringen hvis begrensningene ikke oppfylles (f.eks. “arrival before 6pm is too strict—widen time window or raise budget?”).
VERIFISER: Kjør validatorer («ankomst < 18:00», «pris ≤ £900», «i samsvar med reglene», «setevalg tilgjengelig»).
STOPP: Først når bestillings-API-et returnerer en bekreftelse og alle validatorene godkjenner.
Endringen er subtil, men avgjørende. Innhentingen er betinget (ikke en refleks), konteksten styres (tilstanden struktureres fremfor å hope seg opp), og verifisering er en del av sløyfen (ikke overlatt til brukeren). Bytt ut «bestille en flyreise» med «opprette en innkjøpsordre», «utstede en refusjon», «endre et produksjonsoppsett» eller «levere en PR», så er historien den samme: Når agenten kan handle, betyr sløyfen mer enn prompten.
Undersøkelsen nevnt ovenfor deler agentbasert resonnering inn i tre lag: grunnleggende (planlegging, verktøybruk og søk), selvutviklende (tilbakemelding og minne) og kollektivt (samordning mellom flere agenter).
Men den dypere ideen er at resonnering blir det organiserende prinsippet for planlegging, beslutninger og verifisering – ikke bare for å generere en plausibel tankerekke. Det høres abstrakt ut helt til du ser hva det innebærer for arkitekturen. Det er tre hovedpunkter å huske:
En god agent bør ikke behandle innhenting som noe som «alltid skal gjøres». Innhenting er en beslutning, ikke en refleks.
Her er en praktisk tommelfingerregel:
Hvis systemet ditt henter informasjon i hver runde, har du ikke bygget innhenting – du har innført en kontekstavgift.
Dette ser vi hele tiden i reelt arbeid. Når du feilsøker en produksjonshendelse, dumper du ikke alle loggene inn i konteksten. Du avgjør hvilke målinger og logger som skal hentes videre, ut fra hypotesen du har nå. Det er «agentbasert innhenting». Her er et mer konkret mønster:
Avgjør om du trenger innhenting
Hvis ja: Utform en spørring, hent, skumles og trekk ut
Hvis bevisene er motstridende: Hent på nytt
Først da sammenfatter du
Det er også her «agentbasert RAG» begynner å skille seg fra tradisjonell RAG: Innhenting blir et bevisst trinn i resonneringen, ikke et standardtrinn i kjeden.
I det øyeblikket du slutter å evaluere «en modell» og begynner å evaluere «et system», blir sporing av tilstand og hendelsesforløp viktig.
Én ting bransjen nå har blitt tydeligere på, er observerbarhet i agentarbeidsflyter. OpenAIs Agents SDK leveres for eksempel med innebygd sporing og et Traces-instrumentpanel som registrerer agentkjøringer (genereringer, verktøykall, overleveringer, sikkerhetsmekanismer og egendefinerte hendelser), nettopp slik at du kan feilsøke og revidere hendelsesforløpet trinn for trinn.
Det er ikke bare «kjekt å ha». Det er forskjellen på et system du kan feilsøke, og et system du bare kan magefølelsesteste.
Etter min mening er den mest handlingsrettede delen av undersøkelsen hvor tydelig den er om tilbakemeldinger. Den deler tilbakemeldinger inn i tre kategorier: reflekterende tilbakemelding (generer → vurder → revider), parametrisk tilpasning (lær gjennom finjustering/RL) og validatorstyrt tilbakemelding (prøv på nytt til en validator godkjenner).
De fleste team bør begynne med validatorstyrt tilbakemelding fordi det er kjedelig og effektivt. Hvis du kan skrive en hvilken som helst validator som kjører enhetstester, kontrollerer skjemaet, håndhever forretningsregler og begrensninger («ingen refusjoner over X uten eskalering») eller fastslår faktagrunnlaget («kilder kreves»), kan du gjøre ikke-deterministiske modellresultater til noe du faktisk kan stole på.
Et av de uforutsette skiftene her er enkelt: I agentverdenen kommer pålitelighet ofte mer fra sløyfen enn fra modellen.
Dette er den enkleste sløyfestrukturen jeg har funnet som gir pålitelig bedre atferd uten trening:
Arbeid trinnvis: Planlegg → Utfør → Observer → Oppdater,
Etter hver utførelse oppsummerer du observasjonen i 1–3 punkter,
Stopp når suksesskriteriene er oppfylt eller budsjettet er brukt opp. Returner beste kjente resultat og gjenværende usikkerhet.
Dette handler ikke om å få modellen til å bruke mange ord. Det handler om å gjøre systemet forståelig og tvinge frem «kontakt med virkeligheten» i hvert trinn. Et eksempel mange utviklere vil kjenne seg igjen i, er forankring i en lukket sløyfe etter CI-prinsippet:
Planlegg: foreslå en liste over endringer
Utfør: kjør tester/linting
Observer: analyser feil
Oppdater: rett og prøv på nytt
Her er noen spørsmål som ofte avslører utilsiktede agentutforminger:
«Velger agenten min hva som skal hentes, eller henter jeg alltid noe?»
Hvis innhenting skjer ubetinget, betaler du med lengre ventetid, høyere kostnader, utvannet kontekst og større risiko for «søppel inn, søppel ut».
«Kan agenten min oppdage at den tar feil?»
Hvis agentens eneste tilbakemeldingssignal er «brukeren blir irritert», driver du med RL gjennom menneskelig lidelse. En validatorstyrt sløyfe med nye forsøk er den ryddigste måten å gi agenten en realitetssjekk på.
«Kan det skrives til minnet, og blir det bedre over tid?»
Hvis «minnet» ditt bare utvider chatteloggen, skriver du i praksis bare logger. Undersøkelsens fremstilling av minne er viktig: Minne blir en dynamisk voksende kontekst som agenter forbedrer over tid – ikke bare en utskrift av samtalen.
Logger forteller hva som skjedde, mens minnet forteller hva du bør gjøre neste gang. Chatloggen er en utskrift av samtalen. Minne er en praksis i utvikling for hva det er verdt å ta med videre.
Et praktisk utgangspunkt er en liten tabell over erfaringer, organisert med oppgavetype, verktøy og feilmodus som nøkkel og hva som fungerte og bør unngås som verdi. Poenget er ikke å bygge en perfekt kunnskapsgraf. Poenget er å skape en selvforsterkende effekt: Minne og tilbakemeldinger gjør agenter om fra «tilstandsløse hjelpere» til systemer som blir bedre over tid.
Det er fristende å sette flere agenter på problemet, men det øker ofte samordningsarbeidet tilsvarende. Et godt mønster for et «minste levedyktig team»:
Koordinator: deler opp og fordeler
Utfører: foretar verktøykall og endringer
Kritiker/evaluator: kontrollerer riktighet og risiko
Minneforvalter: skriver og redigerer erfaringer
Hvis du ikke kan forklare hva hver agent har ansvar for, trenger du sannsynligvis ikke flere agenter ennå.
Hvis vi faktisk godtar paradigmeskiftet, slutter vi sannsynligvis å stappe alt inn i prompter, behandle feil som endelige resultater og evaluere agenter som chatboter. I stedet begynner vi å behandle agenter som det de er: programvaresystemer der språket er styringsplanet – og påliteligheten kommer fra sløyfen.
Før du legger til enda en modell, bør du legge til enda en evalueringssløyfe. Før du henter alt, bør du gjøre innhentingen betinget. Lever én validator før du leverer ti. Behandle minnet som beslutninger om praksis, ikke som en database. Og når du går over til flere agenter, bør du begynne med to, ikke tjue. Dette er ikke regler, men mønstrene som overlevde møtet med produksjon.