En AI-agent är en loop med verktyg, inte en smartare chatbot

Skillnaden mellan en chatbot och en agent är att chatboten svarar och agenten gör något. Rent tekniskt är en agent tre delar som hänger ihop: en språkmodell, en uppsättning verktyg modellen får anropa och en loop som kör tills målet är nått eller ett stoppvillkor slår till. Det är hela grundprincipen. Allt annat, inklusive protokoll som MCP och ramverk som Mastra, är bekvämlighetslager ovanpå den loopen.

Om du redan använt Claude Code eller något liknande i terminalen har du sett loopen arbeta: modellen läser en fil, funderar, redigerar, kör testerna, läser felmeddelandet, försöker igen. Ingen människa i mitten mellan stegen. Den som vill se hela processen från grunden kan följa en praktisk genomgång av att bygga en Claude-agent med MCP, som visar samma loop steg för steg.

Loopen heter ReAct och består av fyra steg

Mönstret bakom nästan alla agenter i dag kallas ReAct, kort för reason och act. Agenten resonerar om vad den ska göra, anropar ett verktyg, observerar vad verktyget returnerade och börjar om med den nya informationen i bagaget. Loopen bryts när uppgiften är klar eller när du sagt stopp.

Två egenskaper hos det här skiljer agenter från vanlig kod och båda är viktiga att ta in innan du bygger något.

Agenten är icke-deterministisk. Samma prompt kan ta helt olika vägar två gånger i rad, eftersom modellen väljer nästa steg baserat på vad den råkar observera. Och verktygsanrop misslyckas. En fil saknas, ett API svarar med 500, ett sökanrop returnerar noll träffar och modellen kan då prata sig in i ett dödläge där den upprepar samma misslyckade anrop tio gånger.

Claude passar rimligt bra för den här sortens arbete av ett par konkreta skäl: kontextfönstret på en miljon tokens rymmer långa resonemangkedjor utan att tidiga steg trillar ur, verktygsanvändning är inbyggd som strukturerade funktionsanrop och modellen hallucinerar verktygsargument mer sällan än flera konkurrenter. Det sista låter som en detalj men är det inte. En agent som hittar på parameternamn kraschar i varje varv.

Ett verktyg är en funktion med en beskrivning modellen läser

Här ligger det mesta av det faktiska hantverket. Ett verktyg består av ett namn, ett inmatningsschema och en beskrivning i klartext. Beskrivningen är inte dokumentation för dig, den är instruktionen modellen läser för att avgöra när verktyget ska användas och hur. Skriver du ”hämtar data” får du en agent som gissar.

Schemat definieras typiskt med zod i JavaScript- och TypeScript-världen, vilket ger modellen exakt besked om vilka parametrar som gäller och vilka typer de har. Mastra bygger på just den kombinationen: verktyg med zod-scheman, en agent som binder ihop dem med modellen och en körning som hanterar loopen åt dig. Om du vill se ett komplett exempel byggt på liknande grunder finns en steg-för-steg-guide för att bygga en Claude-agent från grunden.

Fyra principer gör skillnad på tillförlitligheten. Håll varje verktyg snävt, eftersom ett verktyg som gör en sak går att beskriva exakt medan ett som gör fem blir en gissningslek för modellen. Validera inmatningen innan något körs och returnera ett strukturerat fel i stället för att kasta ett undantag som spräcker loopen. Returnera strukturerade resultat, inte fritext som modellen måste tolka. Var explicit när resultatet är tomt: ett verktyg som returnerar tom sträng får modellen att fabricera, ett som returnerar ”inga träffar för sökordet X” får den att gå vidare.

MCP, Model Context Protocol, standardiserar hur verktygen levereras. En MCP-server exponerar funktioner som `read_file`, `write_file` eller `list_directory` och en MCP-klient som Claude Code eller Claude Desktop ansluter och gör dem tillgängliga för modellen. Eftersom formatet är gemensamt kan vilken klient som helst prata med vilken server som helst. Du skriver filsystemverktyget en gång och kan sedan koppla in det i olika miljöer utan att skriva om något.

AG-UI löser den andra änden: hur du visar det agenten håller på med i ett användargränssnitt. En agent som jobbar i trettio sekunder utan att säga något upplevs som trasig och protokollet ger ett standardiserat sätt att strömma händelser om verktygsanrop, delresultat och statusändringar till en frontend.

Modellen glömmer allt mellan körningar om du inte bygger minne

Det är ingen brist, det är hur ett API fungerar men det överraskar många som testar sin första agent och undrar varför den glömde allt.

Tre mönster används i praktiken och de löser olika problem. Enklast är att behålla hela konversationen i kontextfönstret, vilket fungerar utmärkt tills historiken blir för lång eller för dyr. Semantiskt minne med embeddings sparar tidigare material i en vektordatabas och hämtar relevanta bitar vid behov. Tredje varianten är att göra minnet till ett verktyg: agenten får `spara_anteckning` och `sök_anteckningar` och avgör själv när den behöver dem.

Håll isär två saker som är lätta att blanda ihop. Kontext inom en körning är vad som stannar i konversationen medan agenten arbetar. Persistens mellan körningar är vad som överlever att processen avslutas. Bygger du bara det första får du en agent som är briljant i tio minuter och nollställd i morgon.

