KI-agentene mine tilhører ikke verktøyet sitt

Dette får du med deg: Hvorfor identiteten til KI-agentene mine ligger i egne filer i stedet for i det enkelte verktøyet, hvordan seks forskjellige programmer likevel laster inn det samme teamet, og hvordan jeg vurderer hva som faktisk fungerer i produksjon.

Mitt Agents Brain oppsto fordi KI-teamet mitt i stor grad satt fast i ett enkelt verktøy, et såkalt harness: den løpende orkestreringen, kanalene og de innarbeidede automatiseringene. Jeg kunne beholde agentenes Markdown-filer. Alt annet måtte jeg bygge opp på nytt.

Siden har jeg bygget slik at det ikke skal skje igjen. Hvem agentene mine er, hva de har lov til, og hva de har lært, står i filer som jeg eier, og der jeg kan følge endringene. Programmet en agent kjører i akkurat nå, kan derimot byttes ut. Fagfolk kaller dette kjøremiljøet et harness. Jeg sier som regel bare: kroppen den bruker nå.

En agent er ikke samtalevinduet der jeg snakker med den akkurat nå. Vinduet er bare stedet den arbeider i dag. Her kan du lese hvordan den samme agenten kan arbeide i ulike verktøy uten at jeg må finne den opp på nytt hver gang.

Hva dette skillet sparer meg for

Det høres ut som en arkitekturdetalj. For meg er det en forretningsbeslutning.

Med OpenClaw i januar og februar 2026 erfarte jeg hvor fort et verktøy kan kreve mer vedlikehold enn det sparer arbeid. Da vil jeg kunne bytte uten å miste teamet mitt. I innkjøpssammenheng kalles problemet jeg unngår, leverandørbinding. Agentene mine er ikke avhengige av én enkelt leverandør, fordi ingenting vesentlig bare finnes i leverandørens produkt.

I tillegg kommer kontinuiteten. Når jeg lærer en agent en arbeidsmåte eller tar vare på en rettelse for fremtiden, skal det overleve neste verktøybytte. Ellers begynner den krevende fasen der teamet ikke kjenner sine egne regler, på nytt etter hver flytting.

Og fordi forfatteren min, Sol, skriver under mitt navn, finnes det en tredje grunn: pålitelige godkjenninger. At hun aldri publiserer selv, må ikke avhenge av hvilket verktøy hun kjører i den dagen. Mer om det straks.

En liten fil forteller verktøyet hvor agenten bor

For at et verktøy skal kunne laste inn en agent, trengs en bro. Hos meg er det en liten konfigurasjonsfil, adapteren. Den peker på agentens mappe i Brain, det private Git-arkivet der alle disse filene er versjonert. Den angir leserekkefølgen ved oppstart, laster uttrykkelig inn godkjenningsreglene og krever at agenten skriver en dagsoppføring tilbake til hukommelsen ved slutten av økten. Det siste kalles write-back.

Det som ikke hører hjemme der, er like viktig: ingen kopi av personligheten, ingen duplisert fagkunnskap og ingen ekstra versjon av godkjenningsreglene. Hver kopi begynner å bli utdatert så snart den finnes. Nettopp det bygget jeg en gang. I et tidlig oppsett lå en sammensatt personakopi på målsystemet, og jeg innså at den ville bli feil i det stille ved neste rettelse i Brain. Samme dag erstattet jeg den med direkte henvisninger. Siden har disse filene bevisst vært små.

Seks broer til det samme Brain

Nå finnes det slike broer for seks verktøy. Claude Code fra Anthropic leser prosjektinstruksjoner og agentdefinisjoner. Codex, kommandolinjeverktøyet fra OpenAIs ChatGPT-verden, får et prosjektgrunnlag. Google Gemini forventer sin egen prosjektfil, og Hermes fra Nous Research laster inn identiteten via en systemprompt. De to nyeste, Kimi Code fra Moonshot AI og Grok Build fra xAI, har hver sine agentformater.

Seks formater med seks forskjellige syntakser. Innholdet er likevel det samme overalt: hvor agenten bor, hva som skal leses ved oppstart, hvilke godkjenninger som gjelder, og hva som skal skrives tilbake til slutt.

Agentene mine gir arbeid videre til hverandre etter samme prinsipp. Når Nox, orkestratoren min som fordeler oppgaver og holder oversikten, delegerer et oppdrag til et annet verktøy, kopierer han ikke personaen inn i oppdragsteksten. Han skriver i praksis: Arbeid som Sol, og les filene hennes først. Mottakeren laster dermed alltid inn den gjeldende versjonen, også de siste rettelsene.

Godkjenningsreglene følger med

Grensene er den minst forhandlingsbare delen av dette systemet. Sol kan skrive tekster og lagre dem som utkast i WordPress. Hun har ikke lov til å publisere dem. Det bestemmer jeg. Regelen står i hennes egne agentfiler: i RULES, arbeidsavtalen med ferdigheter og godkjenninger, og i MASTER, den utførlige håndboken. Begge lastes inn ved hver oppstart, uansett verktøy.

