Maven Apps: Ihre Agents brauchen Operatoren, keine Schalttafeln

Ein Schaltpult tut genau das, wofür es verdrahtet wurde: Schalter umlegen, immer dieselbe feste Reaktion. Bitten Sie es um etwas außerhalb dieses Stromkreises, kann es nicht helfen, denn es kennt keine Abweichungen, nur Verdrahtung.

Eine Telefonistin dagegen schon. Geben Sie ihr eine Anfrage, etwa „Verbinden Sie mich mit der Rezeption“, und sie findet den Weg: welche Leitung sie nimmt, was sie tut, wenn besetzt ist, und was, wenn die Anfrage selbst unklar war. Sie leitet das Signal nicht bloß weiter, sie interpretiert es und handelt danach.

Maven Apps sind Telefonistinnen, keine Schaltpulte. Als wir das Framework hinter unserer App-Infrastruktur entwickelt haben, sind wir eine bewusste Wette eingegangen: keine weitere Integrationsschicht bauen, sondern eine echte Anwendungsplattform, auf der KI-Agenten vollwertige Akteure sind.

Heute laufen Tausende Apps auf unserem Framework. Dazu gehören Apps für große Drittsysteme wie Salesforce, Zendesk und Notion, aber auch Hunderte individuelle Apps, die produktiv auf Live-Agenten laufen.

Warum einfache Integrationen nicht ausreichen

Fragen Sie 10 Anbieter, was „integriert mit Salesforce“ für ihr Produkt bedeutet, und Sie erhalten 10 verschiedene Antworten. Denn ein System wie Salesforce, Zendesk oder Front ist nie nur eine Sache. Es kann sein:

• Ein Ort, an dem Ihr Agent Informationen findet (eine Wissensdatenbank, eine Fallhistorie)
• Ein Ort, an dem Ihr Agent Aktionen ausführt (ein Ticket erstellen, einen Datensatz aktualisieren, eine Erstattung veranlassen)
• Eine Oberfläche, in der Ihr Agent präsent sein muss (ein Agent-Assist-Copilot direkt in der Konsole, in der Ihr Supportteam ohnehin arbeitet)

Eine „Salesforce-Integration“, die nur Artikel kennt, ist nicht dasselbe Produkt wie eine, die auch einen Fall anlegen kann – und auch nicht dasselbe wie eine, die als Copilot in der Agentenkonsole sitzt. Oft wird all das unter einem einzigen Marketingbegriff gebündelt, und die Lücken entdecken Sie erst bei der Implementierung.

Es ist das Getränkeautomaten-Problem: ein festes Menü, das genau wie beworben funktioniert – bis das, was Sie brauchen, nicht auf der Liste steht. Und dann haben Sie sich bereits festgelegt. So sollten Maven Apps nicht funktionieren. Deshalb haben wir das Framework um die eigentliche Frage herum gebaut (Wissen, Fähigkeit oder Kanal) statt um einen generischen „Connector“.

Maven Apps: mehr als Integrationen

Maven Apps können viele Formen annehmen, die meisten bauen aber auf einigen gängigen Mustern auf. Einige Beispiele, was Apps leisten können:

• Knowledge-Apps lesen und indexieren Inhalte aus einem externen System, damit der Agent darauf basierend antworten kann: schreibgeschützt, versioniert, nach Zielgruppe taggbar.
• Capability-Apps ermöglichen es dem Agenten, in diesem System tatsächlich etwas zu tun: ein echter API-Aufruf, verkettet zu einem mehrstufigen Workflow (Bestellung nachschlagen, Rückgaberichtlinie prüfen, Erstattung veranlassen, dem Kunden bestätigen) – alles innerhalb einer einzigen Konversation. Während ein Geldautomat eine vorgegebene Transaktion aus einem festen Menü abwickelt, verhält sich eine Capability-App eher wie ein persönlicher Bankberater: Sie bekommt ein Ziel statt eines Menüpunkts und tut, was nötig ist, um es zu erreichen – einschließlich der Ausnahmebehandlung.
• Channel-Apps bringen den Agenten dorthin, wo Ihre Kunden oder Ihr Supportteam bereits sind: ein eingebettetes Widget, ein Telefonanruf, ein Posteingang oder ein Copilot-Panel in der Konsole, die Ihre Agenten täglich nutzen.

Eine vorgefertigte App aus unserem Verzeichnis ist meist in wenigen Minuten installiert. Ist das System eines Kunden nicht im Katalog, nutzen Entwickler dasselbe Framework – dasselbe SDK, dieselben Lifecycle-Hooks, dasselbe Sicherheitsmodell –, um eine individuelle App zu bauen.

