Mein KI-Stack — vier Layer, ein Stack
Provider-agnostisch, DSGVO-bewusst, ohne separate Vector-DB — produktiv im Einsatz auf dieser Site.
Mein KI-Stack besteht aus vier Layern, die je eine klar abgegrenzte Verantwortung tragen. Das Diagramm zeigt den Datenfluss von einer Browser-Anfrage bis zur generierten Antwort. Jeder Layer ist austauschbar, ohne die anderen anzufassen — das ist die Voraussetzung dafür, dass der Stack mit der Technologie-Generation mitgeht.
Vier Layer
Storage- und Retrieval-Layer — MariaDB Vector-Type
Embeddings — die mathematische Repräsentation von Text als hochdimensionale Vektoren — werden direkt in MariaDB gespeichert, im nativen Vector-Type. Keine separate Vector-DB, keine Pinecone-Subscription, kein zusätzlicher Service zwischen TYPO3 und der Suche.
Der VECTOR-Typ ist in MariaDB ab 11.7 Standard. TYPO3 beziehungsweise Doctrine DBAL kennt ihn jedoch nicht — die Datenbank-Abstraktion reicht den Typ nicht durch. Dafür habe ich einen Core-Patch geschrieben, der den Vector-Type in TYPO3 nutzbar macht. Der Patch ist als Composer-Hook eingebunden, sodass er bei jedem Composer-Install automatisch wieder appliziert wird.
Vorteil dieses Ansatzes: ein Service weniger im Stack, ein Connection-Pool weniger, ein Backup-Job weniger. Embedding-Reads laufen über die gleiche MariaDB-Connection wie Content-Reads.
Pipeline-Layer — AiM
AiM ist eine TYPO3-Extension-Sammlung von b13, aktuell in Alpha-Stadium. Sie übernimmt die Orchestrierung der RAG-Pipeline: Inhalts-Embeddings erzeugen und persistieren, eingehende Anfragen vektorisieren, Vektorsuche im Index, Prompt-Komposition mit dem gefundenen Content, LLM-Call, Response-Streaming.
Ich nutze AiM produktiv auf dieser Site und bin mit einem Pull-Request an der Extension beteiligt. Sie ist Alpha und wird sich weiter bewegen — wer AiM heute einsetzt, muss bereit sein, die Versions-Sprünge mitzugehen. Für mich ist das ein guter Trade-off: AiM nimmt mir die Schreibarbeit für RAG-Pipelines ab, ich gebe der Extension produktiven Test-Druck zurück.
Backend-Layer — TYPO3
TYPO3 ist das CMS, die Content-Authoring-Schicht — und das Streaming-Backend des Chats. Die HTTP-Stream-Verbindung zum Browser hält eine PSR-15-Middleware direkt in TYPO3, die die LLM-Antwort Token für Token weiterreicht. Kein separater Dienst daneben.
Streaming in PHP und Apache ist nicht geschenkt: mod_deflate puffert die Response, output_buffering puffert sie nochmal, und PHP-FPM blockiert Worker, solange ein Stream offen ist. Genau diese Plumbing — PSR-15-Middleware, <LocationMatch>-Config für Apache, die richtigen PHP-Settings — habe ich gelöst, statt das Streaming in einen separaten Service auszulagern. Die Details stehen im Artikel HTTP-Streaming in TYPO3.
Frontend-Layer — Next.js
Next.js 16 mit App Router und React 19 Server Components. Das Chat-Frontend nutzt Streaming-Rendering: Token kommen aus dem Backend an, werden sofort in den DOM geschrieben, kein Warten auf die vollständige Antwort. Für die Agent-UI-Interaktion läuft CopilotKit, gesteuert über das AG-UI Protocol — ein offenes Protokoll für Agent-Frontend-Kommunikation.
Vorteil dieser Trennung: das Frontend bleibt austauschbar. Das gleiche Backend funktioniert mit einer anderen Chat-UI, mit einem CLI-Client, mit einem Slack-Bot — überall dort, wo AG-UI als Protokoll-Layer akzeptiert wird.
LLM-Anbindung
Ich bin nicht festgelegt auf einen LLM-Provider. OpenAI, Anthropic und Google laufen über eine gemeinsame Abstraktionsschicht. Für DSGVO-sensible Szenarien laufen lokale Modelle über Ollama — Llama, Mistral, Qwen je nach Aufgabe und Hardware-Budget. Provider-Wechsel ist Konfiguration, nicht Code-Refactoring.
Welcher Provider den Zuschlag bekommt, hängt an drei Achsen: Qualität der Antworten für den konkreten Use-Case (manche Modelle sind besser im Zusammenfassen, andere besser im Tool-Calling), Latenz im EU-Raum, und Datenschutz-Profil des Inhalts.
Agentic Protocols
Drei Protokolle bilden den Standardisierungs-Layer für KI-Agenten:
MCP (Model Context Protocol) — das Standard-Protokoll für KI-Modelle, die Tools aufrufen. Mein TYPO3-MCP-Server spricht MCP, jeder MCP-kompatible Client kann ihn nutzen — Claude Code, Cursor, Zed, beliebige eigene Frontends.
A2A (Agent-to-Agent) — für Multi-Agent-Workflows, in denen mehrere spezialisierte Agenten kooperieren. Relevant, sobald ein Use-Case in mehrere Rollen zerlegt werden kann (Research-Agent, Implementation-Agent, Review-Agent).
AG-UI (Agent-UI Protocol) — für Frontend-Agent-Kommunikation. Trennt Agent-Logik vom UI-Rendering, sodass die UI austauschbar bleibt.
WebMCP — dieselben Tools für Ihren eigenen KI-Client
Der KI-Assistent dieser Site ist nur einer von zwei Konsumenten ihrer Tools. Der zweite kann Ihr eigener MCP-Client sein: Claude Desktop, Claude Code, Cursor — was immer bei Ihnen läuft. Über die WebMCP-Schaltfläche im Chat-Fenster verbinden Sie ihn mit dieser Site und rufen dieselben Tools auf, die auch der Chat nutzt: die Vektorsuche über die Site-Inhalte, freie Terminfenster, Seiten öffnen, einen Entwurf für das Kontaktformular, die Übernahme eines Gesprächs in beide Richtungen.
Möglich macht das eine Registry als Vertrag: Jedes Tool, das für den Chat registriert wird, ist automatisch auch am WebMCP-Endpoint sichtbar. Ein Ort für neue Tools, keine zweite Schema-Pflege, kein Drift zwischen den Kanälen — der Chat ist eine von zwei Ansichten auf denselben Tool-Satz, nicht dessen Besitzer.
Die Verbindung läuft über ein Relay, das Ihr MCP-Client auf Ihrem eigenen Rechner startet. Die WebSocket-Strecke verlässt localhost nie; mein Server sieht nur gewöhnliche Same-Origin-Anfragen aus Ihrem Browser-Tab — keine Session-Identität, kein Konto, kein Pairing-Code. Tools, die nur lokal wirken, erreichen den Server gar nicht erst. Schreibende Aktionen sind gestuft abgesichert: Ein Gesprächs-Import in den Website-Chat braucht die Chat-Einwilligung und eine ausdrückliche Bestätigung im Browser; das Kontaktformular wird nur vorbefüllt, nie abgesendet.
Als Browser-Standard steht WebMCP noch am Anfang — eine W3C-Community-Gruppe arbeitet an navigator.modelContext, Chrome führt es als Preview hinter einem Flag. Deshalb setze ich auf einen Weg, der heute funktioniert: Widget plus lokales Relay, kompatibel mit jedem MCP-Client. Wie das im Detail gebaut ist, zeigt das How-to zu WebMCP (auf Englisch). Für den ersten Verbindungsversuch führt Erste Schritte mit WebMCP Schritt für Schritt durch.
Was das in der Praxis bedeutet
Diese Architektur läuft live auf dieser Site. Der KI-Assistent unten rechts auf jeder Seite ist das Live-Beispiel: TYPO3-Inhalte als RAG-Korpus, MariaDB-Vector als Storage, AiM als Pipeline, die Streaming-Middleware in TYPO3 als Backend, Next.js als UI. Für eine Mittelstands-Site mit ähnlichem Profil — TYPO3-Headless, KI-Anbindung, DSGVO-bewusst — ist diese Stack-Auswahl der Default-Ausgangspunkt. Abweichungen entstehen meistens an zwei Stellen: LLM-Provider je nach Inhalts-Sensibilität, und Storage-Layer, wenn das Embedding-Volumen jenseits dessen liegt, was eine einzelne MariaDB-Instanz tragen kann.
Das ist der Punkt, an dem Architektur-Entscheidungen vor Setup-Entscheidungen kommen — und der Grund, warum jedes KI-Projekt bei mir mit einer Architektur-Sitzung beginnt, nicht mit einem Tool-Vergleich.
Weiter im Thema
Klingt nach Ihrem Projekt?
Sprechen wir unverbindlich darüber.
Antwort innerhalb 24h — in der Regel deutlich schneller.