De flesta AI-team som vill förbättra Agent-prestandan använder samma verktyg: större kontextfönster, fler dokument och smartare prompter. Den här artikeln hävdar att det är helt fel instinkt. Det som saknas är inte mer information. Det är styrning. Ett väl utformat styrskikt skiljer en Agent som fungerar i en demo från en som fungerar i produktion.
En AI-Agent blir inte smartare av ett större minne, fler dokument eller ett längre kontextfönster – den blir bara långsammare och dyrare. De verkliga vinsterna kommer av att lära Agenten att välja vad den behöver när den behöver det, i stället för att ta in allt på en gång.
Tillförlitligheten kommer från loopen, inte modellen. Skillnaden mellan en Agent som imponerar i en demo och en som håller i produktion är inte AI-kvaliteten, utan huruvida systemet kontrollerar sitt eget arbete. Agenter som planerar, agerar, observerar och verifierar varje steg upptäcker sina egna misstag i stället för att självsäkert göra fel.
De flesta AI-Agenter är i dag i grunden chattbotar med extra steg. De saknar mekanismer för att veta om de är på rätt väg, när de ska sluta eller när de bör prova en annan metod. Ett riktigt styrskikt – tydliga framgångskriterier, strukturerat tillstånd och valideringskontroller – förvandlar något som liknar en Agent till något du faktiskt kan lita på.
Vad åt du till lunch i går?
Du spelade förmodligen inte upp alla minnen du någonsin haft tills du kom till ”i går + lunch”. Du gick direkt till den del av dina erfarenheter där de begreppen hör hemma. Det är en användbar mental modell när du bygger Agenter:
Ett enormt kontextfönster är inte ett minne.
En hög med hämtade dokument är inte förståelse.
En lång tankekedja är inte tillförlitlighet.
Det är ingredienser. Men det som får en Agent att kännas som en Agent är samma sak som gör att din hjärna inte går igenom hela din livshistoria med råstyrka: styrning.
En aktuell översikt – Agentic Reasoning for Large Language Models – sammanfattade och namngav på ett utmärkt sätt den förändring som många av oss har upplevt när vi byggt system: från resonemang inuti modellen till resonemang genom interaktion. Det här inlägget är inte en sammanfattning av den artikeln. Det är ett försök att omsätta förändringen i praktisk systemdesign:
Om du bygger Agenter som chattbotar med verktyg fortsätter du att få chattbotarnas fellägen – fast med dyrare misstag.
Under en tid var vår standardmetod för att ”göra modellen smartare” i princip bättre prompter, tankekedjor, självkonsistens och samplingsbaserade förbättringar samt möjligen sökning.
ReAct blev en vändpunkt eftersom det fick ”tanke → handling → observation” att kännas naturligt. Men lägg märke till den underförstådda begränsningen: mycket av detta blir fortfarande ”One-shot-inferens, fast med fler token”. Översikten formulerar det skarpare: Agent-baserat resonemang betonar skalning av interaktion vid testtillfället – inferens blir en iterativ process där modellen, minnet och omgivningen hela tiden ingår i loopen.
Om du har byggt eller använt Agenter som imponerar i demonstrationer men är sköra i verkliga arbetsflöden är det här för dig.
Låt mig beskriva ett mönster jag ofta har sett och definitivt själv byggt varianter av:
Utgå från en bra chattmodell
Lägg till några verktyg (sökning, databasfrågor och kanske kodkörning)
Lägg till RAG
Lägg till systemprompten ”du är en autonom Agent”
Lägg allt i en while-loop tills den stannar eller når tidsgränsen
Grattis, du har något som liknar en Agent. Men det brukar misslyckas på förutsägbara sätt:
Uppsvälld kontext: varje observation läggs till och prompterna blir arkeologiska lager.
Planlöst verktygsval: ”fel verktyg, men med självförtroende” blir det vanliga felläget.
Inga stoppvillkor: den fortsätter för att den kan, inte för att den bör.
Ingen disciplin för förankring: den märker inte att den har fel om du inte tvingar den.
Minne = chatthistorik: i praktiken skriver den loggar och kallar det lärande.
Det är därför ”Agenter” ofta känns magiska i demonstrationer och röriga i produktion. Våra erfarenheter av att driftsätta Agent-baserade system visar samma sak: när du inte längre utvärderar en modell utan ett system omfattar fellägena navigering, verktygshygien, rensning av kontext och utformning av utvärderingar – inte bara frågan ”svarade modellen rätt?”
Frågan blir alltså: hur ser den avsiktligt utformade Agenten ut?
För att göra det mindre abstrakt tar vi ett förenklat arbetsflöde som de flesta kan föreställa sig: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
En vanlig implementation som liknar en Agent ser ut så här:
Hämtar omedelbart en mängd dokument om flygbolag och resepolicyer, även om inget av dem behövs ännu.
Anropar ett sökverktyg, klistrar in en lång resultatlista i prompten och ”väljer ett”.
Bokar för tidigt utan att verifiera begränsningarna för ankomsttid, bagage, sittplats och policy.
Om den misslyckas försöker den igen på ett lite annorlunda sätt – men utan en tydlig uppfattning om vad som ändrats eller vad den lärt sig.
Problemet är inte att modellen saknar resonemangsförmåga, utan att systemet inte styr arbetsflödet.
En mer Agent-baserad version behandlar uppgiften som en interaktiv process med explicit tillstånd och tydliga kontroller:
PLANERA: upprepa begränsningarna och lista information som saknas (t.ex. ”föredrar du någon flygplats?”/”är en mellanlandning okej?”).
AGERA: anropa flygsökningen med en strukturerad fråga (datumintervall, ankomstkrav och budget).
OBSERVERA: lagra resultaten i ett kompakt tillståndsobjekt (de fem bästa alternativen med pris, ankomsttid och mellanlandningar), inte som en enorm inklistrad textmassa.
UPPDATERA: förfina frågan om kraven inte uppfylls (t.ex. ”ankomst före kl. 18 är för strikt – ska vi utöka tidsintervallet eller höja budgeten?”).
VERIFIERA: kör validerare (”ankomst < 18:00”, ”pris ≤ 900 £”, ”följer policyn”, ”sittplats kan väljas”).
STOPPA: först när boknings-API:t returnerar en bekräftelse och samtliga validerare godkänner resultatet.
Förändringen är subtil men avgörande. Hämtningen sker vid behov, inte reflexmässigt. Kontexten hanteras genom strukturerat tillstånd i stället för att samlas på hög, och verifieringen ingår i loopen i stället för att lämnas åt användaren. Byt ut ”boka en flygresa” mot ”skapa en inköpsorder”, ”utfärda en återbetalning”, ”ändra en produktionskonfiguration” eller ”leverera en PR”, så gäller samma sak: när en Agent kan agera är loopen viktigare än prompten.
Översikten ovan delar in Agent-baserat resonemang i tre nivåer: grundläggande (planering, verktygsanvändning och sökning), självutvecklande (återkoppling och minne) samt kollektivt (samordning mellan flera Agenter).
Men den djupare tanken är att resonemang blir den organiserande principen för planering, beslutsfattande och verifiering – inte bara för att generera en trovärdig tankekedja. Det låter abstrakt tills du kopplar det till vad som förändras i arkitekturen. Det finns tre centrala punkter att komma ihåg:
En bra Agent bör inte behandla hämtning som något som alltid ska göras. Hämtning är ett beslut, inte en reflex.
Här är en praktisk tumregel:
Om systemet hämtar information i varje tur har du inte byggt hämtning – du har byggt en kontextskatt.
Det här händer hela tiden i verkligt arbete. När du felsöker en produktionsincident lägger du inte alla loggar i kontexten. Du väljer vilka mätvärden och loggar som ska hämtas härnäst utifrån din aktuella hypotes. Det är ”Agent-baserad hämtning”. Här är ett mer konkret mönster:
Avgör om du behöver hämta information
Om ja: formulera en fråga, hämta, ögna igenom och extrahera
Om beläggen motsäger varandra: hämta igen
Sammanställ först därefter
Det är också här ”Agent-baserad RAG” börjar skilja sig från traditionell RAG: hämtning blir ett medvetet steg i resonemanget, inte ett standardsteg i en pipeline.
Så fort du slutar utvärdera ”en modell” och börjar utvärdera ”ett system” blir spårning av tillstånd och förlopp viktigt.
Något som branschen numera är tydligare med är observerbarhet i Agent-arbetsflöden. OpenAI:s Agents SDK har till exempel inbyggd spårning och en Traces-instrumentpanel som registrerar Agent-körningar (genereringar, verktygsanrop, överlämningar, skyddsräcken och anpassade händelser), så att du steg för steg kan felsöka och granska vad som hände.
Det är inte bara ”bra att ha”. Det är skillnaden mellan ett system som går att felsöka och ett som bara går att magkänslegranska.
Den mest användbara delen av översikten är enligt mig hur direkt den tar upp återkoppling. Den delar in återkoppling i tre typer: reflekterande återkoppling (generera → granska → revidera), parametrisk anpassning (lärande via finjustering/RL) och valideringsstyrd återkoppling (försök igen tills en validerare godkänner resultatet).
De flesta team bör börja med valideringsstyrd återkoppling, eftersom den är tråkig men effektiv. Om du kan skriva någon validerare som enhetstestar, kontrollerar schemat, tillämpar affärsregler eller begränsningar (”inga återbetalningar över X utan eskalering”) eller säkerställer riktighet (”källhänvisningar krävs”), kan du omvandla icke-deterministiska modellresultat till något du faktiskt kan lita på.
En av de oväntade insikterna här är enkel: för Agenter kommer tillförlitligheten ofta mer från loopen än från modellen.
Det här är den minsta loopdisciplin jag har hittat som tillförlitligt förbättrar beteendet utan träning:
Arbeta stegvis: Planera → Agera → Observera → Uppdatera,
Sammanfatta observationen i 1–3 punkter efter varje åtgärd,
Avsluta när framgångskriterierna är uppfyllda eller budgeten nåtts. Returnera bästa kända resultat och kvarstående osäkerheter.
Det handlar inte om att göra modellen mångordig. Det handlar om att göra systemet begripligt och tvinga fram ”verklighetskontakt” i varje steg. Ett exempel som ingenjörer lätt kan relatera till är förankring i en sluten loop enligt CI-principer:
Planera: föreslå en ändringslista
Agera: kör tester/lintning
Observera: tolka fel
Uppdatera: korrigera och försök igen
Några frågor som brukar avslöja oavsiktliga Agent-konstruktioner:
”Väljer min Agent vad som ska hämtas, eller hämtar jag alltid?”
Om hämtningen alltid sker får du betala med längre svarstid, högre kostnad, urvattnad kontext och större risk för att skräp in ger skräp ut.
”Kan min Agent upptäcka att den har fel?”
Om din Agents enda återkopplingssignal är att ”användaren blir irriterad” bedriver du RL med mänskligt lidande. En valideringsstyrd loop med nya försök är det renaste sättet att ge den en verklighetskontroll.
”Är minnet skrivbart, och blir det bättre med tiden?”
Om ditt ”minne” bara lägger till chatthistorik skriver du i praktiken bara loggar. Översiktens syn på minne är viktig: minnet blir en dynamiskt växande kontext som Agenter förfinar över tid – inte bara en transkription.
Loggar berättar vad som hände, medan minnet berättar vad du ska göra nästa gång. Chatthistorik är en transkription. Minne är en föränderlig policy för vad som är värt att ta med sig framåt.
En praktisk start är en liten tabell över ”lärdomar”, där nyckeln består av uppgiftstyp, verktyg och felläge och värdet anger vad som fungerade och vad som bör undvikas. Poängen är inte att bygga en perfekt kunskapsgraf. Poängen är att skapa en kumulativ förbättring: minne och återkoppling förvandlar Agenter från ”tillståndslösa hjälpredor” till system som blir bättre med tiden.
Det är frestande att sätta in fler Agenter mot problemet, men ofta mångdubblar det samordningsarbetet. Ett bra mönster för ett ”minsta fungerande team”:
Samordnare: delar upp och fördelar
Utförare: gör verktygsanrop och ändringar
Granskare/utvärderare: kontrollerar riktighet och risk
Minnesförvaltare: skriver och sammanställer lärdomar
Om du inte kan förklara vad varje Agent ansvarar för behöver du förmodligen inte flera Agenter än.
Om vi verkligen tror på paradigmskiftet slutar vi förmodligen att stoppa in allt i prompter, behandla misslyckanden som slutliga resultat och utvärdera Agenter som chattbotar. I stället börjar vi behandla Agenter som det de är: programvarusystem där språket är styrplanet och tillförlitligheten kommer från loopen.
Lägg till en utvärderingsloop innan du lägger till ännu en modell. Gör hämtningen villkorad innan du hämtar allt. Driftsätt en validerare innan du driftsätter tio. Behandla minnet som policybeslut, inte som en databas. Och när du går över till flera Agenter, börja med två – inte tjugo. Det här är inga regler, utan de mönster som klarade sig i produktion.