Maven Apps: Dina agenter behöver operatörer, inte kontrollpaneler

En kopplingspanel gör exakt det den har kopplats för: slå om brytaren och du får samma fasta svar, varje gång. Be den hantera något utanför den kretsen så går det inte, eftersom den inte hanterar variation, bara kablage.

En telefonist fungerar annorlunda. Ge en telefonist en begäran, koppla mig till receptionen, så listar hon ut hur: vilken linje som ska användas, vad som ska göras om den är upptagen och vad som ska göras om själva begäran var otydlig. Telefonisten för inte bara signalen vidare, utan tolkar den och agerar på den.

Maven Apps är telefonister, inte kopplingspaneler. När vi satte oss ner för att bygga ramverket som driver vår App-infrastruktur gjorde vi ett medvetet vägval: bygg inte ännu ett integrationslager. Bygg en riktig applikationsplattform och låt AI-agenter vara fullvärdiga medborgare på den.

I dag finns tusentals appar på vårt ramverk. Ja, det omfattar appar för stora tredjepartssystem som Salesforce, Zendesk och Notion. Men det omfattar också hundratals anpassade appar som körs i produktion på live-agenter.

Därför räcker inte enkla integrationer

Fråga 10 leverantörer vad ”integrerar med Salesforce” betyder för deras produkt så får du 10 olika svar, eftersom ett system som Salesforce, Zendesk eller Front aldrig bara är en sak. Det kan vara:

• Ett ställe där din agent behöver hämta information (en kunskapsbas, en ärendehistorik)
• Ett ställe där din agent behöver utföra åtgärder (skapa ett ärende, uppdatera en post, göra en återbetalning)
• En yta där din agent behöver finnas (en agent-assist-copilot i den konsol ditt supportteam redan arbetar i)

En ”Salesforce-integration” som bara känner till artiklar är inte samma produkt som en som också kan registrera ett ärende, och den är inte samma produkt som en som kan sitta i agentkonsolen som copilot. De paketeras ofta under ett och samma marknadsföringsord, och du får själv upptäcka luckorna under implementeringen.

Det är varuautomatproblemet: en fast meny som fungerar exakt som utlovat tills det du behöver inte finns på listan, och då har du redan bundit upp dig. Vi ville inte att Maven Apps skulle fungera så, så vi byggde ramverket kring den faktiska frågan som ställs (kunskap, förmåga eller kanal) i stället för kring en generisk ”connector”.

Maven Apps: mer än integrationer

Maven Apps kan ta många former, men de flesta bygger på några vanliga mönster. Några exempel på vad appar kan göra:

• Kunskapsappar läser och indexerar innehåll från ett externt system så att agenten kan svara utifrån det: skrivskyddat, versionshanterat och taggbart per målgrupp.
• Förmågeappar låter agenten faktiskt göra något i systemet: ett riktigt API-anrop, kedjat i ett arbetsflöde i flera steg (slå upp ordern, kontrollera returpolicyn, genomför återbetalningen, bekräfta för kunden), allt inom en och samma konversation. Där en bankomat kör en förskriven transaktion från en fast meny beter sig en förmågeapp mer som en personlig bankrådgivare: den tar emot ett önskat resultat, inte ett menyval, och gör det som krävs för att nå dit, inklusive att hantera undantaget.
• Kanalappar placerar agenten där dina kunder eller ditt supportteam redan finns: en inbäddad widget, ett telefonsamtal, en inkorg eller en copilot-panel i den konsol dina agenter använder varje dag.

En förbyggd app i vår katalog kan oftast installeras på några minuter. När en kunds system inte finns i katalogen är det samma ramverk – samma SDK, samma livscykelhooks, samma säkerhetsmodell – som en utvecklare använder för att bygga en egen.

Det finns ingen separat ”enterprise-nivå” av ramverket som bara våra ingenjörer använder; App Studio, vår utvecklarplattform för att bygga appar, körs på exakt samma arkitektur. Det är riktig TypeScript, ett riktigt SDK (@mavenagi/mavenagi) och en riktig driftsättningspipeline, inte ett proprietärt skriptspråk som du måste lära dig bara för vår skull.