Hvis Nox gir henne oppdraget gjennom Codex i stedet for Claude Code, endrer det altså ingenting ved godkjenningen. Selv det kraftigste verktøyet får ikke ekstra rettigheter bare fordi det kan mer. En lengre delegeringskjede gjør ikke en forfatter til en utgiver. Det samme gjelder alt som koster penger, sletter noe eller setter noe i produksjon. Slike steg forblir mitt ansvar, uavhengig av verktøyet.

Fire trinn fra løfte til dokumentasjon

Her kunne jeg påstått: Seks verktøy, ett team, alt fungerer. Men seks adapterfiler beviser i seg selv ingenting. En konfigurasjonsfil er et løfte, og det er langt derfra til faktisk drift. Derfor kontrollerer jeg hver kropp i fire trinn og påstår bare det det enkelte trinnet gir grunnlag for.

Først kontrollerer automatiske testskript oppsettet på papiret. Peker broen på riktig Brain, laster den inn de obligatoriske filene, og er godkjenningsreglene med? Testene fanger også opp småting, som at et konkret navn ved et uhell havner i en generell mal.

På det andre trinnet må verktøyet faktisk starte og lese identiteten i den angitte rekkefølgen, med bare lesetilgang og uten å endre noe. Først da vet jeg at kroppen faktisk laster inn personaen, ikke bare at den kunne gjort det.

Det tredje trinnet er beredskapstesten min. Fra en fersk kopi av arkivet, i et bevisst sparsomt miljø uten de vanlige programmene mine, må det være mulig å gjenopprette en agent med regler og hukommelsesrutine. Bare Git og standardfunksjonene i Python skal være nødvendig. Hvis det fungerer, er ikke systemet avhengig av en skjult installasjon på maskinen min.

Det fjerde trinnet er en full test fra start til slutt: Agenten utfører en ekte oppgave i det kjørende verktøyet, følger godkjenningsreglene og skriver dagsoppføringen til hukommelsen. Deretter må en ny, uavhengig kjøring kunne lese oppføringen tilbake. Først da kaller jeg en kropp fullt arbeidsfør.

Trinnene bygger på hverandre, og ingen av dem gjennomfører det neste. Blander man dem, blir en eksisterende konfigurasjon fort til et oppdiktet bevis fra praksis.

Hvor de seks kroppene står i dag

Fem av de seks har nå vært gjennom ekte kjøringer, men ikke alle på samme trinn, og det er nettopp slik jeg beskriver det. Hermes er kroppen der Nox allerede arbeider og fører dagbok hver dag. Claude Code har bestått hele testen: ekte oppgave, godkjenningsregler fulgt, dagsoppføring skrevet og lest tilbake uavhengig. Grok Build, det nyeste tilskuddet, har nå også bestått den samme testen. To begrensninger hører med til dokumentasjonen: Kjøringene uten tilsyn krevde flere uttrykkelige fortsettelser av den samme økten, og Groks innebygde langtidsminne er bevisst slått av. Hukommelsen ligger utelukkende i Brain.

Codex har flere ganger dokumentert at den felles leseavtalen fungerer i praksis, senest i direkte sammenligning med Claude Code og Hermes. Alle tre leste den samme oppstartssekvensen fra det samme Brain og kom frem til samme vurdering. Kimi Code har gjennomført en første ekte kjøring, foreløpig med bare lesetilgang. For begge gjenstår hele testen med en dagsoppføring skrevet tilbake. Derfor påstår jeg heller ikke at den er gjennomført.

Da gjenstår Gemini. Broen er bygget og består alle kontrakttestene, men en ekte kjøring finnes ennå ikke. Nå skyldes det ikke lenger oppsettet mitt: Google har avviklet gratistilgangen for dette verktøyet og viser til et etterfølgerprodukt. Om jeg bytter til det, velger betalt tilgang eller lar Gemini ligge foreløpig, avgjør jeg i ro og mak. Inntil da står Gemini på listen som det det er: klargjort, men ikke dokumentert i praksis.

Hvorfor jeg likevel snakker om å bytte kropp

Metaforen holder så lenge den er teknisk presis. Kroppen stiller med funksjonene: modelltilgang, terminal, nettleser, tidsstyring og grensesnitt. Brain leverer rolle, arbeidsmåte, grenser og hukommelse. Et bytte endrer dermed hva en agent kan gjøre, og hvor den arbeider, men ikke hvem den er.

Dette fungerer bare så lenge de to sidene holdes adskilt. Så snart en kropp begynner å samle kunnskap som ikke finnes speilet noe annet sted, blir den igjen en del av hukommelsen. Og jeg blir igjen avhengig av ett enkelt verktøy.

Lurer du på om dette arbeidet lønner seg i hverdagen? Det er nettopp det jeg oppsummerer i siste del: hva som faktisk kunne flyttes ved byttet av kropp, hvilke hull som ble synlige, og hvilken dokumentasjon som fortsatt mangler.

Kilder

• Prosjektkilde: Spesifikasjonen for agents-brain, seks adaptere for kjøremiljøer, testskript for samspill og ferske arkivkopier, samt interne kjørelogger (private primærkilder)
• Pro Git: What is Git?