Agentic ERP, byggt inifrån och ut
Skillnaden mellan en chattruta och en agent är verktygen och var de kommer ifrån. Agentens verktyg är systemets egna kommandon, märkta i koden: 236 queries och 409 åtgärder, med samma behörigheter och samma spårbarhet som gränssnittet.
Verktyg tillgängliga för agenten
200+ uppslag · 350+ åtgärder
Hela uppsättningen i chatten, ett urval via MCP · Godkänns var för sig · Loggas som allt annat
Grunderna
Vad är agentic ERP?
Agentic ERP är ett affärssystem där en AI-agent kan utföra arbete i systemet, inte bara svara på frågor om det. Agenten har systemets egna kommandon som verktyg: den söker fram underlaget, väljer åtgärd och kör den med den inloggade användarens behörigheter. Skillnaden mot en vanlig AI-chatt är att svaret blir en ändring i systemet.
Begreppet växte fram när språkmodeller fick verktyg. En modell som bara kan läsa och skriva text kan förklara hur man lägger en inköpsorder. En modell som kan anropa funktioner kan lägga den. Det ena sparar dig ett sök, det andra sparar dig arbetsmomentet.
Just nu kallar de flesta leverantörer sin AI för agentic, och orden agentic AI i ERP, AI-agenter i affärssystemet och agentic ERP används om vartannat. Det är därför kravlistan nedan finns: fyra saker som går att kontrollera hos vem som helst, oavsett vad marknadsföringen säger.
Vill ni först reda ut termerna finns korta definitioner i ordlistan för agentic ERP och MCP.
Utvärdering
Fem krav att ställa på ett agentic ERP
Frågorna fungerar mot vilken leverantör som helst, och de går att svara på med ja eller nej. Våra egna svar står i den gröna rutan under varje krav.
Systemets funktioner måste finnas som verktyg
En agent kan bara göra det den kan anropa. Om AI:n bara har läsåtkomst till en databas eller en söktjänst kan den sammanfatta, men inte arbeta. Kravet är att kommandona (skapa order, lägg offert, boka frakt, stäng ärende) går att kalla på som verktyg.
I Fluit
236 queries och 409 kommandon är märkta för agenten i koden, på samma handlers som gränssnittet anropar. En ny funktion blir ett agentverktyg genom att märkas där den skrivs, i stället för genom ett integrationslager som ska hinna ikapp. Chatten inne i Fluit ser hela uppsättningen; MCP-kopplingen får ett urval, där navigationsåtgärder och rena UI- och konfigurationskategorier hålls utanför eftersom de inte gör nytta för en assistent utan gränssnitt.
Behörighetsmodellen måste gälla agenten
Kör agenten med en egen servicebehörighet ser den allt, och då blir en fråga från en säljare en genväg till inköpspriserna. Fråga vem agenten agerar som. Svaret ska vara den inloggade användaren, inte systemet.
I Fluit
Assistenten agerar som den inloggade användaren. Det du inte får se i gränssnittet får du inte heller ut via chatten, och varje företags data ligger i ett eget databasschema.
Loggen måste skilja agenten från människan
Det räcker inte att ändringen syns. Frågan en revisor ställer först är vilka av förra kvartalets prisändringar en agent gjorde och den går inte att besvara om agentens rad ser likadan ut som en människas. Ett ERP är räkenskapsinformation, och varje ändring ska gå att härleda till en ansvarig.
I Fluit
Varje rad i aktivitetsloggen bär vem som utförde ändringen och på vems mandat: agentens namn plus den användare vars behörighet den använde. Dessutom loggas varje verktygsanrop i en agentliggare, även rena läsningar, annars kan en integration med enbart läsrätt gå igenom hela kundregistret utan att lämna spår. Anropet och de fält det ändrade delar ett korrelations-id, så det går att gå från ett samtal till dess effekter och tillbaka.
Det måste gå att sätta gränser i förväg
En rekommendation till klienten är ingen spärr. Protokollens destruktiv-markering är per definition rådgivande, och en klient som struntar i den möter inget motstånd. Gränsen måste sitta på servern, där den gäller likadant oavsett vem som ringer.
I Fluit
Ni sätter regler per organisation, kategori, enskild åtgärd eller namngiven agent: tillåt, kräv godkännande eller neka. En regel kan knytas till lägsta risknivå, så att kräv godkännande för allt destruktivt blir en enda rad. Stoppade åtgärder hamnar i en kö med exakt de argument agenten begärde. Godkänner ni körs den ordagrant och tillskrivs er, avslår ni körs den aldrig.
Kopplingen måste gå att öppna utåt
En agent inlåst i leverantörens chattruta är bättre än ingenting, men bolag använder redan assistenter i sitt övriga arbete. Att koppla in dem kräver ett protokoll, och i praktiken är det MCP som gäller i dag.
I Fluit
Fluit körs som MCP-server. Assistenten kopplas in med OAuth och ert vanliga Fluit-konto, utan API-nyckel, och läsning respektive åtgärder godkänns var för sig. Reglerna ovan gäller den kopplingen på precis samma sätt som chatten inne i systemet.
Fyra ytor där agenten arbetar
Två av dem sitter i systemet, en läser er e-post och en låter en assistent ni redan använder koppla upp sig. Varje yta har en egen sida med hur den fungerar i praktiken.
Agenten inne i systemet
Chatten som söker, sammanfattar och utför i er egen data.
- Vet vilken kund, order eller artikel du står på
- Söker i kunder, ordrar, artiklar, ärenden och projekt
- Skapar uppgifter, ärenden, offerter och projekt
- Kör på din inloggning och dina behörigheter
Er egen assistent, via MCP
Claude och andra MCP-klienter arbetar direkt mot Fluit.
- En URL läggs till som connector, inget att installera
- Inloggning med Fluit-kontot, ingen API-nyckel
- Läsa och utföra godkänns var för sig
- Produktdokumentationen följer med som källa
Agenten som läser inkorgen
Inkommande mejl blir ett orderförslag att granska.
- Läser e-posttext och bilagor, till exempel en order i PDF
- Matchar avsändaren mot kund eller leverantör
- Håller ihop tråden när kunden svarar
- Ordern finns först när någon har granskat och sparat
Era arbetssätt som instruktion
AI-rutiner beskrivna i text i stället för byggda i kod.
- Instruktion plus trigger-fraser som startar rutinen
- Frågar efter det som saknas: datum, kund, kvantitet
- Delas i hela företaget eller hålls personlig
- Företagsdelade rutiner följer med till MCP-klienten
Ramarna
Var gränsen går
Invändningen mot AI i ett affärssystem är sällan om den kan svara. Den är vad den kommer åt och vad den kan ställa till med.
Läsa och skriva är två olika saker
Att söka och sammanfatta är en sak. Att skapa eller ändra en post är en annan. Vid MCP-koppling godkänns de var för sig, och godkänner ni bara läsning syns inga skrivverktyg alls i assistenten.
Godkännande när ni vill ha det
Ni kan kräva att en människa godkänner utvalda åtgärder innan de körs. Regeln sitter på servern och gäller alla agentanslutningar likadant. Inkorgen jobbar redan så: tolkningen landar i status Redo för granskning och blir en order först när någon sparat den.
Ingen gräddfil förbi reglerna
Agenten anropar systemets kommandon, inte databasen. En order den skapar går genom samma kreditkontroll och samma allokering som en order någon knappar in för hand.
Spår som håller för en revisor
Aktivitetsloggen visar om raden kom från en människa eller en agent, och på vems mandat agenten arbetade. Varje verktygsanrop hamnar dessutom i en agentliggare, även läsningarna, med argument, utfall och ett korrelations-id tillbaka till de fält som ändrades.
Modellen är vårt jobb
Ni tecknar inget avtal med någon modellleverantör och installerar ingenting. Vi driftar kopplingen mot etablerade leverantörer (i dag Anthropic, Google och franska Mistral) och byter modell utan att ni behöver göra något.
Personuppgifter regleras i vårt personuppgiftsbiträdesavtal, som gäller AI-funktionerna på samma sätt som resten av systemet.
Vanliga frågor
Frågor om agentic ERP
Vad är agentic ERP?
Agentic ERP är ett affärssystem där en AI-agent kan utföra arbete i systemet, inte bara svara på frågor om det. Agenten har systemets egna kommandon som verktyg: den söker fram underlaget, väljer åtgärd och kör den med den inloggade användarens behörigheter. Skillnaden mot en vanlig AI-chatt är att svaret blir en ändring i systemet, inte en text att kopiera.
Vad är skillnaden mellan agentic AI och generativ AI i ett affärssystem?
Generativ AI producerar text: den kan förklara hur man lägger en inköpsorder, sammanfatta en kundhistorik eller föreslå ett svar på ett mejl. Agentic AI har dessutom verktyg och kan utföra åtgärden. En modell som beskriver hur du lägger ordern har svarat på frågan; en agent har lagt den.
Vad ska man kräva av ett agentic ERP?
Fyra saker, och alla går att kontrollera. Att systemets funktioner finns som verktyg och inte bara som skärmar. Att agenten agerar som den inloggade användaren, inte med en egen servicebehörighet. Att varje åtgärd hamnar i aktivitetsloggen med samma spårbarhet som ett klick. Och att kopplingen går att öppna utåt via MCP, så att en assistent företaget redan använder kan arbeta mot systemet.
Kan agenten ändra saker på egen hand?
Den utför åtgärder när någon ber om det, och bara sådana den inloggade användaren har behörighet till. Utöver det sätter ni egna regler: tillåt, kräv godkännande eller neka, för hela organisationen, en kategori, en enskild åtgärd eller en namngiven agent. Vid MCP-koppling kan ni dessutom välja att bara ge läsbehörighet, och då finns inga skrivverktyg alls.
Hur ser vi vad en AI-agent har gjort?
På två ställen. Aktivitetsloggen märker varje rad med vem som utförde ändringen och på vems mandat, så en agentändring går att skilja från att personen bakom anslutningen klickade själv. Agentliggaren listar dessutom varje verktygsanrop: tidpunkt, agent, verktyg, om det läste eller ändrade, hur det gick och hur många fält som berördes. Läsningar loggas också, annars kan en integration med enbart läsrätt gå igenom hela kundregistret utan att lämna spår. Båda finns under Inställningar → AI-agenter.
Kan vi kräva att någon godkänner innan agenten gör något?
Ja. En regel kan kräva godkännande för allt, för en kategori som Sälj, för en enskild åtgärd som annullera order, eller för allt över en viss risknivå. Kräv godkännande för allt destruktivt blir en enda rad. Stoppade åtgärder hamnar i en kö med exakt de argument agenten begärde. Godkänner ni körs åtgärden ordagrant och tillskrivs er; avslår ni körs den aldrig. Ett ärende går att godkänna i sju dagar. Värt att veta: utan egna regler tillåts allt utom det som uttryckligen är märkt att kräva godkännande, så ingenting ändrar beteende förrän ni lagt till en regel.
Ser agenten all vår data?
Den ser det den inloggade användaren ser. Behörigheterna i systemet gäller på samma sätt för agenten som i gränssnittet, och varje kunds data ligger isolerad i ett eget databasschema. En säljare som inte kommer åt inköpspriser får dem inte via en omväg genom chatten.
Vilken AI-modell körs bakom?
Vi driftar kopplingen centralt. I dag är en snabb Claude-modell standard, och i katalogen finns även Claude Sonnet, Google Gemini och franska Mistral. Ni behöver inte teckna avtal med någon modellleverantör själva. Kopplar ni in en egen assistent via MCP är det er assistent som väljer modell. Fluit levererar verktygen, inte modellen.
Vad kostar det?
AI, Inbox och automation är en tilläggsmodul som prissätts efter omsättningsnivå, från 495 kr/mån. Fluit fungerar utan den, men då finns varken chatten, inkorgen, AI-rutinerna eller MCP-kopplingen. Prislistan är publik.
Läs vidare
- AI i Fluit , hela översikten över var AI:n sitter i systemet.
- MCP-kopplingen, så kopplar ni in en egen assistent, steg för steg.
- Headless ERP: arkitekturen som gör att en agent kan nå systemet över huvud taget.
- API-dokumentationen: vägen in för integrationer som inte är AI-drivna.
- Priser : vad AI-modulen kostar på er omsättningsnivå.
Se agenten köra mot riktig data
Boka en demo så visar vi chatten, inkorgen och MCP-kopplingen i ett skarpt system. Ta med ett verkligt kundmejl så tolkar vi det på plats.