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.
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.