Ein Anbieter schickt Ihnen ein Angebot. Die Präsentation zeigt ein Diagramm mit Kästchen und Pfeilen: ein LLM in der Mitte, einige Datenbanken am Rand, ein paar API-Icons. Es sieht vollständig aus. Aber das Diagramm verrät Ihnen nicht, ob das System unter Last zuverlässig funktioniert, was passiert, wenn eine API ausfällt, wie viel jede Konversation im Betrieb kostet oder ob Sie in zwei Jahren den Anbieter wechseln können.
Diese Antworten stecken in der Architektur. Und Sie müssen kein Ingenieur sein, um die richtigen Fragen zu stellen.
Dieser Artikel übersetzt KI-Agenten-Architektur in die Begriffe, die bei der Beschaffung zählen: Zuverlässigkeit, Betriebskosten und Anbieterabhängigkeit. Betrachten Sie ihn als Checkliste zur Prüfung eines Anbieterkonzepts, bevor Sie unterschreiben.
Die vier Säulen, die jede KI-Agenten-Architektur hat (ob der Anbieter sie benennt oder nicht)
Ein produktionstauglicher KI-Agent besteht aus vier logischen Komponenten. Anbieter nennen sie unterschiedlich, kombinieren sie auf verschiedene Weise und bündeln sie manchmal in einer einzigen Plattform, in die man keinen Einblick hat. Aber sie sind immer vorhanden.
1. Der Planner (die „Denkschicht”)
Der Planner ist das Large Language Model (LLM) im Kern des Agenten. Er empfängt ein Ziel oder eine Nutzernachricht, überlegt, was als Nächstes zu tun ist, und entscheidet, welche Tools aufgerufen werden. Manche Architekturen verwenden einen einzigen LLM-Aufruf pro Schritt; andere führen mehrere Denkrunden durch, bevor sie handeln.
Was Sie den Anbieter fragen sollten:
- Welches LLM-Modell steuert den Planner, und wie wird es aktualisiert? (Ein Modell-Update, das das Verhalten ohne Vorankündigung ändert, ist ein Zuverlässigkeitsrisiko.)
- Ist der Planner deterministisch oder probabilistisch? Können Sie Konfidenz-Schwellenwerte oder Fallback-Bedingungen festlegen?
- Wie wird der Planner instruiert? Haben Sie Einblick in den System-Prompt oder Kontrolle darüber?
2. Die Tools (die „Hände” des Agenten)
Tools sind die Verbindungen zur Außenwelt: Datenbankabfragen, API-Aufrufe, Formularübermittlungen, Dateilesen, E-Mail-Versand. Ein Agent ohne Tools ist nur ein Chatbot. Die Tool-Schicht ist der Ort, an dem Agenten tatsächlich handeln.
Anzahl, Zuverlässigkeit und Umfang der Tools bestimmen, was der Agent leisten kann — und was er versehentlich tun könnte. Ein Tool, das E-Mails versenden kann, ist nützlich; eines, das E-Mails ohne Genehmigungsschritt an beliebige Empfänger senden kann, ist ein Haftungsrisiko.
Was Sie den Anbieter fragen sollten:
- Auf welche Tools hat der Agent Zugriff, und kann dieser Satz eingeschränkt werden?
- Werden Tool-Aufrufe auf prüfbare Weise protokolliert?
- Was passiert, wenn ein Tool-Aufruf fehlschlägt — wiederholt der Agent den Versuch, eskaliert er an einen Menschen oder schlägt er stillschweigend fehl?
3. Memory (was der Agent sich merkt)
Memory in der KI-Agenten-Architektur ist differenzierter, als es klingt. Es gibt mindestens drei verschiedene Typen:
- Kurzzeitgedächtnis: der aktuelle Gesprächskontext, gehalten im Context Window des LLM. Es wird am Ende der Sitzung zurückgesetzt.
- Langzeitgedächtnis: Fakten, die in einer Datenbank gespeichert und bei Bedarf abgerufen werden — Kundenhistorie, Produktwissen, frühere Interaktionen.
- Prozedurales Gedächtnis: Regeln, Workflows und Muster, die in die Anweisungen des Agenten oder sein Fine-Tuning eingebettet sind.
Das Memory-Design hat direkten Einfluss auf die Nutzererfahrung und die Kosten. Agenten mit gut gestaltetem Langzeitgedächtnis wirken kohärent und kontextbewusst. Agenten, die ausschließlich auf das Kurzzeitgedächtnis angewiesen sind, stellen Fragen erneut, die Nutzer bereits beantwortet haben.
Was Sie den Anbieter fragen sollten:
- Welche Memory-Typen umfasst die Architektur?
- Wo werden Kundendaten gespeichert und unter welcher Jurisdiktion? (Für Schweizer Unternehmen ist das relevant für die nDSG-Konformität — siehe unseren Artikel zu KI-Agenten und Schweizer Datenschutz.)
- Kann das Langzeitgedächtnis gelöscht oder korrigiert werden, wenn es fehlerhafte Informationen enthält?
4. Guardrails (die Sicherheits- und Kontrollschicht)
Guardrails sind die Beschränkungen, die den Agenten auf Kurs und innerhalb akzeptablen Verhaltens halten. Sie wirken auf mehreren Ebenen: Eingabefilterung (Blockierung schädlicher oder out-of-scope-Anfragen), Ausgabe-Validierung (Prüfung von Antworten vor dem Versand), Scope-Limits (Verhinderung, dass der Agent Aktionen außerhalb seiner definierten Rolle ausführt) und Eskalationslogik (Erkennung, wann an einen Menschen übergeben werden soll).
Dies ist die Komponente, die in Anbieter-Demos am häufigsten unterbestimmt ist. Eine Demo funktioniert, weil der Anbieter die Eingaben kontrolliert. Der Produktionsbetrieb funktioniert, weil die Guardrails halten, wenn die Eingaben unvorhersehbar sind.
Was Sie den Anbieter fragen sollten:
- Was passiert, wenn ein Nutzer versucht, den Agenten zu etwas außerhalb seines Aufgabenbereichs zu bringen?
- Gibt es eine Human-in-the-Loop-Option für risikobehaftete Aktionen (große Transaktionen, Zugriff auf sensible Daten)?
- Wie werden Guardrail-Regeln aktualisiert, wenn sich das Unternehmen weiterentwickelt?
Wie Architekturentscheidungen Ihre Betriebskosten beeinflussen
KI-Agenten-Kosten sind keine reine Lizenzgebühr. Die Architektur bestimmt einen erheblichen Teil der Kosten pro Interaktion, die sich im Massstab kumulieren.
Der wichtigste Kostentreiber ist der LLM-Token-Verbrauch. Jede Nachricht im Context Window kostet Geld. Ein Agent, der bei jedem Schritt die vollständige Gesprächshistorie übergibt — statt strukturiertes Langzeitgedächtnis zu nutzen —, verbraucht Token linear mit der Gesprächslänge. Für ein Unternehmen, das täglich Hunderte von Interaktionen verarbeitet, bestimmt die Architekturentscheidung die Kostenkurve.
Weitere Kostentreiber, die es zu prüfen gilt:
- Tool-Call-Häufigkeit: mehr Tool-Aufrufe pro Interaktion bedeuten mehr Latenz und manchmal zusätzliche Drittanbieter-API-Kosten.
- Modell-Tier: manche Architekturen verwenden teure Frontier-Modelle für jeden Schritt; andere reservieren diese für komplexes Reasoning und nutzen leichtere Modelle für einfachere Teilaufgaben (ein Muster, das manchmal als „Model Cascade” bezeichnet wird).
- Retry-Logik: ein Agent, der fehlgeschlagene Tool-Aufrufe ohne Circuit-Breaker-Logik wiederholt, kann die Kosten bei Ausfällen vervielfachen.
Vendor Lock-in steckt in der Architektur, nicht im Vertrag
Das am häufigsten übersehene Beschaffungsrisiko bei KI-Agenten-Projekten ist der architektonische Lock-in. Ein Vertrag kann Ausstiegsklauseln enthalten; eine Architektur lässt sich nicht immer günstig migrieren.
Lock-in akkumuliert sich typischerweise an drei Stellen:
Proprietäre Memory-Speicher: Wenn das Langzeitgedächtnis des Agenten in einem anbieterspezifischen Datenbankformat gespeichert ist, bedeutet Migration das erneute Importieren und Validieren aller historischen Kontexte — oft Monate akkumulierter Daten.
Fest kodierte Tool-Integrationen: Agenten, die direkt auf dem SDK eines Anbieters mit proprietären Tool-Calling-APIs aufgebaut sind, müssen beim Plattformwechsel neu geschrieben werden. Anders verhält es sich bei Agenten, die auf offenen Standards wie dem Model Context Protocol (MCP) basieren, bei denen Tools portabler sind. Wir gehen in KI-Agenten-Plattform-Lock-in: die Risiken, die niemand einpreist näher darauf ein.
Modellabhängigkeit: Wenn die Planner-Logik stark auf die Eigenheiten eines bestimmten Modells zugeschnitten wurde (etwa eines Modells, das inzwischen eingestellt oder erheblich aktualisiert wurde), kann die Migration zu einem anderen LLM eine vollständige Neukalibrierung des gesamten Systems erfordern.
Die sichersten Architekturen halten diese Schichten locker gekoppelt: Der Planner kann Modelle wechseln, die Memory-Schicht nutzt Standard-Retrieval-Muster, die Tools verbinden sich über dokumentierte APIs oder offene Protokolle. Das ist nicht immer im Rahmen von Budget und Zeitplan realisierbar, aber es ist die Frage, die gestellt werden muss.
Eine praktische Audit-Checkliste vor der Entscheidung
Bei der Bewertung eines KI-Agenten-Angebots fördern diese Fragen die Designqualität schneller zutage als jede Demo:
Zuverlässigkeit
- Was ist das Failover-Verhalten, wenn die LLM-API nicht verfügbar ist?
- Wie geht der Agent mit mehrdeutigen oder widersprüchlichen Eingaben um?
- Gibt es einen Mechanismus zur Erkennung und Unterbrechung von Endlosschleifen oder unkontrollierten Tool-Chains?
Kosten
- Was sind die geschätzten Token-Kosten pro Interaktion, und wie skalieren sie mit der Gesprächslänge?
- Verwendet die Architektur ein einziges Modell für alle Aufgaben oder einen nach Kosten gestaffelten Ansatz?
Lock-in
- Welche Komponenten sind proprietär, und welche nutzen offene Standards?
- Wo werden Daten gespeichert, und in welchem Format sind sie exportierbar?
- Was müsste neu geschrieben werden, wenn Sie den LLM-Anbieter wechseln würden?
Kontrolle
- Welche Guardrails sind vorhanden, und wer kann sie ändern?
- Gibt es ein vollständiges Audit-Log der Tool-Aufrufe und Agenten-Entscheidungen?
Wann Architektur-Reviews besonders wichtig sind
Nicht jedes KI-Agenten-Projekt erfordert eine tiefgehende Architekturprüfung bei der Beschaffung. Ein einfacher FAQ-Chatbot ohne Tool-Zugriff und ohne Datenpersistenz ist unabhängig von seiner Bauweise risikoarm.
Der architektonische Einsatz steigt mit:
- Tool-Zugriff auf sensible Systeme (CRM, ERP, Finanzdaten, Kundendaten)
- Hohem Interaktionsvolumen, bei dem sich der Preis pro Interaktion kumuliert
- Mehrstufigen autonomen Workflows, bei denen sich eine frühe Fehlentscheidung fortsetzt
- Regulatorischer Exposition — alles, was personenbezogene Daten unter der DSGVO, dem Schweizer nDSG oder beiden betrifft — viele Schweizer Unternehmen unterliegen gleichzeitig beiden Regelwerken
Wenn Ihr Anwendungsfall in eine dieser Kategorien fällt, verstehen Sie die Architektur vor dem Vertrag, nicht danach. Für einen umfassenderen Blick auf gutes agentisches Design, siehe KI-Agenten-Orchestrierung: Agenten als System zum Einsatz bringen und Was sind KI-Agenten? Ein hype-freier Leitfaden für Führungskräfte.
Die Build-vs-Buy-Entscheidung wird ebenfalls durch die Architektur geprägt: Plattformen tauschen Konfigurierbarkeit gegen Geschwindigkeit; Custom Builds tauschen Geschwindigkeit gegen Kontrolle. Build vs Buy: ein Entscheidungsrahmen für KI-Agenten beleuchtet diesen Trade-off direkt.
Wie eine gute Architekturprüfung aussieht
Bei Orange ITS kartieren wir beim Assessment eines KI-Agenten-Projekts — ob wir es selbst bauen oder ein bestehendes System prüfen — die vier Komponenten explizit, bevor wir eine Zeile Code schreiben. Das bedeutet: das Modell des Planners und sein Fallback-Verhalten definieren, festlegen welche Tools der Agent unter welchen Bedingungen aufrufen kann, das Memory-Modell für Performance und Datenhaltung entwerfen und die Guardrail-Logik vor dem Happy Path schreiben.
Das ist wenig glamourös. Es ist auch der Grund dafür, dass Systeme, die so gebaut werden, ihre Eigentümer sechs Monate später nicht mit explodierenden API-Rechnungen, Compliance-Fragen oder einem Anbieter überraschen, der sagt, die Migration koste mehr als der ursprüngliche Aufbau.
Wenn Sie ein KI-Agenten-Projekt evaluieren und eine zweite Meinung zu einem Anbieterangebot möchten — oder eine nüchterne Einschätzung, welche Architektur zu Ihrem Anwendungsfall passt — ist ein 30-minütiges Gespräch mit unserem Team der schnellste Weg dorthin. Wir kartieren die vier Komponenten anhand Ihrer Anforderungen und zeigen, wo das Design trägt und wo es versteckte Risiken birgt.