Samma agent, fyra olika verktyg

Vad du får med dig här: Du ser hur tunna adaptrar överför samma agentidentitet till olika kopplingssatser – och varför godkännanderegler måste följa med vid verktygsbyte.

För mig är en agent inte det chattfönster där jag just nu pratar med honom.

Fönstret är hans nuvarande verktyg. I Agents Brain kallar jag denna körningsmiljö för en ”harness”. Identiteten finns någon annanstans: i agentens kanoniska filer.

Denna åtskillnad gör det möjligt att byta kropp. Claude Code, Codex, Gemini och Hermes behöver olika ingångar. De ska dock inte få fyra kopior av samma persona.

För detta finns det tunna adaptrar.

Vad en adapter egentligen måste kunna göra

En adapter fungerar som länk mellan kabelnätet och styrenheten. Den innehåller så lite egen logik som möjligt.

Hans arbetsuppgifter är överskådliga:

1. hitta den standardmappen för agenter,
2. ange den obligatoriska läsordningen,
3. Uttryckligen ladda godkännandegrindar,
4. kräva att Daily Memory Write-back utförs vid sessionens slut.

Vad som inte hör hemma här: en kopierad fullständig persona, duplicerad expertkunskap eller en andra version av godkännandereglerna.

Så snart sådant innehåll hamnar i adaptern börjar avvikelsen. En korrigering görs då i Brain, men glöms bort i den gamla verktygsbeskrivningen. Vid nästa start finns det två sanningar.

Fyra verktyg, fyra broar

Adaptrarna ser olika ut beroende på vilket verktyg det gäller.

Claude-koden läser projektrelaterade instruktioner och agentdefinitioner. Bryggan hänvisar därifrån till den önskade agentmappen och dess startordning.

Codex Använd en projektbriefing. Även där är innehållet allmänt hållet: Vilken agent har ansvaret som standard, var finns hans eller hennes ”hjärna” och vad måste skrivas innan det slutgiltiga svaret ges?

Tvillingarna får en motsvarande projektfil med samma avtal i det format som förväntas.

Hermes laddar identiteten via en systemprompt eller en tunn brygga.

Syntaxen ändras. Avtalet förblir oförändrat.

Det är agentens väg som förflyttar sig, inte kopian av persona

När en Orchestrator delegerar ett arbete till en annan Harness kopieras inte personaen in i uppdraget. Istället får mottagaren instruktionen att läsa in den kanoniska agentmappen på nytt.

Det har två fördelar.

För det första är uppdraget av begränsad omfattning. För det andra laddar förberedelsearbetet den aktuella versionen – inklusive nya lärdomar och ändrade godkännandesteg.

En kopierad persona är redan potentiellt inaktuell i samma ögonblick som den skickas iväg. En hänvisning till källan är mer beständig.

Det förutsätter förstås att den andra harnessen har åtkomst till Brain. Just därför ingår åtkomstvägen i den lokala konfigurationen och inte som en fast kopplad privat väg i den offentliga adaptern.

Godkännandesteg byter inte ägare

Det viktigaste med adapterprincipen är inte persona. Det är gränserna.

Sol får förbereda texter och WordPress-utkast. Hon publicerar inget själv. Om Nox ger henne uppdrag via Codex istället för via Claude Code förändras inte denna behörighetsnivå. Inte ens en särskilt kraftfull körning får därmed någon ytterligare godkännande.

Detsamma gäller för destruktiva åtgärder, driftsättningar eller kostnadsbelagda processer som utförs av andra roller. Delegering utökar arbetsflödet. Den utökar inte automatiskt behörigheten.

Därför laddas RULES och MASTER vid varje start. En adapter som endast överför tonalitet är för begränsad. En bra adapter överför hela arbetsavtalet genom att hänvisa till dess källa.

Fyra bedömningsnivåer istället för ett sammanfattande omdöme

Att det finns fyra adapterfiler i repositoriet är inte i sig ett bevis på att en agent fungerar fullt ut i fyra verktyg. Därför skiljer jag mellan fyra verifieringsnivåer:

