imfund: två personer och ett helt företag av AI-agenter

Vid sidan av mina konsultuppdrag genom BBIMP är jag med och bygger imfund tillsammans med Mauricio Garcia, som driver bolaget. imfund är en plattform för fond- och kapitalförvaltare som täcker portföljförvaltning, risk, compliance och fondadministration, med AI-agenter inbyggda i produkten – alltid under mänsklig kontroll.

Det ovanliga med imfund är inte bara produkten, utan hur den byggs. Vi är två personer. Resten av organisationen består av AI-agenter.

Se hela organisationsschemat, husreglerna och alla arbetsbeskrivningar → (på engelska)

Ett organisationsschema, inte en prompt

De flesta lösningar med "AI-agenter" är i praktiken en enda assistent med en lång prompt. imfund är i stället organiserat som ett företag. Agenterna körs i Paperclip, ett ramverk med öppen källkod för att styra och samordna AI-agenter – en så kallad meta-harness. Paperclip fungerar som kontoret: organisationsschema, ärenden, schemalagda väckningar, budgetar, godkännanden och en logg som inte går att ändra i efterhand.

Varje agent har det som en nyanställd skulle få:

• En chef. Engine-utvecklaren rapporterar till arkitekten, som rapporterar till stabschefen, som i sin tur rapporterar till styrelsen – Mauricio och mig.
• En arbetsbeskrivning. Uppdrag, ansvar, vilken åtkomst agenten har, vad "klart" betyder – och en lista över sådant den aldrig får göra.
• Ett schema (heartbeat). När agenten vaknar: när den får ett ärende, varje morgon kl. 07.00 eller, för driftagenten, var femtonde minut medan den amerikanska börsen är öppen.
• En budget. Ett månatligt kostnadstak, så att en agent som hamnar i en loop aldrig kan kosta mer än ett känt belopp.

I dag är 16 agenter i gång, fördelade på fem avdelningar: Utveckling, Säkerhet & ISMS, Produkt & domän, Kunder & tillväxt samt Ekonomi & drift. Bland dem finns en arkitekt, utvecklare för backend och konsol, en testare, en oberoende kodgranskare, en produktchef, en riskanalytiker, en compliance-analytiker och en marknadsanalytiker.

Rekrytering i faser – som i ett vanligt företag

Organisationen växer i tre faser, i takt med behovet, precis som ett företag med anställda:

1. Fas A – nu. Kärnan: stabschef, arkitekt, utvecklare, test, kodgranskning, säkerhet och produktledning.
2. Fas B – de första kunderna. Drift, integrationer, dokumentation, fondadministration, risk och compliance – och därefter onboarding och försäljningsstöd när den första kunden är på plats.
3. Fas C – hela produkten. Handelssystem, datahantering, utvärdering av AI-modeller, dataskydd, support och innehåll.

Regeln är enkel: en agent anställs först när det finns en kö av ärenden som väntar på den. En agent utan uppgifter kostar ändå pengar varje gång den vaknar.

Det här beslutar bara människor

Det här är den del jag tycker är viktigast. Agenterna utför arbetet – men alla beslut som innebär ansvar ligger kvar hos oss människor.

• Jag anställer agenter, sätter deras budgetar och delar ut behörigheter.
• Mauricio har kundkontakten, sätter priser och datum och godkänner allt som en kund ska läsa.
• Tillsammans väljer vi vilka kort agenterna får börja på, godkänner färdigt arbete och slår ihop koden till master – det är först då den går ut i produktion. Vi sätter också bolagets mål och fattar beslut i allt som är reglerat. Frågor om juridik, skatt och redovisning går dessutom alltid till en kvalificerad extern expert.

Ingen agent kan skapa en annan agent, pusha kod direkt till produktion, mejla en kund eller ge ett slutgiltigt svar i en reglerad fråga. Allt sådant stannar som utkast tills en människa har granskat det.

Från Triage till Done – med människan kvar i loopen

I praktiken syns samarbetet tydligast på projekttavlan i Jira. Varje kort går igenom samma fem kolumner, och det är tydligt uppdelat vem som får flytta det vidare:

1. Triage. Här hamnar nya idéer, buggar och önskemål. Agenterna hjälper till att skriva korten – med acceptanskriterier, öppna frågor och beroenden – så att de blir tydliga nog att bygga.
2. To Do. Det är Mauricio eller jag som flyttar ett kort hit, när vi bedömer att agenterna kan börja på funktionen. Inget arbete startar innan dess.
3. In Progress. En agent tar ett kort från To Do och flyttar det hit när den börjar arbeta. Arbetet sker på en egen gren i koden, aldrig direkt på master.
4. In Review. När agenten är klar – med tester, verifiering och en kommentar om vad som gjorts – flyttar den kortet hit och öppnar en pull request. Koden granskas först av en agent från den andra modellfamiljen.
5. Done. Bara en människa kan flytta ett kort hit. Mauricio eller jag kontrollerar resultatet, godkänner det och slår ihop agentens gren till master.

Agenterna gör alltså det mesta av jobbet, men de två viktigaste besluten – vad som ska byggas och när något är färdigt – fattas alltid av en människa.

Husreglerna

Varje agents instruktioner inleds med samma tio husregler, före själva arbetsbeskrivningen. Några av dem:

