Maven Apps: je agents hebben operators nodig, geen schakelpanelen

Een schakelpaneel doet precies waarvoor het bedraad is: zet de schakelaar om en je krijgt telkens dezelfde vaste reactie. Vraag het iets buiten dat circuit en het lukt niet, want het kan niet omgaan met variatie, alleen met bedrading.

Een telefonist werkt anders. Geef een telefonist een verzoek, verbind me door met de receptie, en die zoekt zelf uit hoe: welke lijn te gebruiken, wat te doen als die bezet is, wat te doen als het verzoek zelf onduidelijk was. Een telefonist geeft het signaal niet alleen door, maar interpreteert het en handelt ernaar.

Maven Apps zijn telefonisten, geen schakelpanelen. Toen we het framework ontwierpen dat onze App-infrastructuur aandrijft, maakten we een bewuste keuze: bouw niet nog een integratielaag. Bouw een echt applicatieplatform en maak AI-agents er volwaardige gebruikers van.

Inmiddels draaien er duizenden apps op ons framework. Ja, daar zitten apps tussen voor grote externe systemen zoals Salesforce, Zendesk en Notion. Maar er draaien ook honderden maatwerkapps in productie op live agents.

Waarom basisintegraties tekortschieten

Vraag 10 leveranciers wat ‘integreert met Salesforce’ betekent voor hun product en je krijgt 10 verschillende antwoorden. Een systeem als Salesforce, Zendesk of Front is namelijk nooit zomaar één ding. Het kan zijn:

• Een plek waar je agent informatie moet vinden (een kennisbank, een casegeschiedenis)
• Een plek waar je agent actie moet ondernemen (een ticket aanmaken, een record bijwerken, een terugbetaling uitvoeren)
• Een omgeving waarin je agent zichtbaar moet zijn (een agent-assist-copilot in de console waarin je supportteam toch al werkt)

Een ‘Salesforce-integratie’ die alleen artikelen kent, is een ander product dan een integratie die ook een case kan aanmaken, en weer een ander product dan een integratie die als copilot in de agentconsole kan draaien. Toch worden ze vaak onder één marketingterm gebundeld, waardoor je de gaten pas tijdens de implementatie ontdekt.

Het is het automaatprobleem: een vast menu dat precies doet wat beloofd wordt, totdat wat je nodig hebt er niet tussen staat. En dan heb je je al vastgelegd. Zo wilden we Maven Apps niet laten werken. Daarom bouwden we het framework rond de vraag die er werkelijk gesteld wordt (kennis, functionaliteit of kanaal) in plaats van rond een generieke ‘connector’.

Maven Apps: meer dan integraties

Maven Apps kunnen veel vormen aannemen, maar de meeste bouwen voort op een paar veelvoorkomende patronen. Een paar voorbeelden van wat apps kunnen:

• Kennisapps lezen en indexeren content uit een extern systeem, zodat de agent daaruit kan antwoorden: alleen-lezen, met versiebeheer en te taggen per doelgroep.
• Capability-apps laten de agent echt iets doen in dat systeem: een echte API-call, gekoppeld in een workflow met meerdere stappen (de bestelling opzoeken, het retourbeleid controleren, de terugbetaling uitvoeren, het aan de klant bevestigen), allemaal binnen één gesprek. Waar een geldautomaat één vaste transactie uitvoert vanuit een vast menu, gedraagt een capability-app zich meer als een persoonlijke bankier: die krijgt een gewenst resultaat, geen menu-optie, en doet wat nodig is om daar te komen, inclusief het afhandelen van uitzonderingen.
• Kanaalapps brengen de agent naar de plek waar je klanten of supportteam al zijn: een ingesloten widget, een telefoongesprek, een inbox of een copilotpaneel in de console die je medewerkers dagelijks gebruiken.

Een kant-en-klare app uit onze directory installeer je meestal binnen enkele minuten. Staat het systeem van een klant niet in de catalogus, dan gebruikt een developer hetzelfde framework, dezelfde SDK, dezelfde lifecycle-hooks en hetzelfde beveiligingsmodel om er zelf een te bouwen.

Er bestaat geen aparte ‘enterprise-grade’-variant van het framework die alleen onze engineers gebruiken; App Studio, ons developerplatform voor het bouwen van apps, draait op exact dezelfde architectuur. Het is echte TypeScript, een echte SDK (@mavenagi/mavenagi) en een echte deploy-pipeline, geen eigen scripttaal die je speciaal voor ons moet leren.

