Vom Demo zum Produktivsystem: Die 5 Zonen einer echten KI-Agenten-Architektur

Die meisten KI-Agenten bestehen ihren ersten Test. Eine Nutzerin stellt eine Frage, das Modell antwortet, und die Demo wirkt fertig. Dann geht der Agent live, die Nutzung steigt, und die Antworten werden schlechter statt besser. Das Modell hat sich nicht verändert. Die Architektur drumherum war nie darauf ausgelegt, Last zu tragen.

Genau dieses Muster sehen wir bei GoTeams immer wieder: Teams bauen heute schneller denn je Agenten, und die Qualität dieser Agenten sinkt mit steigender Nutzung, statt zu steigen. Die Lösung ist selten ein größeres Modell. Es ist der richtige Aufbau: fünf architektonische Zonen, die aus einer einmaligen Demo ein produktionsreifes KI-Agentensystem machen, das echten Traffic übersteht. Dieser Artikel geht jede Zone durch, benennt den Fehler, den sie verhindert, und zeigt, wo GoTeams gesehen hat, dass Teams sie richtig aufbauen.

Die fünf Zonen im Überblick

Zone	Aufgabe	Verhinderter Fehler
Der Harness	Stellt alles zusammen, was das Modell pro Lauf sieht	Fehlender Kontext; Regeln verstreut im Code
Der Agent Run	LLM + Tools + Schleife + Guardrails	Endlose Wiederholungen; nicht autorisierte Aktionen
Die Memory Layer	Speichert Skills, Fakten und Verlauf dauerhaft	Jede Sitzung beginnt bei null
Die RAG-Pipeline	Indexiert Wissen und ruft es bei Bedarf ab	Selbstbewusste Antworten aus veralteten Daten
LLM Ops	Traces, Evals, Gates, Releases	Nicht erklärbare Fehler; irreversible Änderungen

1. Der Harness: Was das Modell sehen darf

Der Harness stellt dem Modell vor jeder Antwort ein vollständiges Bild der Konversation zusammen, aus drei Quellen.

System Prompt: Ihre Hausregeln, Tonalität, feste Vorgaben, Sicherheitsrichtlinien. Halten Sie diesen in einer versionierten Datei, niemals verstreut im Anwendungscode, damit er bewertet und zurückgerollt werden kann, ohne ein Deployment auszulösen.

User Prompt: Die ursprüngliche Anfrage, wortgetreu gespeichert. Eine bereinigte Version kann zusätzlich für das Modell existieren, aber das Original bleibt erhalten. Evaluierungen und Beschwerdeanalysen brauchen beide den exakten Wortlaut, keine Paraphrase.

Chat-Verlauf: Die Runden des aktuellen Threads, begrenzt auf ein Token-Budget. Eine Anschlussfrage wie „und die günstigere Option?“ ergibt ohne diesen Kontext keinen Sinn.

Das Kontextfenster ist ein Zähler, kein kostenloser Speicher. Diese drei Quellen fließen ins Arbeitsgedächtnis, das Kontextfenster. Ein einziger Context Builder sollte jeden Lauf zusammenstellen, wobei jeder Abschnitt (Regeln, Thread, abgerufene Fakten, Tool-Schemas) ein eigenes, festgelegtes Token-Budget erhält. Ein Überlauf wird damit zu einer im Voraus getroffenen Entscheidung: belangloser Small Talk fällt zuerst weg, sicherheitskritische Regeln nie. Alles auf dem Zähler wird gelöscht, sobald der Lauf endet.

Der häufigste Fehler bei GoTeams-Kundenprojekten: ein einziger riesiger Prompt, in den alles hineinkopiert wird. Das funktioniert in der Demo. Es bricht in der ersten Woche mit echtem Traffic, wenn das Token-Limit erreicht wird und ausgerechnet die wichtigste Anweisung als Erste stillschweigend herausfällt.

2. Der Agent Run: Urteilsvermögen, Werkzeuge und ein Timer

Hier hört der Assistent auf, ein Chatbot zu sein, und beginnt, Konsequenzen zu haben.

LLM: das Urteilsvermögen. Es liest den zusammengestellten Kontext und entscheidet über den nächsten Schritt.

