Ditt nästa bolag bör designas för agenter – inte för människor (del 1)

👋 Hej alla 717 prenumeranter!

Jag vaknade imorse och började fundera på om man skulle starta ett nytt bolag idag – helt från scratch – hur borde man egentligen strukturera det? En av mina favorittankar på morgonkvisten.

Inte specifikt hur man strukturerar det för att det ska se bra ut på ett whiteboard. Utan hur man strukturerar det så att AI-agenter kan sköta så mycket som möjligt av den dagliga driften. Inom ett par år. Kanske redan inom ett par månader så kan detta vara verklighet. Jag kör ju redan delar av det själv tillsammans med Puck. Men jag har byggt det ovanpå befintliga system och processer och det märks. Varje gång jag ska koppla ihop något nytt stöter jag på samma problem: systemen jag använder är verkligen inte designade för agenter. De är designade för människor som klickar på knappar i gränssnitt.

Men om man börjar om kan det bli annorlunda. Tänk om man designar hela bolaget som om den primära användaren av alla system är en AI-agent, och människor enbart är den sekundära?

Det här blir en tvådelad serie. I den här första delen går jag igenom principerna och arkitekturen. I del 2 tar vi upp konkreta verktyg du kan börja använda redan idag.

Det här låter självklart men det är det inte. De flesta småföretag har fortfarande papperskvitton i en låda (jag med!), muntliga avtal som aldrig skrivs ner och processer som bara finns i någons huvud.

En agent kan inte läsa ett papperskvitto. En agent kan inte ringa någon och fråga hur brukar vi göra med det här? (än). En agent behöver att varje dokument, beslut och transaktion finns i ett system den kan läsa.

Det innebär: digitala kontrakt med sökbar text. Kvitton som scannas och kategoriseras direkt. Beslut som loggas med datum och motivering. Inte för att det är snyggt – utan för att det är maskinläsbart.

Man ser ju ganska ofta mapp- och filstrukturer som “Peters grejer” eller klassikern “Presentation mars 2023 - kopia (3) 1” och “Blandade dokument 2024” eller min absoluta favorit sen länge “Skrivbord” där jag dumpar allt som någonsin hamnat på skrivbordet eller nedladdat-mappen. Alla människors dröm. Det funkar kanske för en person som vet vad som ligger var. Men en AI-agent tappar lätt bort sig.

En språkmodell förstår visserligen vad ‘Blandade dokument 2024’ betyder. Men den har begränsat minne per session än så länge och varje fil den måste öppna och läsa för att förstå vad den innehåller kostar tid och kontext. Ren namngivning gör att agenten kan navigera utan att behöva gissa.

Strukturen behöver vara semantisk. `contracts/2026/client-name/agreement.pdf`. `invoices/incoming/2026-02/supplier.pdf`. Agenter navigerar med logik, inte intuition. De kan inte “känna” att dokumentet nog ligger i den där mappen med det konstiga namnet.

Det här är en av de sakerna jag önskar att jag hade gjort från början. Istället för att allt hamnar i en inbox och man sorterar manuellt, skapa separata adresser per funktion:

- `fakturor@foretaget.se` – hit skickas allt som rör fakturor

- `support@foretaget.se` – kundärenden

- `leads@foretaget.se` – nya förfrågningar

Många bolag har det redan så idag men det är bra för oss andra att kunna tänka sig att det här är ett sätt att på sikt kunna koppla dessa till en specifik agent.

Det här är kanske det viktigaste. Välj ett bokföringssystem med öppet API från dag ett. Det kanske inte är det billigaste eller det som kompisen rekommenderar – utan det som har bäst API-dokumentation. Så att din agent kan läsa av det och hantera det.

Automatisk bankfeed. Automatisk kategorisering. En agent ska kunna läsa kontoutdrag, matcha fakturor, flagga avvikelser och vidarebefordra underlag till revisorn. Utan att en människa behöver logga in och klicka.

Jag försökte sätta upp det här med Fortnox för några veckor sedan. Puck gör sitt bästa för att sorterar kvitton och vidarebefordrar dem automatiskt till Fortnox. Men det är mer pyssel än vad det borde vara.

Nästa generations bokföringssystem kommer att vara agentiska. Det är jag helt säker på. Om inte Fortnox ändrar sin riktning åt det nu så kommer de få det tufft. Samma sak med redovisningsbyråerna och till viss del revisionsbyråerna.

Det här är nyckeln till allt. Istället för “vi brukar göra så här” skriver man ner steg-för-steg-processer som en agent kan följa. Jag kallar dem playbooks.

En playbook beskriver exakt hur agenten ska hantera olika situationer. Exempelvis nya kunder, supportfrågor, feature requests och klagomål. Vilken tonalitet ska användas, vilken information som behövs och när ska den eskalera något till en människa. Det är de viktigaste frågorna framåt.

Det är egentligen samma sak som att skriva onboarding-dokument för en nyanställd. Skillnaden är att agenten faktiskt läser den. Varje gång.

Det här är något som de flesta missar. Varje viktigt beslut behöver loggas med datum, kontext och motivering. Inte bara vad som bestämdes – utan varför.