Als je eerder met MCP hebt gebouwd: een Maven App biedt een vergelijkbaar concept, volledig beheerd. Met een standaard MCP-server moet je die nog steeds zelf opzetten, registreren, draaiende houden en schalen. Een Maven App lijkt meer op een MCP-endpoint dat zichzelf registreert en automatisch schaalt, zonder dat jij die infrastructuur hoeft te beheren: jij schrijft de logica, en het endpoint, de authenticatie en de hosting worden voor je geregeld.

Hoe Apps zijn ontworpen om krachtig te zijn

Een Maven App is een serverless applicatie die draait in een beveiligde, geïsoleerde omgeving en via een vastgelegde SDK communiceert met het Maven-platform. Concreet:

Het is multi-tenant. Een app wordt één keer gebouwd en vele keren geïnstalleerd, bij verschillende organisaties en agents. Elke installatie krijgt een eigen afgebakende context (een eigen organisatie-ID, agent-ID en runtimeconfiguratie), maar deelt dezelfde onderliggende code. Als we de Salesforce-app verbeteren, profiteert dus elke klant die hem gebruikt, en niemand blijft hangen op een verouderde, zelfgebouwde versie van ‘hun’ integratie.

Het is geïsoleerd, niet ergens aan vastgeplakt. Elke app draait als eigen functie in een beveiligde omgeving, gescheiden van de kernbackend van Maven en van de apps van andere klanten. Jouw maatwerklogica draait nooit in een gedeelde monoliet naast die van een ander. Verbindingen met je bronsystemen kunnen via VPN, VPC-peering, OIDC of gewoon HTTPS met IP-allowlisting lopen: jij kiest, niet wij.

Het reageert op echte events, niet op pollingschema’s. In plaats van een nachtelijke synchronisatietaak kan een app event-hooks implementeren, zogeheten triggers: er is een gesprek aangemaakt, er is feedback binnengekomen, een kennisbank is ververst, en het platform laat de app dat weten op het moment dat het gebeurt. Dat werkt anders dan de automatiseringstools die je misschien al kent. Een Maven-trigger is passief: het platform luistert zelf naar statuswijzigingen en stuurt die door naar elke app die er belang bij heeft, zonder koppeling tussen de app die het event veroorzaakte en de app die erop reageert. In de praktijk kunnen een e-mailresponsapp en een volledig losstaande Salesforce-synchronisatieapp dus allebei onafhankelijk reageren op hetzelfde event ‘gesprek bijgewerkt’, elk op hun eigen manier, zonder dat ze van elkaars bestaan weten.

Het is hetzelfde coördinatiemechanisme dat een mierenkolonie gebruikt. Geen enkele mier plant het gedrag van de kolonie, en geen mier stuurt een andere direct een bericht. Een mier verandert iets in de gedeelde omgeving (een feromonenspoor) en alle andere mieren reageren daar onafhankelijk op, elk volgens een eigen eenvoudige regel. De intelligentie van de kolonie als geheel (geoptimaliseerde foerageerroutes, lastverdeling, zelfs collectieve beslissingen zoals het verhuizen van het nest) ontstaat daaruit, zonder centrale coördinator en zonder dat één mier het plan kent. Maven Apps coördineren op dezelfde manier: een event verandert de gedeelde status en elke app die erbij betrokken is, reageert zelfstandig.

Het heeft een echte lifecycle. Elke app implementeert een klein aantal lifecycle-hooks:

• preInstall: valideert credentials en configuratie voordat er iets live gaat. Klopt je API-sleutel niet, dan mislukt de installatie hier duidelijk zichtbaar, in plaats van ongemerkt 3 weken later.
• postInstall: registreert de acties van de app en richt de benodigde resources in zodra de installatie is gelukt.
• executeAction: voert het daadwerkelijke werk uit waar een agent om vraagt, voor klanten beschikbaar als capability: een bestelling opzoeken, een case aanmaken, een terugbetaling uitvoeren, een rekeningsaldo controleren.