Tools: die Werkzeuge. Typisierte Schemas, eingeschränkte Zugangsdaten, wo immer möglich nur lesend. Ein Tool zum Abrufen von Zahlungen sollte auf die anfragende Kundin beschränkt sein, niemals eine freie Abfrage über die gesamte Zahlungstabelle erlauben. Tool-Beschreibungen sind genauso wichtig wie die Signaturen, denn das Modell wählt ein Tool anhand seiner Beschreibung aus. Eine vage Beschreibung ist ein Fehler, kein Stilmittel. Vermeiden Sie zwanzig sich überschneidende Tools: Die Trefferquote sinkt deutlich, sobald sich die Namen ähneln.

Die Schleife: Denken, Handeln, Beobachten, Wiederholen. Genau das erlaubt dem Agenten, sich von einem leeren Ergebnis zu erholen, statt aufzugeben.

Guardrails setzen drei Grenzen gegen drei Fehlerarten. Ein Limit für maximale Iterationen fängt ein Modell ab, das auf demselben fehlgeschlagenen Aufruf hin und her springt. Eine Kostenobergrenze fängt ein teures Tool oder eine teure Abfrage ab, die das Budget sprengt. Ein Zeitlimit fängt eine hängende externe API ab, die nie antwortet.

Die Schreckensgeschichte, die jedes Team irgendwann erzählt: ein Agent, der über Nacht vierzig Mal dasselbe Tool mit denselben Parametern aufruft, eine erschreckende Rechnung und keine Antwort. Mit Guardrails bricht ein festgefahrener Lauf stattdessen mit einer Teilantwort und einem protokollierten Limit ab. Die Antwort sollte zudem einen Verweis auf das tatsächlich Erledigte tragen (eine Buchungsnummer, eine Bestellnummer), damit ein fehlgeschlagener Schreibvorgang sofort auffällt, nicht erst drei Tage später im Support-Ticket.

3. Die Memory Layer: Drei Speicher, ein Rückschreibprozess

Das Kontextfenster stirbt in dem Moment, in dem der Lauf endet. Ohne eine Memory Layer ist jede Konversation die erste Konversation des Agenten, egal wie oft dieselbe Nutzerin schon dieselbe Frage gestellt hat.

Die Lösung: drei Speicherarten trennen. Prozedurales Gedächtnis beantwortet, wie zu handeln ist, und lebt in Skill-Dateien (wie eine individuelle Bestellung kalkuliert wird). Semantisches Gedächtnis beantwortet, was wahr ist, und lebt in einer Vektordatenbank (dauerhafte Fakten, Katalogdaten, Präferenzen). Episodisches Gedächtnis beantwortet, was geschehen ist, und lebt in SQL plus Vektoren (datierte Ereignisse, vergangene Threads). Die Trennung sorgt dafür, dass jeder Speicher bearbeitet werden kann, ohne die anderen zu beschädigen. Episodisches Gedächtnis nutzt bewusst beide Hälften: SQL beantwortet „Was haben wir letzten Dienstag zugesagt“, Vektoren beantworten „Wann haben wir über diese Allergie gesprochen“.

Den Rückschreibschritt lassen die meisten Teams aus. Jeder abgeschlossene Lauf sollte nach der Antwort in den Speicher zurückgeschrieben werden. Fehlt dieser Schritt, wirkt das Gedächtnis implementiert, obwohl tatsächlich nichts erhalten bleibt. Speichern Sie die Lauf-ID mit jedem Eintrag, damit eine schlechte Eval-Bewertung in der kommenden Woche exakt auf die verursachenden Runden zurückführbar ist.

Rohe Chat-Runden stapeln sich schnell, und ein halbes Jahr später liefert die Suche „Hallo“ und „Danke“ zurück statt echter Fakten. Ein günstiges Modell sollte in regelmäßigen Abständen rohe Runden zu strukturierten Fakten verdichten (Subjekt, Fakt, Quell-Lauf, Datum) und ins semantische Gedächtnis schreiben. Dieser Zusammenfasser sollte hinter einer Schwelle feuern, nach N neuen Chats oder einer Alterungsgrenze, nicht per Fünf-Minuten-Cron. Die Konsolidierungskosten folgen so der tatsächlichen Aktivität statt der Uhr, und da es sich um Kompressionsarbeit handelt, nicht um Schlussfolgerung, gehört dafür das günstigste, ausreichend fähige Modell eingesetzt.

