--- title: Mina AI-agenter tillhör inte sitt verktyg — isla Studio url: https://isla-stud.io/sv/ki-b2b/derselbe-agent-vier-werkzeuge/ date: 2026-07-29 --- # Mina AI-agenter tillhör inte sitt verktyg Vad du får med dig här: Varför identiteten hos mina AI-agenter finns i egna filer istället för i respektive verktyg, hur sex olika program ändå laddar samma team – och hur jag mäter vad som fungerar produktivt. Mitt Agents Brain uppstod ursprungligen ur problemet att mitt AI-team till stor del var fast i ett enda verktyg (Harness): den löpande orkestreringen, kanalerna, de inarbetade automatiseringarna. Jag kunde behålla mina agenters Markdown-filer – allt annat var jag tvungen att bygga upp på nytt. Sedan dess bygger jag så att det inte händer mig igen. Vem mina agenter är, vad de får göra och vad de har lärt sig står i filer som för det första tillhör mig och för det andra där jag kan spåra ändringarna. Programmet där en agent just nu körs är däremot utbytbart – experter kallar denna körmiljö för en ”harness”, jag brukar oftast bara säga: dess nuvarande kropp. En agent är helt enkelt inte det chattfönster där jag just nu pratar med den. Fönstret är bara den plats där den arbetar idag. Här kan du läsa om hur samma agent kan arbeta i olika verktyg utan att jag behöver uppfinna den på nytt varje gång. Vad denna åtskillnad sparar mig Det låter som en arkitektonisk detalj. För mig är det dock ett affärsbeslut. Hur snabbt ett verktyg kräver mer underhåll än det underlättar arbetet upplevde jag med OpenClaw i januari och februari 2026. I ett sådant ögonblick vill jag kunna byta utan att förlora mitt team – inom inköp kallas det problem som jag därmed undviker för leverantörsberoende. Mina agenter är inte bundna till någon enskild leverantör, eftersom inget väsentligt endast finns i just den leverantörens produkt. Därtill kommer kontinuiteten. När jag lär en agent ett arbetssätt eller fastställer en korrigering permanent ska det överleva nästa verktygsbyte. Annars börjar den mödosamma fasen igen efter varje byte, där teamet inte känner till sina egna regler. Och eftersom min författare Sol skriver under mitt namn finns det en tredje anledning: tillförlitlighet vid publiceringar. Att hon aldrig publicerar själv får inte bero på vilket verktyg hon använder just idag. Mer om det strax. En liten fil talar om för verktyget var agenten finns För att ett verktyg ska kunna ladda en agent krävs en brygga. För mig är det en liten konfigurationsfil, adaptern: Den pekar på agentens mapp i Brain – det privata Git-arkivet där alla dessa filer finns versionerade – anger läsordningen för uppstarten, laddar uttryckligen med delningsreglerna och kräver att agenten i slutet av en session skriver tillbaka en dagspost till sitt minne (den så kallade Write-Back). Lika viktigt är vad som inte hör hemma där: ingen kopia av personligheten, ingen duplicerad sakkunskap, ingen andra version av godkännandereglerna. Varje kopia börjar bli föråldrad så fort den existerar. Det var precis det jag en gång byggde – i en tidig konfiguration fanns en sammansatt personlighetskopia på målsystemet, och jag insåg att den skulle bli felaktig i hjärnan redan vid nästa korrigering. Jag bytte samma dag till direkta referenser, och sedan dess håller jag medvetet dessa filer små. Sex broar till samma Brain Numera finns sådana broar för sex verktyg. Claude Code från Anthropic läser projektrelaterade instruktioner inklusive agentdefinitioner. Codex – kommandoradsverktyget från OpenAI:s ChatGPT-värld – får en projektbriefing. Google Gemini förväntar sig en egen projektfil, och Hermes från Nous Research laddar identiteten via en systemprompt. Kimi Code från Moonshot AI och Grok Build från xAI, de två senaste, har var och en sina egna agentformat. Sex format, sex olika syntaxer. Innehållsmässigt står det ändå samma sak överallt: var agenten finns, vad som ska läsas vid start, vilka behörigheter som gäller och vad som skrivs tillbaka i slutet. Enligt samma princip överlämnar mina agenter arbete till varandra. När Nox – min orkestrator, det vill säga agenten som fördelar uppgifter och håller koll på helheten – delegerar ett uppdrag till ett annat verktyg, kopierar han inte personaen till uppdragstexten. Han skriver i stället ungefär: Arbeta som Sol, läs först hennes filer. Därmed laddar mottagaren alltid den aktuella versionen, inklusive de senaste korrigeringarna. Godkännandereglerna följer med Den minst förhandlingsbara delen av detta system är gränserna. Sol får utforma texter och spara dem som utkast i WordPress; men hon får inte publicera dem – det bestämmer jag. Denna regel finns i hennes egna agentfiler – i RULES, hennes anställningsavtal med kompetenser och behörigheter, och i MASTER, hennes detaljerade handbok – och båda laddas vid varje start, oavsett vilket verktyg som används. Om Nox alltså ger henne i uppdrag via Codex istället för via Claude Code, förändras ingenting i denna behörighet. Inte ens det mest kraftfulla verktyget får några ytterligare rättigheter bara för att det kan mer: En längre delegeringsväg gör inte en författare till en redaktör. Detsamma gäller allt som kostar pengar, raderar något eller aktiverar något produktivt – sådana åtgärder förblir hos mig, oavsett verktyg. Fyra steg från löfte till bevis Här skulle jag kunna hävda: sex verktyg, ett team, allt fungerar. Men sex adapterfiler bevisar i första hand ingenting – en konfigurationsfil är ett löfte och långt ifrån drift. Därför granskar jag varje komponent i fyra steg och hävdar endast vad respektive steg ger utrymme för. Först kontrollerar automatiska testskript pappersläget. Pekar bryggan mot rätt Brain, laddar den nödvändiga filerna, finns godkännandereglerna med? Dessa tester fångar även upp småsaker, till exempel om ett konkret namn av misstag hamnar i en generisk mall. I det andra steget måste verktyget verkligen starta och läsa identiteten i den avsedda ordningen – endast i läsläge, utan att ändra något. Först då vet jag att systemet faktiskt laddar persona och inte bara skulle kunna ladda den. Det tredje steget är mitt nödtest. Från en ny kopia av repositoriet, i en medvetet avskalad miljö utan mina vanliga program, måste det gå att återställa en agent inklusive regler och minnesrutin – enbart med Git och inbyggda Python-verktyg. Om det fungerar är systemet inte beroende av någon dold installation på min dator. Det fjärde steget är det fullständiga genombrottet: Agenten utför en verklig uppgift i det körande verktyget, håller sig till sina behörigheter och skriver dagens post i sitt minne. Därefter måste en andra, oberoende körning kunna läsa denna post igen. Först då kallar jag en kropp fullt funktionsduglig. Stegen bygger på varandra, och inget steg utför nästa åt dig. Den som blandar ihop dem förvandlar snabbt en befintlig konfiguration till ett påhittat praktiskt bevis. Var de sex enheterna befinner sig idag Fem av de sex har nu genomfört riktiga körningar – men inte alla på samma nivå, och det är precis så jag uttrycker det. Hermes är den enhet där Nox ändå arbetar dagligen och för sin dagbok. Claude Code har klarat hela genomgången: verklig uppgift, iakttagna godkännanden, dagboksanteckning skriven och självständigt återläst. Grok Build, den senaste tillskottet, har nu också klarat samma genomgång. Två begränsningar hör till detta bevis: De obevakade körningarna krävde flera uttryckliga fortsättningar av samma session, och Groks inbyggda långtidsminne förblir medvetet avstängt – minnet sker uteslutande i Brain. Codex har flera gånger bevisat det gemensamma läskontraktet i praktiken, senast i en direkt jämförelse med Claude Code och Hermes: Alla tre läste samma startsekvens från samma Brain och kom fram till samma utvärdering. Kimi Code har genomfört en första riktig körning, hittills endast i läsläge. För båda återstår det fullständiga genombrottet med återskriven dagboksanteckning – därför hävdas det inte heller. Då återstår Gemini. Bron är byggd och klarar alla avtalstester, men en riktig körning har ännu inte ägt rum – och det beror numera inte längre på min konfiguration: Google har avslutat den kostnadsfria åtkomsten till detta verktyg och hänvisar till en efterföljare. Om jag ska byta dit, skaffa en betald åtkomst eller lägga Gemini på is tills vidare, det bestämmer jag i lugn och ro. Tills dess står Gemini på min lista som det den är – förberedd, men inte använd. Varför jag ändå talar om kroppsbyte Metaforen håller så länge den förblir tekniskt korrekt. Kroppen har förmågorna: modellåtkomst, terminal, webbläsare, tidsstyrning, gränssnitt. Hjärnan tillhandahåller roll, hantverk, gränser och minne. Ett byte förändrar alltså vad en agent kan och var den arbetar – inte vem den är. Det fungerar bara så länge båda sidor förblir åtskilda. Så snart en kropp börjar samla på sig egen kunskap som inte återspeglas någon annanstans blir den återigen en del av minnet – och jag blir återigen beroende av ett enda verktyg. Om du undrar om denna insats lönar sig i vardagen: Det är just denna sammanfattning jag gör i den sista delen – vad som faktiskt var portabelt vid kroppsbytet, vilka luckor som blev synliga och vilka bevis som fortfarande saknas. Källor Projektkälla: agents-brain-specifikation, sex Harness-adaptrar, Interop- och Fresh-Clone-testskript samt interna körningsloggar (privata primärkällor) Pro Git: Vad är Git? Agents-Brain-serien← Del 4: Att minnas är en skrivrutin hos mina agenterDel 6: Vad som verkligen kvarstod efter kroppsbytet →