Om du har byggt mot MCP tidigare ger en Maven App dig en liknande idé, helt förvaltad. En vanlig MCP-server innebär fortfarande att du måste sätta upp den, registrera den, hålla den igång och skala den själv. En Maven App är snarare en självregistrerande, autoskalande MCP-endpoint utan någon av den infrastrukturen kvar för dig att äga: du skriver logiken, och endpointen, autentiseringen och hostingen sköts åt dig.

Så är Apps utformade för att vara kraftfulla

En Maven App är en serverlös applikation som körs i en säker, isolerad miljö och kommunicerar med Maven-plattformen via ett definierat SDK. Konkret:

Den är multi-tenant. En app byggs en gång och installeras många gånger, i olika organisationer och för olika agenter. Varje installation får sin egen avgränsade kontext (eget organisations-ID, agent-ID och körningskonfiguration) men delar samma underliggande kod. Det innebär att när vi levererar en förbättring av Salesforce-appen gynnas alla kunder som kör den, och ingen fastnar på en föråldrad, egenhändigt byggd version av ”sin” integration.

Den är isolerad, inte påskruvad. Varje app körs som en egen funktion i en säker miljö, separat från Mavens kärnbackend och separat från andra kunders appar. Din anpassade logik körs aldrig i en delad monolit bredvid någon annans. Anslutningar ut till dina källsystem kan gå via VPN, VPC-peering, OIDC eller vanlig HTTPS med IP-tillåtelselistor – du väljer, inte vi.

Den reagerar på verkliga händelser, inte på pollningsscheman. I stället för ett nattligt synkjobb kan en app implementera händelsehooks som kallas triggers: en konversation skapades, feedback kom in, en kunskapsbas uppdaterades – och plattformen meddelar appen i samma ögonblick som händelsen inträffar. Det är en annan modell än de automationsverktyg du kanske redan känner till. En Maven-trigger är passiv: plattformen lyssnar själv efter tillståndsförändringar och skickar dem till varje app som är intresserad, utan koppling mellan appen som orsakade händelsen och appen som reagerar på den. I praktiken innebär det att en app för e-postsvar och en helt separat Salesforce-synkapp båda kan reagera på samma ”konversation uppdaterad”-händelse oberoende av varandra, var och en på sitt sätt, utan att någon av dem vet att den andra finns.

Det är samma koordineringsmekanism som en myrkoloni använder. Ingen enskild myra planerar koloniens beteende, och ingen myra skickar meddelanden direkt till en annan; en myra förändrar något i den gemensamma miljön (ett feromonspår) och alla andra myror reagerar på förändringen oberoende av varandra, var och en enligt sin egen enkla regel. Intelligensen på kolonins nivå (optimerade födosöksvägar, lastbalansering, till och med kollektiva beslut som att flytta boet) växer fram ur detta, utan central samordnare och utan att någon myra känner till planen. Maven Apps samordnas på samma sätt: en händelse förändrar det gemensamma tillståndet, och varje app som berörs reagerar på egen hand.

Den har en riktig livscykel. Varje app implementerar en liten uppsättning livscykelhooks:

• preInstall: validerar inloggningsuppgifter och konfiguration innan något går live. Om din API-nyckel är fel misslyckas installationen tydligt här i stället för i det tysta 3 veckor senare.
• postInstall: registrerar appens åtgärder och tillhandahåller de resurser den behöver när installationen har lyckats.
• executeAction: utför det faktiska arbete som en agent ber om, exponerat för kunder som en förmåga: slå upp en order, skapa ett ärende, göra en återbetalning, kontrollera ett kontosaldo.

De flesta integrationer är en strömbrytare: på eller av, inget däremellan. Våra genomgår en fullständig livscykel – installera, validera, köra, avveckla – och liknar mer en rutin som läser av sammanhanget och anpassar sig (kontrollera vad som är öppet, bekräfta vad som är säkert, agera sedan) än en brytare med 2 lägen. Det är precis den disciplin du förväntar dig av produktionsprogramvara, eftersom det är precis vad det är.