De meeste integraties zijn een lichtschakelaar: aan of uit, niets daartussen. Die van ons doorlopen een volledige lifecycle van installeren, valideren, uitvoeren en afbouwen. Dat lijkt meer op een routine die context leest en zich aanpast (kijk wat er openstaat, controleer wat veilig is, en handel dan) dan op een schakelaar met 2 standen. Dat is precies de discipline die je verwacht van productiesoftware, want dat is het ook.

Apps vs. integraties

Een typische integratie beantwoordt een enkele, smalle vraag, meestal ‘kan data van A naar B?’, en beschouwt dat als de eindstreep. Een Maven App is gebouwd voor een moeilijkere, nuttigere vraag: kan een AI-agent betrouwbaar weten wat er op dit moment in je systemen klopt, en kun je erop vertrouwen dat hij namens jou handelt wanneer dat nodig is?

De meeste enterpriseplatforms bieden een variant van ‘bouw het zelf als wij het niet standaard hebben’. Wat ze er meestal niet bij vertellen: zelf bouwen betekent je eigen server, je eigen schaling en je eigen securityreview, op je eigen infrastructuur. Daarmee wordt een simpel gat in de connectorcatalogus een personeelskwestie: krijg je budget voor engineering en infrastructuur, of blijf je beperkt tot wat er kant-en-klaar is? Met Maven Apps hoeven onze klanten niet te kiezen voor de minst slechte optie. Een maatwerkapp die jij of je developer bouwt, draait op onze infrastructuur, met dezelfde monitoring, schaling en beveiliging als elke kant-en-klare app in onze directory. Jij schrijft de code; wij draaien hem.

Daarom stelt de architectuur ook eisen waar een simpele webhook zich nooit druk over hoeft te maken:

• Gestructureerde responses met een maximale omvang. Elke actie die een app uitvoert, geeft een duidelijke response terug plus gestructureerde data waarmee de agent kan redeneren, geen ruwe, onbegrensde datablob waar hij naar moet raden.
• Ondertekende, wederzijdse authenticatie. Het platform ondertekent elk verzoek aan een app, zodat de app kan verifiëren dat het echt Maven is die belt, en de app authenticeert zich met eigen credentials bij het platform. Geen van beide kanten hoeft alleen op het netwerk te vertrouwen.
• Configuratie gevalideerd voordat die productie bereikt. Omdat preInstall draait voordat een app live gaat, worden een ongeldige credential of een ontbrekende instelling bij de installatie opgemerkt, niet pas wanneer een klant er voor het eerst op rekent.
• Echte infrastructuur eronder, niet alleen een functieaanroep. Omdat apps volwaardige applicaties zijn, kunnen ze echte state bijhouden: een cache, een rate-teller, een kleine database, niet alleen een stateless request en response. Daardoor kun je bijvoorbeeld bijhouden of het oplossingspercentage voor een specifiek domein in de afgelopen 24 uur met meer dan 10% is gedaald, en je team alarmeren als dat zo is. Een kale API-call kan zo’n geheugen niet vasthouden. Een echte applicatie wel, net zoals een mierenkolonie onthoudt waar het voedsel ligt, terwijl geen enkele mier dat doet.
• Gevoelige data weg van het model. Sommige stappen horen helemaal niet langs een AI te gaan. Is een klant klaar om af te rekenen, dan start de agent de checkout van de app, en de app verzamelt betaal- en persoonsgegevens rechtstreeks bij de klant via een eigen beveiligde interface. De agent regisseert de flow, maar kaartnummers en andere gevoelige informatie komen nooit in het gesprek met de AI terecht.
• Eén gedeelde codebase voor elke klant, met geïsoleerde impact. Multi-tenancy betekent dat fixes en verbeteringen één keer worden uitgerold en iedereen bereiken, terwijl isolatie ervoor zorgt dat de maatwerklogica van de ene klant nooit invloed heeft op die van een andere.

Wat het voor jou betekent

Overweeg je Maven, dan is de praktische conclusie deze: als wij zeggen dat een agent een vraag kan beantwoorden en er actie op kan ondernemen, bedoelen we dat er een echte applicatie achter die actie zit, met versiebeheer, authenticatie en isolatie, gebouwd op hetzelfde framework, of hij nu door ons team is uitgebracht of door het jouwe. Dat is het verschil tussen een agent die over je systemen kan praten en een agent die er echt mee verbonden is.

We hebben Maven Apps gebouwd omdat we vinden dat ‘integratie’ altijd al dit had moeten betekenen.