Die Idee für diesen Artikel entstand nicht am Reißbrett. Sie kam nebenbei – in einem Gespräch mit einem KI-Modell über mein eigenes kleines Agentenprojekt. Ich wollte keinen Server betreiben, keine Infrastruktur verwalten, aber trotzdem einen Agenten mit Gedächtnis bauen. Und plötzlich stand die Frage im Raum: Wo leben eigentlich die Erinnerungen – und wem gehören sie, wenn der Anbieter morgen weg ist?
Der Markt für KI-Agenten bewegt sich in atemberaubender Geschwindigkeit. Fast wöchentlich erscheinen neue Frameworks, die versprechen, komplexe Geschäftsprozesse autark zu steuern. Doch wer tiefer einsteigt, stößt schnell auf eine fundamentale strategische Frage: Was passiert, wenn ein großer Modellanbieter seine Pricing-Struktur drastisch ändert, Richtlinien anpasst oder schlicht verschwindet? Und wie lässt sich ein mühsam aufgebauter Agent von Anbieter A nach Anbieter B migrieren?
Aktuell fehlt es der Industrie an etablierten Architekturstandards für langfristige Portabilität. Wenn wir nicht aufpassen, wiederholen wir die größten Fehler der Softwaregeschichte – und verketten geschäftskritische Logik untrennbar mit proprietären APIs.
Was folgt, ist kein fertiges Konzept. Es ist ein Denkansatz, den ich im Sparring mit mehreren KI-Modellen entwickelt habe – und der vielleicht falsch ist. Aber ich glaube, es ist die richtige Frage zur richtigen Zeit.
1. Das Modell ist austauschbar (Model Agnosticism)
Ein Agent darf niemals fest mit einer proprietären API verdrahtet sein. Zwischen der Kernlogik und dem Sprachmodell gehört eine Abstraktionsschicht. Fällt ein Anbieter weg oder wird zu teuer, muss im Hintergrund nahtlos gewechselt werden können – ohne dass das Gesamtsystem kollabiert.
2. Das Gedächtnis gehört dem Kunden (Externalized State)
Wissen, Präferenzen und Interaktionshistorie haben im Modell selbst nichts zu suchen. Sie gehören in eine vom Unternehmen kontrollierte Schicht – relationale Datenbanken, Dokumentenspeicher oder Vektordatenbanken. Nur so bleibt das Kontextwissen erhalten, wenn das darunterliegende Modell wechselt.
3. Werkzeuge sprechen offene Standards (Standardized Tooling)
Agenten entfalten ihren Wert erst, wenn sie mit Drittsystemen kommunizieren – CRM, ERP, HR-Software. Diese Integration darf nicht proprietär sein. Ob klassische REST-APIs, OpenAPI-Spezifikationen oder aufkommende Protokolle wie das Model Context Protocol (MCP): Entscheidend ist, dass die Schnittstelle unabhängig vom Modell bleibt.
4. Prompts und Regeln gehören dem Unternehmen (Portable Governance)
Das geschäftskritische Know-how steckt oft nicht im Modell, sondern in der Orchestrierung drumherum: Systemprompts, Geschäftsregeln, Freigabeprozesse, Tool-Berechtigungen, Guardrails. Diese Artefakte müssen exportierbar, versionierbar und dokumentiert sein.
Sonst erleben wir dasselbe wie früher bei BPM-Systemen: Die Daten lassen sich migrieren – die eigentliche Prozesslogik bleibt gefangen.
Fazit
Die technischen Bausteine entstehen gerade. Abstraktions-Frameworks existieren, Protokolle wie MCP entwickeln sich. Es liegt an Architekten und Entscheidern, diese Standards von Anfang an einzufordern – bevor die nächste Welle des Vendor Lock-ins zuschlägt.
Ich selbst bin noch dabei, das zu verstehen. Aber genau deshalb lohnt es sich, jetzt darüber zu reden.