Apps kontra integrationer

En typisk integration besvarar en snäv fråga, oftast ”kan data ta sig från A till B”, och ser det som mållinjen. En Maven App är byggd för att besvara en svårare och mer användbar fråga: kan en AI-agent på ett tillförlitligt sätt veta vad som gäller i dina system just nu, och kan den anförtros att agera för din räkning när det behövs?

De flesta företagsplattformar erbjuder någon variant av ”bygg själv om vi inte har det färdigt”. Vad de sällan berättar är att bygga själv innebär att du kör din egen server och sköter din egen skalning och din egen säkerhetsgranskning, på din egen infrastruktur. Det förvandlar en enkel lucka i connector-katalogen till ett bemanningsbeslut: skaffar du en budget för utveckling och infrastruktur, eller nöjer du dig med det som finns förbyggt? Med Maven Apps tvingas våra kunder inte välja det minst dåliga alternativet. En anpassad app som du eller din utvecklare bygger körs på vår infrastruktur, med samma övervakning, skalning och säkerhetsnivå som varje förbyggd app i vår katalog. Du skriver koden, vi kör den.

Det är också därför arkitekturen kräver saker som en enkel webhook aldrig behöver bry sig om:

• Strukturerade, storleksbegränsade svar. Varje åtgärd en app utför returnerar ett tydligt svar plus strukturerad data som agenten kan resonera kring, inte en rå, obegränsad datamassa som den måste gissa sig till.
• Signerad, ömsesidig autentisering. Plattformen signerar varje förfrågan till en app så att appen kan verifiera att det verkligen är Maven som anropar, och appen autentiserar sig mot plattformen med sina egna inloggningsuppgifter. Ingen av parterna behöver lita enbart på nätverket.
• Konfiguration som valideras innan den når produktion. Eftersom preInstall körs innan en app går live fångas en felaktig inloggningsuppgift eller en saknad inställning upp vid installationen, inte första gången en kund förlitar sig på den.
• Riktig infrastruktur i botten, inte bara ett funktionsanrop. Eftersom appar är fullständiga applikationer kan de hålla verkligt tillstånd: en cache, en räknare för anropsfrekvens, en liten databas – inte bara en tillståndslös förfrågan och ett svar. Det är det som gör det möjligt att till exempel följa om lösningsgraden för en viss domän har sjunkit med mer än 10 % under de senaste 24 timmarna och larma ditt team när det händer. Ett enkelt API-anrop kan inte hålla den typen av minne. En riktig applikation kan det, på samma sätt som en myrkoloni minns var maten finns trots att ingen enskild myra gör det.
• Känslig data hålls borta från modellen. Vissa steg ska inte passera genom en AI över huvud taget. När en kund är redo att köpa det som ligger i varukorgen triggar agenten appens kassaflöde, och appen samlar in betalnings- och personuppgifter direkt från kunden via sitt eget säkra gränssnitt. Agenten styr flödet, men kortnummer och annan känslig information kommer aldrig in i konversationen med AI:n.
• En kodbas, alla kunder, isolerad skadeverkan. Multi-tenancy innebär att korrigeringar och förbättringar levereras en gång och når alla, medan isoleringen innebär att en kunds anpassade logik aldrig kan påverka en annans.

Vad det innebär för dig

Om du utvärderar Maven är den praktiska slutsatsen denna: när vi säger att en agent kan besvara en fråga och agera på den menar vi att det finns en riktig applikation bakom åtgärden – versionshanterad, autentiserad, isolerad och byggd på samma ramverk oavsett om den kommer från vårt team eller ditt. Det är skillnaden mellan en agent som kan prata om dina system och en som faktiskt är inkopplad i dem.

Vi byggde Maven Apps för att vi tror att det är vad ”integration” borde ha betytt hela tiden.