4. Die RAG-Pipeline: Zwei Pfade, die sich in der Vektordatenbank treffen

Echtes Unternehmenswissen steckt in PDFs, Tabellen und Chat-Protokollen. Eine RAG-Pipeline (Retrieval-Augmented Generation) macht dieses Wissen durchsuchbar, und die entscheidende Designentscheidung ist: zwei Pfade, zwei unterschiedliche Takte. Ablage läuft nach Zeitplan. Abfrage läuft im Takt der Nutzerin. Beide Pfade treffen sich ausschließlich in der Vektordatenbank.

Der Schreibpfad läuft offline und geplant. Quellen (Dokumente und Chats) tragen jeweils einen Eigentümer und ein Datum. Chunking teilt Inhalte nach Abschnitt, mit Überlappung, Metadaten bleiben erhalten. Embedding nutzt ein festgelegtes Modell, nicht das jeweils aktuellste. Die Speicherung landet in der Vektordatenbank plus SQL-Metadaten und speist das semantische Gedächtnis.

Der Lesepfad läuft live, pro Anfrage. Die tatsächliche Absicht wird eigenständig aus dem Thread neu formuliert. Die Anfrage wird mit demselben Modell eingebettet, das auch beim Schreiben verwendet wurde. Retrieval liefert die nächsten Nachbarn (Top-k) mit Berechtigungs- und Datumsfiltern. Reranking, meist über einen Cross-Encoder, behält die besten wenigen. Assembly platziert das Ergebnis im Kontextfenster, mit Quelle und Datum versehen.

Vier Regeln erledigen den größten Teil der Arbeit. Niemals Dokumente live während einer Anfrage einbetten: Das ist langsam, teuer und später nicht reproduzierbar, ein nächtlicher Job aktualisiert stattdessen den Index, während Live-Anfragen weiter den bestehenden Index bedienen. Absicht einbetten, nicht die wörtliche Nachricht: „Und die günstigere Option?“ liefert allein keine Treffer, das Thema steckt in früheren Runden. Der Lesepfad muss exakt dasselbe Embedding-Modell wie der Schreibpfad nutzen. Eine Abweichung wirft keinen Fehler, die Qualität bricht einfach ein, während jedes Dashboard grün bleibt. Und großzügig abrufen, streng filtern: zwanzig bis fünfzig Kandidaten hinein, drei bis acht nach dem Reranking hinaus, denn der Absatz, der die Frage tatsächlich beantwortet, liegt oft auf Rang elf. Jeder Chunk sollte zudem Quelle und Gültigkeitsdatum tragen. Wer eine Preisliste ohne Datum indexiert, zitiert irgendwann einen abgelaufenen Preis mit vollem Selbstbewusstsein.

5. LLM Ops: Von der Beschwerde zum reversiblen Release

Wenn jemand meldet „gestern kam die falsche Antwort“ und nur der Antworttext vorliegt, lässt sich nichts diagnostizieren. LLM Ops ist die Zone, die diesen Verbesserungskreislauf schließt.

Sechs Schritte bilden den Kreislauf. Trace erzeugt einen Datensatz pro Lauf: zusammengestellter Kontext, Tool-Aufrufe, Tokens, Latenz, Kosten, Prompt-Version. Observe verfolgt Gesundheitskennzahlen: p95-Latenz, Fehler- und Tool-Fehlerraten, Kosten pro Lauf. Eval nutzt ein Richter-Modell, das Läufe gegen eine Rubrik auf einem eingefrorenen Satz echter Fragen bewertet. Diagnose clustert Fehler nach Phase: Retrieval, Tool-Wahl oder Generierung. Gate wendet feste Schwellenwerte an, keine Regression auf irgendeiner Rubrik-Zeile ist erlaubt. Release liefert ein einziges reversibles Paket aus Prompt-Version, Modellkonfiguration, Tool-Änderungen und RAG-Parametern, hinter einem Canary-Rollout.

