Altu Central Command: vårt eget CRM, byggt för att en AI-agent ska kunna arbeta i det
Gustav Brochmann
Altu Central Command är det system vi driver Altu på: kunder, kontakter och säljpipe, prospektering, kvitton och utlägg som bokförs i Fortnox, projekt, tidrapporter, kalender och mail – i en applikation vi äger. Ovanpå ligger ett lager med 47 verktyg som exponeras via Model Context Protocol (MCP), så att var och en i teamet kan låta Claude läsa och arbeta i systemet som sig själv. Varje ändring av befintlig data går till en godkännandekö som en människa hanterar. Systemet är byggt för flera organisationer och är den grund vi bygger kunders system på.
Varför vi byggde det själva
Vi började som alla andra: ett CRM i molnet, kvitton i en app, projekt i en tredje, prospektlistor i kalkylark, och mail och kalender hos Google. Varje verktyg var bra på sitt, men ingen fråga som spände över två av dem gick att svara på utan handpåläggning. ”Vilka kunder har vi fakturerat men inte pratat med på ett kvartal?” krävde tre exporter och en eftermiddag.
Vi ville också kunna ge en AI-agent tillgång till hela bilden – och det är i praktiken omöjligt när datan ligger i sex system med sex behörighetsmodeller. Så vi byggde ett system som äger datan, och som från dag ett var tänkt att kunna läsas och skrivas av både människor och agenter.
Vad systemet gör
- CRM. Bolag, kontor, kontakter, aktivitetslogg och säljpipe. Inkommande leads från altu.se hamnar direkt i en inkorg med push-notis till teamet.
- Prospektering. Prospekt med kontakter, kvalificering mot vår idealkundsprofil, och ett klick för att lyfta ett prospekt till CRM:et.
- Ekonomi. Kvitton fotograferas eller laddas upp, dubblettkontrolleras, blir utlägg som godkänns av en administratör och bokförs i Fortnox.
- Projekt och tid. Projekt med logg och filer, tidrapportering och statistik per person och kund.
- Kalender och mail. Google Kalender och Gmail speglas in i systemet så att möten och trådar kan kopplas till bolag och kontakter – och läsas av agenten.
- Sök över allt. Dokument, anteckningar och mötesunderlag är vektorindexerade i Postgres (pgvector), så både människor och agenten kan ställa frågor i fritext.
- Presentationer. Offert- och pitchunderlag genereras ur CRM-datan och presenteras direkt i systemet.
MCP-lagret: så får Claude arbeta i systemet
Allt som går att göra i gränssnittet finns också som funktioner i serverkoden. De 47 viktigaste är registrerade som verktyg – med namn, beskrivning, indata och en klassning som läsning, skrivning eller borttagning – och exponeras över MCP på en enda slutpunkt. Den som vill kopplar upp Claude mot systemet under Anslutningar, loggar in med sitt vanliga Google-konto och godkänner vilka rättigheter anslutningen får.
- Varje anrop är en person. Slutpunkten skyddas med OAuth 2.1. Ett åtkomsttoken pekar på en verklig användare med dennes roll, så agenten kan aldrig mer än den som startade den. En anslutning kan återkallas när som helst utan att påverka någon annans.
- Läsning är fri, skrivning är styrd. Alla skrivningar går genom ett gemensamt lager: ett tomt fält fylls i direkt; ett befintligt värde som skulle ändras hamnar i en godkännandekö; borttagningar köas alltid. Kön är en sida i systemet där en administratör ser före- och eftervärden och godkänner eller avslår. Varje beslut loggas, även det som gick igenom direkt.
- Rättigheterna sitter på verktyget, inte i databasen. Servern arbetar med fulla rättigheter mot databasen, så verktygsklasserna och anslutningens omfattning (läs, skriv, ta bort) är den enda spärren. Det är därför registret är den enda platsen verktyg definieras på – det finns ingen bakväg.
- Ingen modell körs hos oss. Resonemanget sker i Claude Desktop eller Claude Code hos användaren. Vår server tillhandahåller verktyg och data, aldrig intelligens. Det håller driftkostnaden nära noll och betyder att kunddata bara lämnar systemet när en användare själv ber om det.
Hur det är byggt
Next.js i TypeScript, Supabase (Postgres med radnivåsäkerhet och pgvector) i EU-region, Vercel för drift, Anthropics Claude för AI-funktioner. All dataåtkomst går genom ett serverlager som klienten aldrig kringgår. Databasen har byggts ut i över 70 versionerade, återkörbara migrationer sedan starten – systemet växer i steg, inte i omskrivningar.
Under hösten 2026 gjorde vi systemet fleranvändarbolag: organisationer, roller, inbjudningar och OAuth-anslutningar är separerade per organisation, så att samma installation kan köra för flera bolag med vattentäta skott emellan. Det som började som vårt interna verktyg är den grund vi bygger kunders system på.
Vad vi lärde oss
- Bygg godkännandekön först. Den är enkel att lägga till innan agenten finns och obehaglig att lägga till efter första felaktiga skrivningen.
- Färre, bättre verktyg. Modellen väljer sämre ju fler nästan likadana alternativ den ser; vi har slagit ihop verktyg oftare än vi delat dem.
- Låt varje agentanrop vara en person. Delade API-nycklar gör loggen värdelös och återkallelse omöjlig.
- Äg datan innan du kopplar AI till den. Det är samma slutsats som i vår text om MCP för svenska bolag, och det är därför vi bygger system, inte bara agenter.
Vi bygger den här typen av system – och det här MCP-lagret – åt kunder, på deras egna databaser eller på den grund Central Command utgör. Hör av er om ni vill se det live.