Es gibt keine separate „Enterprise-Grade“-Stufe des Frameworks, die nur unsere Engineers nutzen. App Studio, unsere Entwicklerplattform für Apps, läuft auf exakt derselben Architektur. Es ist echtes TypeScript, ein echtes SDK (@mavenagi/mavenagi) und eine echte Deploy-Pipeline – keine proprietäre Skriptsprache, die Sie nur für uns lernen müssen.

Wenn Sie bereits mit MCP gearbeitet haben: Eine Maven App bietet ein ähnliches Konzept, vollständig gemanagt. Einen Standard-MCP-Server müssen Sie selbst aufsetzen, registrieren, betreiben und skalieren. Eine Maven App ähnelt eher einem automatisch registrierenden, automatisch skalierenden MCP-Endpunkt, ohne dass Sie sich um die Infrastruktur kümmern müssen: Sie schreiben die Logik, Endpunkt, Authentifizierung und Hosting übernehmen wir.

Wie Apps auf Leistungsfähigkeit ausgelegt sind

Eine Maven App ist eine serverlose Anwendung, die in einer sicheren, isolierten Umgebung läuft und über ein definiertes SDK mit der Maven-Plattform kommuniziert. Konkret:

Sie ist mandantenfähig. Eine App wird einmal gebaut und vielfach installiert, über verschiedene Organisationen und Agenten hinweg. Jede Installation erhält ihren eigenen Kontext (eigene Organisations-ID, Agenten-ID und Laufzeitkonfiguration), teilt aber denselben zugrunde liegenden Code. Wenn wir also die Salesforce-App verbessern, profitiert jeder Kunde, der sie nutzt – niemand bleibt auf einer veralteten, selbst gebauten Version „seiner“ Integration sitzen.

Sie ist isoliert, nicht angeflanscht. Jede App läuft als eigene Funktion in einer sicheren Umgebung, getrennt vom Maven-Kern-Backend und von den Apps anderer Kunden. Ihre individuelle Logik läuft nie in einem gemeinsamen Monolithen neben der eines anderen. Verbindungen zu Ihren führenden Systemen können über VPN, VPC-Peering, OIDC oder einfaches HTTPS mit IP-Allowlisting laufen – Sie entscheiden, nicht wir.

Sie reagiert auf echte Ereignisse statt auf Polling-Zeitpläne. Statt eines nächtlichen Sync-Jobs kann eine App Event-Hooks, sogenannte Trigger, implementieren: Eine Konversation wurde erstellt, Feedback ist eingegangen, eine Wissensdatenbank wurde aktualisiert – und die Plattform benachrichtigt die App in dem Moment, in dem das Ereignis eintritt. Das unterscheidet sich von den Automatisierungstools, die Sie vielleicht kennen. Ein Maven-Trigger ist passiv: Die Plattform selbst lauscht auf Zustandsänderungen und übermittelt sie an jede App, die sich dafür interessiert – ohne Kopplung zwischen der App, die das Ereignis ausgelöst hat, und der App, die darauf reagiert. In der Praxis können so eine E-Mail-Antwort-App und eine völlig separate Salesforce-Sync-App unabhängig voneinander auf dasselbe Ereignis „Konversation aktualisiert“ reagieren, jede auf ihre Weise, ohne dass die eine von der anderen weiß.

Es ist derselbe Koordinationsmechanismus, den eine Ameisenkolonie nutzt. Keine einzelne Ameise plant das Verhalten der Kolonie, und keine Ameise kommuniziert direkt mit einer anderen. Eine Ameise verändert etwas in der gemeinsamen Umgebung (eine Pheromonspur), und alle anderen reagieren unabhängig darauf, jede nach ihrer eigenen einfachen Regel. Die Intelligenz der Kolonie (optimierte Futterrouten, Lastverteilung, sogar kollektive Entscheidungen wie ein Nestumzug) entsteht daraus – ohne zentrale Steuerung und ohne dass eine Ameise den Plan kennt. Maven Apps koordinieren sich genauso: Ein Ereignis verändert den gemeinsamen Zustand, und jede betroffene App reagiert eigenständig.

Sie hat einen echten Lebenszyklus. Jede App implementiert einige wenige Lifecycle-Hooks:

• preInstall: prüft Zugangsdaten und Konfiguration, bevor irgendetwas live geht. Ist Ihr API-Schlüssel falsch, schlägt die Installation hier deutlich sichtbar fehl – statt 3 Wochen später unbemerkt.
• postInstall: registriert die Aktionen der App und stellt nach erfolgreicher Installation die benötigten Ressourcen bereit.
• executeAction: führt die eigentliche Arbeit aus, die ein Agent anfordert, und stellt sie Kunden als Fähigkeit bereit: eine Bestellung nachschlagen, einen Fall anlegen, eine Erstattung veranlassen, einen Kontostand prüfen.