Fem sätt agenter går sönder i produktion

Felen är förutsägbara nog att man kan förbereda sig på dem innan de inträffar. De vanliga:

1. Agenten loopar för alltid utan att komma närmare målet.
2. Den bränner budget på en enda lång körning ingen tittade på.
3. Den fabricerar innehåll när ett verktyg returnerade ingenting.
4. Den utför fel irreversibel åtgärd, som att radera eller skicka.
5. Den misslyckas tyst, utan loggar som förklarar var det gick fel.

Motmedlen är lika konkreta. Sätt en hård iterationsgräns och lägg till upprepningsdetektering som bryter när samma anrop kommer tredje gången med samma argument. Sätt en tokenbudget per körning. Gör tomma resultat explicita, som beskrivet ovan. Kräv bekräftelse eller kör torrläge på allt med sidoeffekter, alltså allt som skriver, skickar eller betalar. Logga varje steg strukturerat: vilket verktyg, vilka argument, vilket svar, hur lång tid.

Den sista punkten är inte en trevlighet. Utan stegloggar kan du inte felsöka ett system som tar olika väg varje gång.

Utan eval-harness vet du inte om ändringen hjälpte

Eftersom agenten är icke-deterministisk bevisar ”det fungerade när jag testade” ingenting alls. Du körde ett fall en gång och fick en av flera möjliga vägar.

Lösningen är en eval-harness: en samling fasta testfall som agenten körs mot, med automatisk poängsättning av resultaten. Justerar du en verktygsbeskrivning eller byter systemprompt kör du hela sviten och ser om siffran gick upp eller ner. Det är den enda mekanism som gör agentutveckling till ingenjörsarbete i stället för tur. Bygg den tidigt, inte när något redan gått fel i skarpt läge.

Välj den minst agentiska lösning som fungerar

Här är rådet som sparar mest tid och det går emot instinkten hos den som just läst om agenter.

Kan du skriva ner stegen i förväg ska du inte bygga en agent. Bygg en pipeline. En fast sekvens är billigare att köra, snabbare att svara och trivial att felsöka, eftersom samma inmatning alltid ger samma väg genom koden. Hämta data, transformera, skicka till modellen, formatera svaret: det är en pipeline, inte en agent, även om det finns en LLM i mitten.

Agenten är rätt val när vägen fram genuint inte går att känna i förväg och systemet måste bestämma sitt nästa drag utifrån vad det hittar. Felsökningsuppgifter, research där svaret avgör nästa sökning, arbete mot ett filsystem eller kodbas vars innehåll du inte känner. Att välja den minst agentiska arkitekturen som löser problemet är seniordraget och en påfallande stor del av allt som marknadsförs som agenter under 2026 hade fungerat bättre som tre funktionsanrop i rad.

Börja lokalt med Node och två verktyg

Definiera två verktyg, inte tio: ett som läser något och ett som skriver något. Ge dem zod-scheman och beskrivningar som en kollega hade förstått utan att läsa koden. Skriv loopen själv första gången, alltså anropa modellen, kolla om svaret innehåller ett verktygsanrop, kör verktyget, skicka tillbaka resultatet, upprepa. Sätt maxantal varv till fem.

När loopen känns självklar kan du byta ut den mot Mastra och slippa boilerplaten, koppla på MCP för att återanvända verktygen i Claude Code och lägga AG-UI över alltihop när det ska bli ett gränssnitt någon annan använder. Ordningen spelar roll: förstår du inte loopen blir ramverket en svart låda du inte kan felsöka. Om du redan experimenterat med att bygga en AI-agent som körs direkt i webbläsaren känner du igen samma grundmönster, bara i en annan miljö.

Ett tips för lokal utveckling: kör allt mot localhost och logga varje steg till fil från första dagen. Du kommer läsa de loggarna mer än du tror.

FAQ

Behöver jag Claude Code för att bygga en agent?

Nej. Claude Code är en utvecklingsmiljö där agenten kör i din terminal och mot din kodbas men du kan lika gärna anropa modell-API:et direkt från en egen Node- eller Python-process. Claude Code blir användbart när du vill koppla in MCP-verktyg och testa dem i en färdig klient utan att bygga gränssnitt.

Vad är skillnaden mellan MCP och vanliga tool calls?

Tool calls är formatet modellen använder för att be om att en funktion körs. MCP är protokollet som beskriver hur verktygen levereras till modellen, oberoende av vilken klient som används. Du kan bygga en fungerande agent helt utan MCP, med verktygen definierade direkt i koden.

Hur mycket kostar det att köra en agent?

Kostnaden styrs av hur många tokens som passerar och en agent som loopar tjugo varv skickar med hela historiken varje gång. Det är därför tokenbudget per körning är standardpraxis snarare än en försiktighetsåtgärd.

Kan agenten komma ihåg mig mellan sessioner?

Bara om du bygger persistensen. Spara konversationer eller sammanfattningar i en databas och läs in dem vid start eller ge agenten verktyg för att skriva och söka i sina egna anteckningar.