Observe und Eval beantworten unterschiedliche Fragen, „funktioniert es“ und „ist es gut“, und sie scheitern unabhängig voneinander. Bauen Sie das Referenz-Eval-Set aus echten Traces auf, peinliche Fälle eingeschlossen, und frieren Sie es dann ein, damit Bewertungen über Releases hinweg vergleichbar bleiben. Niemals mit demselben Modell und demselben Prompt bewerten, der getestet wird, es bewertet dann seinen eigenen Stil als korrekt. Erst diagnostizieren, dann reparieren: Ein Bewertungseinbruch nach einer Datenänderung ist meist ein Retrieval- oder Assembly-Fehler (abgeschnittene Chunks durch ein Token-Budget sind ein häufiger Fall), kein Prompt-Problem, auch wenn der Reflex in den meisten Räumen ist, freitagnachmittags den Prompt umzuschreiben. Gate pro Rubrik-Dimension statt über einen einzigen Durchschnitt, damit sich ein Rückgang bei der faktischen Fundierung nicht hinter hübscherer Formatierung verstecken kann. Und ein Release ist ein Paket, keine Prompt-Änderung: derselbe Prompt mit einem anderen Top-k oder einem anderen Modell ist ein anderes System. Versionieren Sie auch die Retrieval-Parameter, sonst stellt ein Rollback nur die halbe alte Systemversion wieder her, und das Rätsel bleibt bestehen.

Das Ergebnis eines Releases fließt zurück in den Harness: bessere Regeln und Konfiguration für jeden folgenden Lauf. Traces erzeugen Evals, Evals erzeugen eine Diagnose, Releases erzeugen bessere Läufe, die wiederum bessere Traces erzeugen. Genau dieser geschlossene Kreislauf ist der Unterschied zwischen einem überwachten und einem sich verbessernden System.

6. Warum die meisten Agenten bei „eigentlich ganz gut“ hängen bleiben

Dieses Muster hat GoTeams aus der Nähe beobachtet. Die meisten Teams bauen zuerst das Kontextfenster und den Lesepfad: den Harness und eine einfache RAG-Pipeline. Sie gehen live, die Demo überzeugt, die Nutzung wächst. Was fehlt, wird selten sichtbar, bevor es zu spät ist: kein Konsolidierungsschritt, kein Release-Gate, keine Trennung zwischen prozeduralem, semantischem und episodischem Gedächtnis. Die Qualität bricht nicht auf einen Schlag ein. Sie erodiert, eine still fallengelassene Anweisung und ein veralteter Retrieval-Treffer nach dem anderen, bis der Agent bei „eigentlich ganz gut“ stehen bleibt und niemand genau sagen kann, warum.

Genau dieses Muster steckt hinter Zennify, einem GoTeams Plus+ Venture, das eine Call-Center-Plattform zu einem skalierbaren Framework für KI-Assistenten ausgebaut hat: LLM-Orchestrierung, Sprachdienste und Twilio-Integration, von Beginn an als modulares, containerisiertes System aufgebaut. Das Team hat Orchestrierung nicht als nachträglichen Anbau an eine funktionierende Demo behandelt. Guardrails, Tool-Scoping und eine strukturierte Memory Layer gehörten von Sprint eins an zur Architektur, nicht zu einem Aufräumprojekt im vierten Quartal. Zennify betreibt heute über 200 Konfigurationsoptionen für Contact Center und ist europäischer Marktführer, unter anderem bei PMI, Nestlé, FlixBus und Illy Café im Einsatz. Die Lehre daraus ist nicht, dass GoTeams die fünf Zonen perfekt umsetzt. Sie ist, dass Teams, die Architektur als Aufgabe des ersten Tages behandeln, nicht als Aufgabe der Skalierungsphase, diejenigen sind, deren Agenten mit steigendem Volumen besser werden statt schlechter.

Häufig gestellte Fragen

Warum wird ein KI-Agent mit steigender Nutzung schlechter, obwohl sich das Modell nicht verändert hat?

