Tillbaka till bloggen
8 min läsning

Fem minuters avstämning med mitt företag av AI-agenter – från sidlinjen på fotbollsplanen

Isak La Fleur EngdahlAv Isak La Fleur Engdahl

Det här är en uppföljning till imfund: två personer och ett helt företag av AI-agenter.

Lördag förmiddag. Sol, blå himmel och min dotters lag som värmer upp på konstgräset. Jag var där för att titta på matchen, med en kaffe i handen och mobilen i fickan.

Samtidigt, hemma, höll en Linux-server arbetet i gång utan mig.

Vad som har ändrats sedan sist

I förra inlägget beskrev jag hur imfund är organiserat: två personer i styrelsen och ett företag av AI-agenter i Paperclip, var och en med chef, arbetsbeskrivning, schema och budget. Den här gången vill jag visa hur det ser ut en vanlig lördag.

Sedan dess har företaget vuxit från 16 till 19 agenter: 11 i byggflödet, 6 som kallas in vid behov och 2 som är pausade tills färdplanen når deras arbete. Var och en har en chef och körs i antingen Claude Code eller Codex.

Se den senaste uppsättningen – alla agenter, hur en uppgift rör sig och varje arbetsbeskrivning →

imfunds agentuppställning: Isak och Mauricio i styrelsen, 11 agenter i byggflödet, 6 vid behov och 2 pausade – varje kort visar agentens miljö och modell och vem den rapporterar till
Den aktuella uppställningen – 19 agenter, var och en med miljö, modell och chef. Klicka för att öppna hela uppsättningen.

Två saker är nya.

1. Det går av sig självt. Paperclip körs nu på min Ubuntu-server hemma. Agenterna vaknar på händelser: när ett kort godkänns vaknar stabschefen (Chief of Staff) inom några sekunder och lämnar det vidare till arkitekten; när en uppgift är klar väcks nästa agent i kedjan; en kommentar väcker den agent den riktas till. Ett litet återställningsskript körs var 15:e minut och startar om agentkörningar som har fastnat eller tappats bort på vägen. Agenterna plockar sina kort, skapar brancher, skriver kod, kör kontrollerna och öppnar pull requests. Jag behöver inte vara där för något av det.

2. Jag kan prata med det från mobilen. Jag skapade en Telegram-bot med BotFather och kopplade den till Paperclip. Stabschefen har nu ett eget Telegram-konto.

Profilen för Telegram-boten ”Chief of Staff - imfund”, som beskrivs som en bot kopplad till Paperclip
Stabschefen i Telegram – en bot kopplad till Paperclip.

En snabb koll i första halvlek

Klockan 10:46, under ett avbrott i spelet, tog jag fram mobilen och skickade ett enda meddelande:

Please give me a general status update on what agents are working on right now.

En minut senare kom svaret:

En Telegram-chatt där stabschefen rapporterar vilka kort Engine Engineer, Console Engineer och Release Engineer arbetar med, var och en med en pågående agentkörning
Statusrapporten i Telegram: vem som jobbar med vad, med länk till varje kort.

Backendutvecklaren (Engine Engineer) byggde ett sätt för en administratör att ladda upp och kontrollera ett exempelutdrag innan det importeras. Konsolutvecklaren (Console Engineer) arbetade med att stämma av portfölj- och serievärden mot fondadministratören. Releaseansvarige (Release Engineer) såg till att databasändringar på en branch hålls borta från den delade databasen. Varje punkt länkade till sitt kort, och bakom varje kort fanns en pågående agentkörning.

Det var hela interaktionen – högst fem minuter. Ingen laptop, ingen VPN, ingen dashboard. En fråga i klartext, ett svar i klartext, och sedan åkte mobilen tillbaka i fickan. Allt rullade, inget behövde mig, så jag fortsatte titta på matchen.

Vad jag kan göra från Telegram

Poängen är inte att jobba från sidlinjen, utan att snabbt kunna stämma av läget utan att öppna en laptop. Från chatten kan jag:

  • Be om status – vad som pågår, vad som är blockerat och vad som är klart.
  • Se öppna kort – tavlan grupperad efter status, med det senast avslutade arbetet överst.
  • Läsa ett helt kort – /conversation IMF-1073 ger mig hela beskrivningen och alla kommentarer, äldst först.
  • Skapa ett kort – /create lägger till en ny uppgift på tavlan, märkt så att alla ser att den kom från mig via Telegram, och placerar den i Triage.
  • Skicka en bild – till exempel en skärmdump av en bugg, som bifogas i konversationen så att stabschefen kan titta på den.
  • Be stabschefen att jobba med något – och föra en dialog om det, där konversationen minns mellan meddelandena.

Skyddsräckena

