Mina AI-agenter tillhör inte sitt verktyg

Vad du får med dig här: Varför identiteten för mina AI-agenter finns i separata filer istället för i respektive verktyg, hur sex olika program ändå kan ladda samma team – och hur jag bedömer vad som faktiskt fungerar produktivt.

”Mein Agents Brain” uppstod ursprungligen ur problemet att mitt AI-team till stor del var låst till 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 på ett sätt som gör att det inte händer mig igen. Vem mina agenter är, vad de får göra och vad de har lärt sig finns 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”, men jag brukar oftast bara säga: dess nuvarande kropp.

En agent är inte samma sak som det chattfönster där jag just nu pratar med honom. Fönstret är bara den plats där han arbetar just idag. Här kan du läsa om hur samma agent kan arbeta i olika verktyg utan att jag behöver skapa honom på nytt varje gång.

Vad denna separation besparar mig

Det låter som en arkitektonisk detalj. För mig är det dock ett affärsbeslut.

Hur snabbt ett verktyg kan kräva mer underhåll än det underlättar arbetet upplevde jag med OpenClaw i januari och februari 2026. I ett sådant läge vill jag kunna byta utan att förlora mitt team – inom inköp kallas det problem som jag därmed undviker för ”vendor lock-in”. 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 medarbetare ett arbetssätt eller fastställer en korrigering på lång sikt, ska det bestå även efter nästa personalförändring. Annars börjar den mödosamma fasen på nytt efter varje omställning, 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 publicering. 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 min del ä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 vid start, laddar uttryckligen med delningsreglerna och kräver att agenten vid 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 vad jag en gång skapade – i en tidig konfiguration fanns en sammansatt kopia av en persona på målsystemet, och jag insåg att den skulle bli fel i Brain redan vid nästa korrigering. Jag bytte samma dag till direkta hänvisningar, och sedan dess håller jag medvetet dessa filer små.

Sex broar till samma hjärna

Det finns nu sådana kopplingar 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 tillskotten, 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 den agent 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. På så sätt laddar målet alltid den aktuella versionen, inklusive de senaste korrigeringarna.

Godkännandereglerna följer med

Den del av systemet som är minst förhandlingsbar är gränserna. Sol får utforma texter och spara dem som utkast i WordPress; 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 detta godkännande. Inte ens det mest kraftfulla verktyget får några ytterligare befogenheter bara för att det kan göra mer: en längre delegeringskedja 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 mitt ansvar, oavsett vilket verktyg som används.

Fyra steg från löfte till bevis

Här skulle jag kunna säga: sex verktyg, ett team, allt fungerar. Men sex adapterfiler bevisar i sig ingenting – en konfigurationsfil är ett löfte, men långt ifrån drift. Därför kontrollerar jag varje objekt i fyra steg och uttalar mig endast utifrån vad respektive steg ger utrymme för.

Först kontrollerar automatiska testskript pappersnivån. Pekar bryggan på rätt Brain, laddar den nödvändiga filerna, finns godkännandereglerna med? Dessa tester upptäcker även småfel, till exempel om ett specifikt 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 – enbart läsning, utan att ändra något. Först då vet jag att systemet faktiskt laddar persona och inte bara skulle kunna ladda den.

Den tredje nivån är mitt nödtest. Från en färsk kopia av repositoriet, i en medvetet avskalad miljö utan mina vanliga program, måste det gå att återställa en agent inklusive regler och minnesrutiner – enbart med Git och Pythons inbyggda verktyg. Om det fungerar är systemet inte beroende av någon dold installation på min dator.

Det fjärde steget är den fullständiga genomföringen: Agenten utför en verklig uppgift i det aktiva verktyget, håller sig till sina godkännanden och lagrar dagens post i sitt minne. Därefter måste en andra, oberoende körning kunna läsa denna post igen. Först då betraktar jag en enhet som fullt funktionsduglig.

Stegen bygger på varandra, och inget steg tar hand om nästa. Den som blandar ihop dem förvandlar snabbt en befintlig konfiguration till ett påhittat praktiskt bevis.

Var de sex kropparna befinner sig idag

Fem av de sex har nu genomfört riktiga omgångar – men inte alla på samma nivå, och det är precis så jag uttrycker det. Hermes är den kropp där Nox ändå arbetar dagligen och för sin dagbok. Claude Code har klarat hela testet: verkligt uppdrag, iakttagna godkännanden, dagboksanteckning skriven och självständigt genomläst. Grok Build, den senaste tillskottet, har nu också klarat samma test. Två begränsningar gäller för 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 – minnen lagras uteslutande i hjärnan.

Codex har vid flera tillfällen konkret bevisat det gemensamma läsavtalet, senast i en direkt jämförelse med Claude Code och Hermes: Alla tre läste samma inledande sekvens 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 den fullständiga genomkörningen med återskriven dagboksanteckning – därför görs heller inget påstående om detta.

Då återstår Gemini. Bron är byggd och klarar alla kontraktstester, men det har ännu inte genomförts någon riktig körning – 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 betaltillgång 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 i bruk.

Varför jag ändå talar om kroppsbyte

Metaforen håller så länge den förblir tekniskt korrekt. Kroppen tillhandahåller funktionerna: åtkomst till modellen, terminal, webbläsare, tidsstyrning, gränssnitt. Hjärnan tillhandahåller roll, hantverk, gränser och minne. En förändring påverkar alltså vad en agent kan göra 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 det här arbetet lönar sig i vardagen: Det är just den här sammanfattningen jag gör i den sista delen – vad som faktiskt gick att överföra vid bytet av kropp, vilka luckor som blev synliga och vilka bevis som fortfarande saknas.

Källor

• Projektkälla: agents-brain-specifikation, sex harness-adaptrar, testskript för Interop och Fresh Clone samt interna körningsloggar (privata primärkällor)
• Pro Git: Vad är Git?