Die Modellqualität bleibt konstant, die umgebende Architektur ist es, die unter Last bricht. Ohne einen Context Builder mit Token-Budgets, Guardrails für Tool-Aufrufe und eine Memory Layer, die nach jedem Lauf zurückschreibt, sammelt ein Agent stille Fehler an: fallengelassene Anweisungen, unbegrenzte Wiederholungsversuche und veraltete Retrieval-Treffer. Bei geringem Volumen fallen diese selten genug auf, um sie zu bemerken. Bei Skalierung summieren sie sich zum „eigentlich ganz gut“-Plateau, an dem die meisten Teams irgendwann hängen bleiben.

Was ist der am häufigsten übersprungene Teil der KI-Agenten-Architektur?

Der Rückschreibschritt in der Memory Layer. Teams bauen eine Vektordatenbank und nennen sie Gedächtnis, aber wenn abgeschlossene Läufe nach der Antwort nie zurückgeschrieben werden, bleibt zwischen Sitzungen tatsächlich nichts erhalten. Der Agent sieht aus, als hätte er ein Gedächtnis, verhält sich aber, als hätte er keines.

Braucht man alle fünf Zonen von Tag eins an?

Nicht in voller Tiefe, aber jede Zone braucht ihr Grundgerüst, bevor der Traffic skaliert. Eine produktionsreife RAG-Pipeline ohne Trace- und Eval-Kreislauf in LLM Ops bedeutet zum Beispiel, dass die erste Qualitätsbeschwerde nicht diagnostizierbar ist. Guardrails und Observability nachträglich einzubauen ist möglich, aber langsamer und riskanter, als das Grundgerüst zuerst zu bauen.

Was unterscheidet Lese- und Schreibpfad in einer RAG-Pipeline?

Der Schreibpfad läuft offline und geplant: Dokumente werden aufgeteilt, mit einem festgelegten Modell eingebettet und im Voraus gespeichert. Der Lesepfad läuft live, im Takt der Nutzerin, pro Anfrage: Er formuliert die Absicht aus dem Thread neu, bettet mit exakt demselben Modell ein, das beim Schreiben verwendet wurde, ruft großzügig ab und filtert streng nach dem Reranking. Beide Pfade treffen sich ausschließlich in der Vektordatenbank, und eine Abweichung zwischen ihren Embedding-Modellen scheitert lautlos, ohne Fehlermeldung, aber mit sichtbarem Qualitätsverlust.

Wie diagnostiziert man einen KI-Agenten, der „gestern die falsche Antwort gegeben hat“?

Nur mit einem Trace: einem Datensatz pro Lauf, der den zusammengestellten Kontext, Tool-Aufrufe, Tokens, Latenz und Prompt-Version festhält. Ohne diesen hat „die Antwort war falsch“ keinen Ausgangspunkt für eine Diagnose. Mit LLM Ops wird der Fehler zunächst nach Phase geclustert (Retrieval, Tool-Wahl oder Generierung), bevor jemand den Prompt anfasst, denn die meisten Qualitätseinbrüche gehen auf einen Retrieval- oder Assembly-Fehler zurück, nicht auf ein Prompt-Problem.

Das Fazit

Bauen Sie Ihre Agenten von Anfang an für Qualität bei Skalierung, nicht für die Demo. Ein Assistent mit einem einzigen Modellaufruf kann jeden Test bestehen, den eine Stakeholderin im Konferenzraum stellt, und trotzdem am ersten Tag mit echtem Traffic scheitern, weil die Demo nie einen Token-Budget-Überlauf, einen hängenden Tool-Aufruf oder sechs Monate veraltetes Retrieval überstehen musste. Die fünf Zonen (Harness, Agent Run, Memory Layer, RAG-Pipeline und LLM Ops) sind kein nachträglich angeflanschtes Enterprise-Upgrade. Sie sind der Unterschied zwischen einem Agenten, der bei „eigentlich ganz gut“ stehen bleibt, und einem, der mit steigender Nutzung zuverlässiger wird. GoTeams baut KI-orchestrierte Entwicklungsteams genau um diese Disziplin herum auf: das Urteilsvermögen des Modells gepaart mit den Guardrails, dem Gedächtnis und dem Release-Prozess, die es auch bei Skalierung rechenschaftspflichtig halten. Die nächste sinnvolle Investition ist selten ein größeres Modell. Es ist die am weitesten links fehlende Zone.