Die meisten Integrationen sind ein Lichtschalter: an oder aus, nichts dazwischen. Unsere durchlaufen einen vollständigen Lebenszyklus aus Installation, Validierung, Ausführung und Abbau – eher eine Routine, die Kontext liest und sich anpasst (prüfen, was offen ist, bestätigen, was sicher ist, dann handeln), als ein Schalter mit 2 Zuständen. Genau diese Disziplin erwarten Sie von Produktivsoftware – denn genau das ist es.

Apps vs. Integrationen

Eine typische Integration beantwortet eine eng gefasste Frage, meist „Kommen Daten von A nach B?“, und betrachtet das als Ziellinie. Eine Maven App ist darauf ausgelegt, eine schwierigere, nützlichere Frage zu beantworten: Kann ein KI-Agent zuverlässig wissen, was in Ihren Systemen gerade zutrifft – und kann man ihm vertrauen, bei Bedarf in Ihrem Namen zu handeln?

Die meisten Enterprise-Plattformen bieten eine Variante von „Bauen Sie es selbst, wenn wir es nicht standardmäßig haben“. Was sie meist verschweigen: Selbst bauen heißt eigener Server, eigene Skalierung, eigenes Security-Review, auf eigener Infrastruktur. Aus einer einfachen Lücke im Connector-Katalog wird so eine Personalentscheidung: Bekommen Sie ein Budget für Engineering und Infrastruktur, oder bleiben Sie auf das Vorgefertigte beschränkt? Mit Maven Apps müssen sich unsere Kunden nicht für das kleinere Übel entscheiden. Eine individuelle App, die Sie oder Ihr Entwickler bauen, läuft auf unserer Infrastruktur – mit demselben Monitoring, derselben Skalierung und demselben Sicherheitsniveau wie jede vorgefertigte App in unserem Verzeichnis. Sie schreiben den Code, wir betreiben ihn.

Deshalb besteht die Architektur auch auf Dingen, um die sich ein einfacher Webhook nie kümmern muss:

• Strukturierte, größenbegrenzte Antworten. Jede Aktion einer App liefert eine klare Antwort plus strukturierte Daten, mit denen der Agent arbeiten kann – keinen rohen, unbegrenzten Datenblob, den er erraten muss.
• Signierte, gegenseitige Authentifizierung. Die Plattform signiert jede Anfrage an eine App, damit die App prüfen kann, dass wirklich Maven anfragt, und die App authentifiziert sich mit eigenen Zugangsdaten gegenüber der Plattform. Keine Seite muss sich allein auf das Netzwerk verlassen.
• Konfiguration, die vor der Produktion validiert wird. Weil preInstall läuft, bevor eine App live geht, werden fehlerhafte Zugangsdaten oder fehlende Einstellungen bei der Installation erkannt – nicht erst, wenn sich ein Kunde zum ersten Mal darauf verlässt.
• Echte Infrastruktur statt bloßer Funktionsaufruf. Da Apps vollwertige Anwendungen sind, können sie echten Zustand halten: einen Cache, einen Ratenzähler, eine kleine Datenbank – nicht nur zustandslose Anfrage und Antwort. So lässt sich etwa verfolgen, ob die Lösungsrate für einen bestimmten Bereich in den letzten 24 Stunden um mehr als 10 % gesunken ist, und in diesem Fall Ihr Team alarmieren. Ein bloßer API-Aufruf kann sich so etwas nicht merken. Eine echte Anwendung schon – so wie eine Ameisenkolonie weiß, wo das Futter ist, obwohl keine einzelne Ameise es weiß.
• Sensible Daten bleiben vom Modell fern. Manche Schritte sollten gar nicht durch eine KI laufen. Will ein Kunde den Inhalt seines Warenkorbs kaufen, löst der Agent den Checkout der App aus, und die App erfasst Zahlungs- und persönliche Daten direkt beim Kunden über ihre eigene sichere Oberfläche. Der Agent orchestriert den Ablauf, aber Kartennummern und andere sensible Informationen gelangen nie in die Konversation mit der KI.
• Eine Codebasis, alle Kunden, isolierter Wirkungsradius. Mandantenfähigkeit bedeutet, dass Fixes und Verbesserungen einmal ausgeliefert werden und alle erreichen, während die Isolation sicherstellt, dass die individuelle Logik eines Kunden nie die eines anderen beeinträchtigt.

Was das für Sie bedeutet

Wenn Sie Maven evaluieren, ist die praktische Erkenntnis: Wenn wir sagen, ein Agent kann eine Frage beantworten und darauf handeln, steckt hinter dieser Aktion eine echte Anwendung – versioniert, authentifiziert, isoliert und auf demselben Framework gebaut, egal ob sie von unserem Team oder Ihrem stammt. Das ist der Unterschied zwischen einem Agenten, der über Ihre Systeme sprechen kann, und einem, der tatsächlich mit ihnen verdrahtet ist.

Wir haben Maven Apps gebaut, weil wir glauben, dass „Integration“ genau das schon immer hätte bedeuten sollen.