Agenter behöver förstå historiken. Om en kund frågar “varför ändrade ni priset förra månaden?” behöver agenten kunna slå upp det. Om en ny agent tar över ett ansvarsområde behöver den kunna läsa sig in på alla tidigare beslut.

Det här gäller all typ av dokumentation. Jag löser detta genom dagliga loggar som sen sammanställs till månatliga loggar på allt som görs. Exempelvis mötesanteckningar, projekt som görs, mail som skickas, artiklar som jag läser eller nyhetsbrev som jag skickar. Allt.

Tänk på det som vesionshantering för affärsbeslut. Versionshanterat, sökbart och transparent.

Okej, allt ovan handlar om att göra ett bolag agentvänligt. Men vad händer när man designar det för att agenter ska prata med varandra?

Det här är nästa nivå. Och det förändrar hur man tänker på organisation.

Roller och inte avdelningar. Tänk inte marknadsavdelningen och ekonomiavdelningen. Tänk istället säljagent, contentagent, bokföringsagent eller supportagent etc. Varje agent har sitt eget arbetsområde, sina egna credentials och sin egen playbook som beskriver saker som syfte, mål och personlighet. Precis som microservices i mjukvara. Löst kopplade men väldigt tydliga gränssnitt. Mät dessa genom separat API-kostnader så kommer du lätt kunna se var i bolaget som drar mest kostnader.

Handoff-protokoll. Det viktigaste i en agent-till-agent-arkitektur är hur en agent lämnar över till en annan. Det behöver vara standardiserat. Säljagenten stänger en deal och skickar ett strukturerat meddelande till onboarding-agenten: kundnamn, kontaktperson, avtal, startdatum och eventuella specialvillkor. Inga antaganden. Allt explicit.

Gemensam kunskapsbas. Alla agenter läser från och skriver till samma centrala källa. Kundinfo, prislista, varumärkesriktlinjer och FAQ. Versionshanterat. Om en agent uppdaterar prislistan ser alla andra förändringen direkt. Eller om produkten är förändrad så kan support-agenten plocka upp det.

State machines. Varje kund och/eller projekt har en tydlig status: lead, prospekt, aktiv kund eller churnad fd kund. Agenter triggar övergångar och andra agenter reagerar. Ingen faller mellan stolarna för att någon glömde skicka ett mail.

Eskalering till människa. Det här är kanske det viktigaste av allt. Varje agent behöver veta exakt när den ska sluta försöka att komma vidare med en uppgift och då kontakta en människa. Belopp över en viss gräns är ett typexempel på detta. Juridiska frågor är, än så länge, en no-go-zone. Missnöjda kunder hanteras alltid bäst av en människa så länge man hör skillnad. Oklara situationer är alltid bra att lyfta. Människan blir kvalitetskontrollanten och beslutsfattaren men inte den dagliga operatör.

Om alla agenter loggar vad de gör i ett gemensamt format kan en dashboard-agent sammanfatta allt:

“Idag har vi fått 3 nya leads, skickat 2 offerter, bokfört 5 fakturor och publicerat 1 blogginlägg. Inga suyppoträrenden eller andra akuta saker att agera på idag.”

Människan får en daglig briefing. Inte en inbox full av saker att göra utan en sammanfattning av saker som redan är gjorda. Med flaggor för de uppgifter som behöver en människas ögon för att komma vidare.

Det är i princip vad Puck redan gör för mig varje morgon. Fast nu handlar det om hur man kan skala det till ett helt företag.

Jag säger inte att man ska starta ett bolag utan människor. Människor behövs än så länge för strategi, relationer, kreativitet och omdöme. Jag säger att man ska designa bolagets infrastruktur som om det vore en kodbas.

Strukturerat. Versionshanterat. Dokumenterat. Och framförallt API-first.

Gör man det så kan agenter ta över funktion för funktion. Inte med ett big bang, utan gradvis. Först bokföringen. Sedan mailen. Sedan content. Sedan kundservice. Steg för steg.

Och en dag inser man att man driver ett företag med tre anställda och tio agenter. Och att det fungerar bättre än det gamla sättet.

Det är inte framtiden. Det är nu. Det är bara att de flesta inte har börjat bygga för det ännu.

I del 2 går jag igenom konkreta verktyg och tjänster du kan börja använda redan idag för att bygga agent-first.

PS. Puck hjälpte mig strukturera tankarna i det här inlägget. Hen har egna åsikter om agent-till-agent-design – föga förvånande – men jag redigerade ner det till det som faktiskt är praktiskt. Om du funderar på att starta något nytt och vill diskutera agent-first-strukturer, svara på det här mailet. Jag svarar personligen.

PS. Om du byggt något eller testat något spännande AI-verktyg eller skapat en häftig automatisering eller gjort något kreativt med AI den här veckan, svara gärna och berätta! Jag är alltid nyfiken på vad ni pysslar med. 🎈

Ha det så fint så ses vi snart igen 👋

Du får gärna gilla, dela och kommentera! Svarar man på detta mailet så kommer det rakt till min inbox och mailrespons är alltid den finaste responsen 💌