1. Avtal och adapter: Bron hänvisar till rätt Brain, laddar de obligatoriska filerna och hanterar godkännandeprocesserna.
2. Avtal om läsrättigheter: Harness startar faktiskt och läser in identitet, regler och minne i den angivna ordningen.
3. Återställning via en Fresh-klon: Brain kan återställas från repositoriet i en isolerad miljö, utan dolda lokala beroenden.
4. Verklig uppgift med write-back: Harness utför en verklig uppgift: den håller kvar portarna, skriver tillbaka den begärda dagliga posten och en annan körning kan sedan läsa den igen.

Dessa steg bygger på varandra. Den som blandar ihop dem förvandlar snabbt en befintlig konfiguration till ett påhittat praktiskt bevis.

Steg 1: Avtal och adapter

Repositoriet kontrollerar adapter- och agentfiler med hjälp av valideringsverktyg. Bland annat kontrolleras startsekvenser, obligatoriska filer, godkännandegrindar, Brain-Root-referenser och oönskade kopior av persona.

Sådana avtalstester upptäcker till exempel specifika namn som av misstag hamnat i portabla mallar. Lokala, personrelaterade övergångar får vara specifika. De kanoniska mallarna måste förbli generiska.

Automatiserade tester bevisar därmed filöverföringen. Inloggning, körtid och faktisk minnesåterföring kräver separata bevis.

Steg 2: Avtalet om läsbehörighet

Claude Code, en ny Codex-körning och Hermes har i separata skrivskyddade smokes laddat samma bindande startordning från samma valv. Alla tre läste samma minneskontrakt och kom fram till samma semantiska utvärdering för samma kontrollvillkor.

Därmed är det gemensamma läsavtalet för dessa tre harnesses i praktiken bekräftat. Dessa körningar var dock inget write-back-test. De visar varken en utförd verklig uppgift eller en daglig post som har skickats tillbaka till Brain via respektive harness.

För Gemini finns adaptrar och avtalstester tillgängliga. Den faktiska lanseringen med samma läsavtal är ännu inte fastställd.

Steg 3: Återställning via en Fresh-klon

Det automatiserade Recovery-Smoke-verktyget klonar repositoriet till en isolerad tillfällig katalog, skapar en utkastagent och en Claude-Bridge utifrån de riktiga mallarna och kontrollerar skriv- och återläsningen av en Markdown-Daily mellan separata processer. För detta används endast Pythons standardbibliotek och Git. Obsidian, OpenViking och de lokala Harness-kommandoradsgränssnitten saknas avsiktligt.

Den gröna Fresh-klonen visar att identitet, Gates och minnesrutiner kan återställas enbart från Vault. Den är inte ett E2E-test av en specifik testuppsättning. Den bevisar alltså varken en fullständig körning av Claude-koden eller en Gemini-start.

Steg 4: Den egentliga uppgiften med write-back

Det starkaste beviset framkommer först i det aktiva verktyget: Agenten hanterar ett verkligt uppdrag, följer godkännandesteget och skriver tillbaka den föreskrivna påminnelsen. Därefter måste en oberoende körning kunna ladda ner denna post från Brain igen.

För Claude Code, Codex och Hermes har läsbarhetsbeviset fastställts i denna jämförelse. Ingen av de tre påstås här ha någon sådan uppgifts- eller skrivåterföringsläcka. För Gemini är till och med det faktiska läsavtalet fortfarande oklart.

Det är först genom denna separata prövning som mognadsgraden för varje kabelstam kan fastställas på ett korrekt sätt. Att en grön nivå uppnås innebär inte automatiskt att nästa nivå också uppnås.

Varför jag ändå talar om kroppsbyte

Metaforen är till hjälp så länge den förblir tekniskt korrekt.

Kroppen tillhandahåller verktyg: modellåtkomst, terminal, webbläsare, cron, gateway eller användargränssnitt. Hjärnan tillhandahåller roll, hantverk, gränser och minne. En förändring påverkar förmågor och omgivning, men inte automatiskt den kanoniska identiteten.

Det fungerar bara om de båda sidorna förblir åtskilda. Så snart kroppen lagrar egen, icke-speglad kunskap blir den återigen en del av minnet.

I den sista delen gör jag en praktisk sammanfattning: Vad som faktiskt är överförbart, vilka brister som har blivit synliga och vilka belägg som fortfarande saknas.

Källor

• Projektkälla: agents-brain-specifikation, Harness-adapter, Interop-/Fresh-Clone-validerare och interna testprotokoll (privata primärkällor)
• Pro Git: Vad är Git?