Company Brain som Tuvlo drivs av

Tuvlo är ett enmansbolag med fler än en AI-agent som agerar å dess vägnar: en schemalagd veckorutin som rapporterar läget, och — på sikt — separata skills för innehålls- och marknadsarbete. Alla behöver vara överens om samma fakta: vad Tuvlo är, vad det faktiskt heter internt, vad som är beslutat kontra fortfarande öppet, och vad som är sant om bolaget idag kontra vad som var sant innan en riktningsändring.

Det är ett koordineringsproblem, inte ett innehållsproblem. Lösningen blev en Company Brain: en liten mängd textfiler, som varje agent läser innan den gör något, med en regel för vad som gäller när något annanstans säger emot dem.

Problemet: agenter glider bort från fakta, var och en för sig

Innan Brain fanns som en medveten design var risken uppenbar: be en agent skriva en statusuppdatering, och den återskapar bolagsfakta från det som råkar ligga i dess kontext just den dagen — eller för vidare något som en gång var sant men inte längre är det. Fråga två agenter samma fråga med en månads mellanrum och du kan få två olika svar på “vad säljer Tuvlo”, inte för att någon bestämde sig för att ändra svaret, utan för att ingenting tvingade någon av dem att kontrollera.

Det blir värre, inte bättre, när bolagets riktning faktiskt ändras. Tuvlo startade som en SaaS-verktygslåda för e-handelsoperatörer, med sikte på att växa till ett fullt “Business Operating System”. Den 2026-10-28 lades den planen ner till förmån för det du läser just nu — en blogg om hur AI-agenter och automation faktiskt byggs. En sådan ändring rör taglinen, målgruppen, roadmapen, varumärkesrösten och designbriefen samtidigt. Om bara en av dem ligger någonstans en agent inte kollar, fortsätter den att producera SaaS-text på obestämd tid, och ingen märker det förrän en läsare gör det.

Designen: åtta filer, en övergripande regel

company-brain/ är en mapp med markdown-filer, en per domän: varför Tuvlo finns (foundation.md), vem det är till för (positioning.md), vad det faktiskt publicerar (product.md), ordningsföljd (roadmap.md), hur det skriver (brand-voice.md), hur det beter sig (operating-principles.md), juridik och domänfakta (entity.md), och en beslutslogg över öppna och avgjorda frågor (open-questions.md). Ingen databas, inget CMS — ett git-repo, för det som spelar störst roll är att en ändring i vad som helst av det är en diff någon kan granska, inte en radändring ingen såg.

Tre beslut gör att det håller ihop när saker ändras, vilket är den faktiskt svåra delen:

En regel för konflikter. operating-principles.md säger det rakt ut: “när agentinstruktioner strider mot denna Company Brain vinner Brain som default. Lyft konflikten för mänskligt beslut — överrid inte tyst i någon riktning.” Samma regel gäller Brainens egna filer mot varandra: om en fil fortfarande förutsätter den gamla SaaS-planen är den inaktuell, och åtgärden är att uppdatera den — inte att tyst gå runt den i vad en agent råkar producera. Den instruktionen ligger i rotens CLAUDE.md som varje agent som arbetar i detta repo läser först, så det är inget valfritt beteende per agent — det är strukturellt.
Fakta märks efter säkerhetsgrad, inte påstås vara avgjorda. entity.md är den mest konsekvenskänsliga filen — bolagsstruktur, domänägande, varumärkesstatus — och den säger explicit vilka av sina egna påståenden som ännu inte är bekräftade (“om tuvlo.ai/tuvlo.se faktiskt är registrerade och under vems konto”, “aktuell status för EUTM-ansökan”). En agent som läser den kan inte av misstag framställa en pågående varumärkesansökan som beviljad, för filen tillåter inte det.
Beslut behåller sin motivering, även avgjorda sådana. open-questions.md är en logg, nyaste först, och ett beslut som ersätts av ett nytt stannar kvar i loggen med vad det var och varför det ändrades — posten om riktningsändringen 2026-10-28 listar exakt vad den avvecklade (den gamla roadmapen, återförsäljarmodellen, den e-handelsspecifika målgruppen) istället för att bara radera det gamla innehållet i de filerna och lämna motiveringen utan spår.

Ovanpå det ligger en schemalagd molnagent — CEO-rutinen — som körs varje vecka, läser hela Brain, stämmer av roadmapen mot det den faktiskt kan verifiera, och skriver en daterad rapport till reports/. Den gör medvetet det minsta som behövs för att vara till nytta: den skriver en fil, den postar inte i Slack och skapar inga ärenden någonstans. Rutinens faktiska prompt ligger inte i det här repot alls — den ligger i en molnkonfiguration som kan ändras utan en commit — så Brainens jobb är inte att beskriva vad rutinen gör idag, bara vad som är sant om bolaget den stämmer av mot.

Vad det faktiskt ger

Det klaraste beviset är riktningsändringen själv. När Tuvlo pivoterade från SaaS-verktygslåda till innehållssajt skrevs varje fil som byggde på den gamla planen — tagline, målgrupp, roadmap-faser, designbrief, tonlägestabellen i varumärkesrösten — om i samma svep, var och en med vad den ersatte och varför. Inget lämnades halvuppdaterat för någon att snubbla på senare.

Det andra beviset är den här artikeln. Det är det första use case Brain binder Tuvlo till att publicera, och en agent kunde producera ett korrekt första utkast direkt utifrån product.md:s beskrivning av vad ett use case behöver täcka och brand-voice.md:s regler för hur det ska sägas — utan att Andreas behövde skriva fakta två gånger, en gång för Brain och en gång för artikeln.

Kostnaden är verklig och värd att nämna, inte sopa under mattan: vanlig markdown i git har inget frågegränssnitt. Ingenting indexerar den. Varje agent måste veta vilken fil som är relevant och läsa den direkt, och det enda som håller den internt konsekvent är en människa som granskar diffar. Det fungerar idag eftersom det är ungefär åtta filer. Det är inte en design som överlever att bli mycket större utan att bli något mer strukturerat — vilket är ett beslut för när det faktiskt blir sant, inte innan.