In Teil 1 haben wir drei Diagnosefragen gestellt. Wenn Sie sie mit Ihrem Team durchgearbeitet haben, wissen Sie jetzt: Welche Kontextschichten fehlen? Ob Context Rot bereits Ihre Qualität beeinträchtigt. Und ob Ihre Kosten unkontrolliert wachsen. Die meisten Unternehmen überspringen diese Diagnose vollständig - sie gehen direkt vom Piloten zur Optimierung, ohne zu wissen, was sie optimieren. Wenn Sie Antworten haben, auch näherungsweise, sind Sie den meisten KI-Programmen in Europa voraus.
Jetzt kommt die Architektur. Dieser Artikel behandelt die vier Designentscheidungen, die Level 2 von Level 3 trennen: Datenschichten-Design, Kompressionsstrategie, Human-Oversight und Multi-Agenten-Orchestrierung. Zusammen bestimmen sie, ob Ihre KI-Agenten zuverlässig funktionieren - oder nur gelegentlich.
Die erste Entscheidung: Memory-Architektur
Die folgenreichste Architekturentscheidung für einen Enterprise-KI-Agenten ist nicht die Modellwahl. Es ist das Design der Datenschichten. In den meisten Projekten entsteht dieses Design nicht - es wächst unkontrolliert. Jemand konfiguriert eine Dokumentensuche. Jemand anderes fügt Gesprächshistorie hinzu. Ein drittes Team bindet ein Nutzerprofil an. Am Ende ist das Kontextfenster mit Informationen aus drei Systemen in drei Formaten gefüllt - ohne Logik dafür, was hineingehört und was nicht. Ein Agent, der bei den ersten drei Austauschen präzise antwortet und bei Austausch fünfzehn inkohärent wird.
Agenten benötigen drei grundlegend verschiedene Informationskategorien - jede mit anderem Rhythmus, anderer Dringlichkeit, anderem Ort:
| Schicht | Was sie enthält | Aktualisierung |
|---|---|---|
| Aktive Sitzung | Laufendes Gespräch, aktueller Aufgabenstatus, Daten aus System-Abfragen dieser Sitzung | Jeden Austausch |
| Nutzerprofil | Sprachpräferenz, Vertragsniveau, Zusammenfassungen letzter Sitzungen, offene Aufgaben | Pro Sitzung oder täglich |
| Wissensdatenbank | Produktdaten, Richtliniendokumente, regulatorische Leitlinien, Compliance-Handbücher, FAQs | Bei Änderungen - wöchentlich oder seltener |
Das typische Fehlermuster: Alles landet in der Wissensdatenbank. Eine einzige Dokumentensuche, bei jeder Anfrage vollständig geladen. Das korrekte Design ist selektiv: Für einen Kundenservice-Agenten bei einem Rechnungsstreit enthält die Aktive Sitzung das Gespräch und die ERP-Daten dieser Rechnung; das Nutzerprofil lädt Sprachpräferenz, Vertragsniveau und offene Tickets; die Wissensdatenbank liefert nur die zwei, drei Richtlinienabschnitte, die diesem Streittyp am nächsten sind. Jede Schicht wird explizit verwaltet.
Das ist kein Retrieval-Problem. Es ist ein Design-Problem. Die Frage lautet nicht: "Wie rufen wir die richtigen Informationen ab?" Sie lautet: "Was sind die richtigen Informationskategorien, und wo gehört jede davon hin?"
Die zweite Entscheidung: Kontextkomprimierung
Sobald die Datenschichten stehen, taucht das nächste Problem auf: Kontexte wachsen. Lange Sitzungen akkumulieren. Autonome Prozesse häufen sich. Ohne aktives Management erreicht jeder Kontext dasselbe Ziel: Aufblähung, höhere Kosten, schlechtere Qualität, Context Rot. Das WSCI-Framework - Window, Summarise, Compress, Isolate - hält Kontexte schlank, ohne Kontinuität zu opfern.
Window
Halten Sie nur die jüngsten Austausche vollständig. Für die meisten transaktionalen Workflows - Support-Tickets, Genehmigungsketten, Standardanfragen - sind acht bis zwölf Austausche ausreichend. Die Disziplin: die Fenstergröße ist explizit festgelegt, nicht unbegrenzt wachsen gelassen.
Summarise
Statt ältere Austausche zu verwerfen, komprimieren Sie sie zu strukturierten Zusammenfassungen. Eine fünfzehn Austausche umfassende Rechnungseskalation wird zu: "Kunde: Q3-Rechnungsstreit, 12.400 €. Problem: falscher MwSt.-Satz. Lösung: Gutschrift ausgestellt. Status: Finanzbestätigung ausstehend." Vierzig Wörter ersetzen 1.800 Token. Der Agent behält das Wesentliche, das Fenster gewinnt Platz für Neues.
Compress
Reduzieren Sie Systemdaten, bevor sie den Kontext betreten. Eine SAP-S/4HANA-Antwort kann 4.000 Token XML zurückgeben. Strukturierte Extraktion der aufgabenrelevanten Felder reduziert das auf 200 Token. Gleicher Informationsgehalt, 95% niedrigere Kosten. Kein Modellwechsel erforderlich.
Isolate
Halten Sie Informationskategorien in klar abgegrenzten Abschnitten: Anweisungen oben, abgerufene Dokumente danach, Systemdaten mit Quelle und Zeitstempel beschriftet, Gesprächshistorie zuletzt. Eine Anweisung in der Mitte einer langen Gesprächshistorie wird weniger zuverlässig befolgt als dieselbe Anweisung ganz oben.
Ein Produktionssystem, das alle vier WSCI-Elemente implementiert, erzielt typischerweise 40–70% Reduktion der Token-Kosten pro Interaktion ohne messbare Qualitätsverluste. Die Qualität verbessert sich häufig - weil das Modell den richtigen Informationen Aufmerksamkeit widmet, nicht allem.
Die dritte Entscheidung: Human-Oversight-Design
Kein Enterprise-KI-Agent sollte eine folgenreiche Aktion - E-Mail versenden, CRM-Eintrag aktualisieren, Zahlung initiieren, Anfrage genehmigen - ohne menschlichen Kontrollpunkt ausführen. Das ist keine regulatorische Pflicht. Es ist eine Qualitätsentscheidung. Der menschliche Prüfschritt ist kein Overhead - er ist das Signal mit dem höchsten Informationsgehalt in Ihrem System.
Wenn ein Support-Lead einen KI-Entwurf bearbeitet, bevor er ihn versendet, kodiert diese Bearbeitung etwas, das kein Training replizieren kann: wie Ihre Organisation wirklich kommuniziert, welches Detail für diesen Kunden falsch war, welche Nuance das Modell übersehen hat. Die Konsequenz: protokollieren Sie jede Bearbeitung. Bearbeitungen im Bereich 5–50% sind Ihr wertvollstes Signal - informativ genug, um zu lernen, spezifisch genug, um echte Korrekturen zu enthalten. Nutzen Sie sie als Beispiele für ähnliche Interaktionen. Qualität potenziert sich über die Zeit, auf eine Weise, die exklusiv für Ihre Organisation ist.
Die menschliche Bearbeitung ist kein Overhead. Sie ist der Mechanismus, durch den Ihr KI-Agent über Zeit spezifisch für Ihre Organisation wird - auf eine Weise, die kein generisches Modell replizieren kann.
Dazu kommt der regulatorische Aspekt: Der EU AI Act und sektorspezifische Rahmenwerke verlangen nachweisbare menschliche Aufsicht für Hochrisiko-KI-Entscheidungen. Eine gut entworfene Review-Architektur ist beides gleichzeitig: Qualitätsmechanismus und Compliance-Nachweis. Aus einer einzigen Entscheidung.
Die vierte Entscheidung: Multi-Agenten-Orchestrierung
Die meisten Unternehmens-Workflows sind nicht einstufig. Eine Vertragsüberprüfung erfordert Rechtsanalyse, Finanzrisiko, Compliance und Zusammenfassung - parallel. Eine Lieferkettenunterbrechung erfordert gleichzeitig Logistikalternativen, Lieferantenkommunikation, Kundenbenachrichtigung und Bestandsanpassung. Ein einzelner Agent kann das nicht bewältigen: der Kontext kollabiert unter der Breite, und das spezialisierte Wissen jeder Teilaufgabe koexistiert nicht sauber in einem Fenster.
Multi-Agenten-Architekturen verteilen Aufgaben auf spezialisierte Agenten, koordiniert durch einen Orchestrator. Drei Muster sind relevant:
Der Orchestrator weist denselben Input - ein Dokument, einen Fall, eine Anfrage - gleichzeitig mehreren Spezialagenten zu. Ein Vertrag wird zeitgleich von einem Rechtsagenten, einem Finanzrisikoagenten und einem Compliance-Agenten geprüft. Jeder Agent operiert mit einem sauberen, aufgabenspezifischen Kontext, der nur das enthält, was er benötigt. Die Gesamtlaufzeit entspricht der Dauer des langsamsten Sub-Agenten - nicht der Summe aller drei.
Ideal für: mehrdimensionale Analyseaufgaben, bei denen derselbe Input aus mehreren unabhängigen Expertenperspektiven bewertet werden muss.
Der Output eines Agenten wird zum strukturierten Input des nächsten. Dokumentparser → Entitätsextraktor → Compliance-Prüfer → Genehmigungsentwurf. Jeder Agent in der Kette erhält genau die Informationen, die er benötigt - als strukturierten Input aus der vorherigen Stufe. Die entscheidende Ingenieursdisziplin ist das Übergabeformat: jeder Agent-Output muss explizit für den Kontext des nächsten Agenten strukturiert sein - nicht als Freitext hinterlassen, den der nächste Agent neu interpretieren muss.
Ideal für: dokumentenintensive Branchen - Schadensfallbearbeitung, regulatorische Einreichungen, pharmazeutische Chargendokumentation, Vertragserstellung aus Vorlagen.
Alle Agenten eines Workflows teilen eine gemeinsame, schreibgeschützte Kontextschicht - das Kundenkonto, den anwendbaren regulatorischen Rahmen, das Projektbriefing - während sie vollständig separate Kontexte für ihre Fachaufgaben behalten. Das verhindert Duplizierung, stellt Konsistenz im Workflow sicher und hält den operativen Kontext jedes Agenten schlank.
Ideal für: langandauernde Enterprise-Workflows, bei denen mehrere Agenten dieselbe Grundinformation benötigen, aber im Zeitverlauf unterschiedliche Arbeitskontexte haben.
Der häufigste Multi-Agenten-Fehler ist Context Bleed: Sub-Agenten erhalten Informationen aus den Aufgaben anderer Agenten, die für ihre eigene Arbeit keine Relevanz haben. Die Lösung ist strikte Kontextbegrenzung auf Orchestrierungsebene - jeder Sub-Agent erhält nur, was seine spezifische Aufgabe erfordert. Nichts, das von seinen Nachbarn übertragen wurde.
Die unterschätzte Anforderung: Kontexttransparenz
Nichts davon kann optimiert werden, wenn Sie nicht sehen können, was im Kontext steht, wenn das Modell antwortet. Kontexttransparenz ist kein Debugging-Feature - es ist eine Produktionsüberwachungsanforderung: ein Mechanismus, der zeigt, welche Dokumente abgerufen wurden, aus welcher Schicht, wie viele Token jede Schicht verbrauchte, wie der vollständige Prompt aussah.
In einem Deployment gab die Nutzerprofil-Abfrage elf Tage lang still einen leeren Ergebnissatz zurück - aufgrund eines Datenbankindex-Problems. Der Agent operierte ohne Kundenpräferenz-Kontext. Die Qualitätsverschlechterung wurde als Modell-Drift fehldiagnostiziert. Sobald ein Visualizer den leeren Slot sichtbar machte, war die Lösung in zwanzig Minuten umgesetzt. Elf Tage degradierter Outputs, die nicht hätten sein müssen.
Für europäische Unternehmen dient Kontexttransparenz auch als Prüfpfad. DSGVO-Auskunftsanfragen erfordern Rekonstruktion, welche Kundendaten in welcher Interaktion verwendet wurden. Der EU AI Act (Artikel 13) verlangt Dokumentation der KI-Inputs. Ein Kontextprotokoll liefert beides automatisch - wenn die Architektur von Anfang an darauf ausgelegt ist.
Sie können nicht einhalten, was Sie nicht protokollieren. Sie können nicht optimieren, was Sie nicht sehen können.
Was Level 3 tatsächlich bedeutet
Ein korrekt kontext-engineerter Enterprise-Agent hat diese Eigenschaften - und alle sind erreichbar:
- Jede Schicht ist explizit entworfen. Datenkategorien definiert, Kompressionsschwellen gesetzt, Isolationsgrenzen durchgesetzt.
- Kosten pro Interaktion sind bekannt, stabil - skalieren nicht steil mit der Sitzungslänge.
- Antwortqualität bei Austausch zwanzig ist messbar nah an Austausch drei.
- Jede menschliche Bearbeitung wird erfasst und als Signal für ähnliche künftige Interaktionen genutzt.
- Jede KI-Interaktion hat ein vollständiges, abfragbares Protokoll, das Audit- und Compliance-Anforderungen erfüllt.
- Das System weiß, was es nicht weiß - und leitet zur menschlichen Prüfung weiter, statt zu raten.
Die meisten Teams sind noch nicht dort. Der Weg von Level 1 zu Level 3 ist ein Arbeitsprogramm, kein Sprint. Die vier Entscheidungen oben sind die Reihenfolge.
Drei Schritte für diese Woche
Drei konkrete Schritte - jeder innerhalb eines einzelnen Sprints umsetzbar:
Bauen Sie ein Kontextprotokoll für Ihre kritischste Agenten-Interaktion
Es muss nicht aufwändig sein - ein Protokoll, das den vollständigen Prompt, Token-Anzahl pro Schicht und Modellantwort erfasst, durchsuchbar nach Sitzungs-ID und Zeitstempel, reicht aus. Bauen Sie das zuerst, bevor Sie irgendetwas optimieren.
Komprimierungs-Audit für Ihre kostenintensivsten Systemabfragen
Identifizieren Sie die drei Abfragen, die pro Sitzung die meisten Daten zurückgeben. Extrahieren Sie nur die Felder, die der Agent tatsächlich benötigt, bevor die Daten den Kontext betreten. Messen Sie vorher und nachher. In den meisten Deployments reduziert dieser Schritt die Kosten um 20–40% - ohne Modellwechsel.
Protokollieren Sie Ihre Human-Review-Bearbeitungen
Überall, wo Menschen KI-Outputs prüfen, bevor eine Aktion folgt - E-Mails, Zusammenfassungen, Berichte - protokollieren Sie beide Versionen und berechnen Sie den Bearbeitungsanteil. Bearbeitungen im 5–50%-Bereich sind Ihr wertvollstes Signal. Nutzen Sie eine Auswahl davon als Beispiele für ähnliche künftige Interaktionen.
Keiner dieser Schritte erfordert ein neues Modell, einen neuen Anbieter oder ein Framework. Nur Engineering-Aufmerksamkeit auf der richtigen Ebene - der Kontextebene.