• Arbeta bara utifrån ärenden. Inget arbete börjar på ett kort som inte har prioriterats.
• Pusha aldrig direkt till master. Öppna en pull request och låt en människa godkänna den.
• Den som skriver koden granskar den aldrig. Kod från den ena modellfamiljen granskas av den andra.
• Ingen kunddata som standard. Bara när en människa har öppnat en supportbehörighet – och bara för just det ärendet.
• Håll budgeten. Har du fastnat två gånger på samma steg? Stanna och eskalera i stället för att försöka om och om igen.
• Lämna bevis. Varje körning avslutas med en kommentar: vad som ändrades, vad som verifierades, vad som inte verifierades och vad nästa steg är.

Två modellfamiljer – med avsikt

Agenterna körs i två olika miljöer: Claude Code för arkitektur, backend, säkerhet, produkt, design, drift och risk, och OpenAI:s Codex för konsolen, integrationer, test, kodgranskning och flera analytikerroller. Uppdelningen är medveten. När den som skriver och den som granskar kommer från olika modellfamiljer har de inte samma blinda fläckar – av samma skäl som en utvecklare inte ska godkänna sin egen ändring.

Här är det också viktigt att skilja på två sorters AI. Tradingdesken och portföljförvaltaragenten i imfund är funktioner i produkten. De styrs av kundens mandat och av en regelmotor, inte av organisationsschemat. Bolagets agenter bygger och testar dem, men agerar aldrig i deras ställe.

Hermes Agent – portföljförvaltaren

Portföljförvaltaren i produkten körs på Hermes Agent, en AI-agent med öppen källkod från Nous Research, släppt under MIT-licens. Till skillnad från kodverktyg som Claude Code och Codex är Hermes en generell agent som är byggd för att arbeta långsiktigt och lära sig under tiden. Den har ett beständigt minne, gör om erfarenheter till återanvändbara färdigheter (skills) som den förbättrar efter hand, och kan söka i sina egna tidigare konversationer. Den klarar också schemalagda uppgifter, MCP-verktyg, flera olika exekveringsmiljöer och isolerade profiler, där varje profil har eget minne, egna färdigheter och egna inställningar.

Det är just de isolerade profilerna som gör Hermes rätt för imfund. Fondens portföljförvaltare har en egen profil som är bunden till kundens mandat, och en regelmotor kontrollerar varje beslut innan något genomförs. Ingen av bolagets agenter får röra den profilen. Hermes är också tänkt att driva flera kommande roller – onboarding, försäljningsstöd, support, innehåll och ekonomi – var och en med en egen imfund-*-profil via OpenRouter. På så sätt kan modellen bakom varje roll väljas utifrån uppgift och kostnad.

Teknikstacken

imfund bygger medvetet på ett fåtal molntjänster, så att två personer – och deras agenter – kan driva plattformen utan en egen driftavdelning.

Backend består av två Python-tjänster på Railway: Engine, med API:t, regelmotorerna och tradingdesken, och Worker, som kör bakgrundsjobb och schemalagda uppgifter. Båda använder PostgreSQL på Neon. Händelser läggs bara till – ingenting uppdateras eller raderas – vilket ger full spårbarhet från start. Tack vare Neons databasgrenar kan varje ny funktion få en egen kopia av databasen för utveckling och test, och ingen agent rör någonsin produktionsdatabasen. Kundspecifik information ligger i en egen, separat databas, skild från plattformens gemensamma data. Frontend – konsolen som kunder och administratörer faktiskt ser och arbetar i – är byggd i Next.js och driftas på Vercel, som levererar den snabbt över hela världen och driftsätter varje godkänd ändring automatiskt.

Ovanpå detta ligger agentlagret. Paperclip skriver ingen kod själv, utan organiserar agenterna som gör det: vem som rapporterar till vem, vilket ärende de arbetar med, när de vaknar och hur mycket de får kosta. Bolagets agenter körs i Claude Code och Codex, medan Hermes Agent driver agenten i produkten. Varje bolagsagent startas med en låst konfiguration – utan åtkomst till produktionsmiljöer, molnnycklar eller betalda API-nycklar.

I grunden en fråga om styrning – därför känns den bekant

Det som slår mig efter en tid med det här arbetssättet är hur lite som egentligen handlar om själva modellerna. Nästan allt handlar om styrning: tydligt ägarskap, definierade roller, regler för vem som får ändra vad, spårbarhet och åtskillnad mellan uppgifter.

Det är precis det jag har arbetat med i över tio år inom master data management och datamigrering. En golden record behöver en ägare och regler för godkännande – det gör en pull request som en agent har skrivit också. En migrering behöver avstämning för att bevisa att den blev rätt – en agent behöver lämna bevis för vad den har verifierat. imfund arbetar dessutom mot ISO 27001, och varje agent behandlas som en identitet med åtkomst: den ingår i den månatliga behörighetsgenomgången, har egna nycklar och finns med i leverantörsregistret.

Min slutsats: bra AI engineering är till största delen bra datastyrning. De organisationer som redan har ägarskap, regler och spårbarhet för sin data är bäst rustade att sätta AI-agenter i arbete på ett säkert sätt.

Funderar du på att använda AI-agenter i din egen verksamhet – ovanpå data från ERP, MDM eller en migrering? Hör av dig.