Att ge en AI-agent ett telefonnummer låter riskabelt, så samma tänkande kring styrning som i förra inlägget gäller här:

  • Bara jag kan prata med den. Boten svarar ett enda Telegram-användar-ID i en enda grupp. Alla andra ignoreras.
  • Token är en hemlighet. Botens token lagras som en hemlighet i Paperclip och hamnar aldrig i en agents kontext.
  • Att prata är inte samma sak som att göra. Stabschefen kan svara fritt på frågor, men nytt implementationsarbete går först genom Triage. Om jag bara ställer en fråga säger den uttryckligen att den inte har startat eller delegerat något.
  • Agenterna mergar – men bara genom en strikt spärr. Mauricio och jag bestämmer vad som ska byggas. När ett kort väl är godkänt tar agenterna det hela vägen till produktion själva, merge inräknat. Det är bara säkert tack vare granskningskedjan nedan.
  • Agenterna kan inte ändra sina egna regler. Deras instruktioner ligger i ett separat repository som de saknar skrivrättighet till.

Vägen till produktion

Att låta agenter merga sin egen kod låter djärvt. I praktiken måste varje ändring passera en lång kedja av kontroller, och varje länk i kedjan är en annan agent:

  1. Bevis före granskning. Arkitekten måste visa bevis för varje acceptanskriterium före den första granskningen. En ändring som påverkar det användaren ser testas i en riktig webbläsare av testansvarige (QA & Test Engineer), med skärmdumpar. En ändring av en finansiell siffra måste klara facit byggda på exempel som Mauricio har godkänt, kontrollerade av den finansiella testaren (Financial QA Engineer).
  2. Fyra obligatoriska CI-kontroller. Lint, typkontroll och enhetstester för backend; integrationstester mot en riktig PostgreSQL-databas; lint, typkontroll, bygge och databastester för konsolen; och en kontroll av dokumentationen. Alla fyra måste vara gröna.
  3. En oberoende kodgranskning. Kodgranskaren – en agent som inte har skrivit koden och inte rapporterar till kedjan som gjorde det – letar efter buggar, brutna regler och saknade tester. Den får bara godkänna den senaste committen, och varje ny push upphäver godkännandet.
  4. En andra, separat granskning av åtkomst och data. Om en ändring rör inloggning, roller, kunddata, exporter, AI-promptar eller hemligheter granskar även behörighetsgranskaren (Authorization Reviewer) den, oberoende av kodgranskaren. En kunds data får aldrig nå en annan kund.
  5. GitHub upprätthåller reglerna – utan undantag. Branchen måste vara uppdaterad mot master, alla granskningstrådar lösta och godkännandet givet på den sista pushen. Inte ens jag kan kringgå det.
  6. En release i taget. Releaseansvarige (Release Engineer) kontrollerar alla spärrar igen, plus driftsättningsanteckningarna för eventuella manuella steg, och mergar först då – en pull request i taget.
  7. Kontroller i produktion. Exakt den commit som klarade CI driftsätts till backend, bakgrundsjobben och konsolen. Releaseansvarige följer varje driftsättning och röktestar konsolen. Om något fallerar diagnostiserar plattformsansvarige (Platform & Reliability Engineer) felet och kan rulla tillbaka; ett kodfel backas genom en ny, granskad pull request. Bara om produktionen förblir trasig når det stabschefen – och vid behov mig.

Så ingen människa trycker på ”merge”. Men ingen ändring når produktion utan att ha passerat minst tre olika agenter – och upp till sex – fyra automatiska kontroller och en regelbok som ingen kan kringgå.

Slutresultatet

Efter matchen tog jag en snabb titt i GitHub-appen. Den visade sju pull requests som mergats under de senaste timmarna: import av kontoutdrag med förhandsgranskning och dubblettkontroll, avstämning av portföljvärden, en fix för databasändringar på brancher, fastnade bakgrundsjobb, testdata för mäklarkorrigeringar, hantering av marknadskalendrar och en fix för typsnitt i PDF:er. Alla med godkända granskningar och gröna kontroller.

GitHub-appen i mobilen som visar sju mergade pull requests från de senaste två till fyra timmarna, alla med godkända granskningar och kontroller
Sju pull requests mergade under förmiddagen – alla granskade och med gröna kontroller.

Och på planen? De vann med 5–2. ⚽

Jag missade inte ett enda mål.

Vad jag har lärt mig

Den intressanta förändringen är inte att agenterna skriver kod. Det är att arbetet fortsätter när jag inte är där – och att jag inte behöver undra hur det går. En kort statusrapport i mobilen räcker för att veta att inget har fastnat. Det riktiga arbetet – att sätta prioriteringar och granska det som kommer tillbaka – gör jag fortfarande vid skrivbordet, när jag själv väljer det.

Det fungerar bara för att styrningen finns på plats: tydligt ägarskap, kort som bara människor släpper ut ur Triage, en granskningskedja som ingen kan kringgå och ett spår av vad varje agent har gjort. Det är samma princip som jag arbetar med inom masterdata och datamigrering – när reglerna och spårbarheten finns kan man kliva bort från tangentbordet med gott samvete.

Det finns fortfarande mer att göra. Jag har ännu inte testat hur väl stabschefen delegerar nytt arbete hela vägen från Telegram, och Mauricio ska också få tillgång till boten. Men fem minuters avstämning och sedan full uppmärksamhet på min dotters match – det är precis så jag vill att det ska fungera.

Nyfiken på hur AI-agenter skulle kunna arbeta i din egen verksamhet – med rätt styrning från början? Hör av dig.