# Bau keinen Agenten. Bau die Agentenfabrik.
Einen KI-Agenten kann jeder an einem Wochenende bauen. Ein gutes Modell, ein paar Tools, ein anständiger System-Prompt — und man hat eine Demo, die im Montagsmeeting beeindruckt. Über [den Unterschied zwischen Modell und Agent](/de/blog/ai-model-vs-agent) und darüber, [wie Agenten in Produktion aussehen](/de/blog/ai-agents-2026), habe ich bereits geschrieben; den Teil wiederhole ich nicht.
Das echte Problem taucht bei der zweiten Frage auf, die die Wochenend-Demo nie berührt: Was passiert, wenn **zehn Teams** jeweils ihren eigenen Agenten wollen? Jedes mit Zugriff auf das CRM, auf Tickets, auf Datenbanken. Jedes mit eigenen API-Keys, eigenen Prompts, eigener Vorstellung davon, was „funktioniert" bedeutet. Ohne Antwort auf diese Frage bekommt man, was ich derzeit in vielen Unternehmen sehe: einen Haufen Pilot-Agenten, die nie in Produktion gehen, weil niemand sagen kann, wer worauf zugreifen darf, wie gut etwas tatsächlich funktioniert und was beim nächsten Release kaputtgeht.
Die Antwort darauf ist nicht „noch ein Agent", sondern eine **Agentenarchitektur** — die interne Fabrik, über die jedes Team governte, getestete Agenten mit kontrolliertem Zugriff auf die Unternehmenssysteme ausliefern kann. Dieser Artikel geht die vier Bausteine dieser Architektur durch und erklärt, warum man jeden davon braucht.
## Die zwei Schichten
Zuerst eine Klärung, denn hier verheddern sich die meisten Diskussionen: Der Agent, den der Nutzer sieht, und die Plattform darunter sind unterschiedliche Schichten mit unterschiedlichen Problemen.
Die Anwendungsschicht ist das, was man für einen konkreten Anwendungsfall baut: Orchestrierung mit Sub-Agenten, RAG über die relevanten Dokumente, Freigabe-Gates, an denen ein Mensch sensible Aktionen validiert. Es ist die Schicht, die auch wir in Kundenprojekten bauen — und über die 95 % aller Agenten-Artikel geschrieben werden.
Die Plattformschicht ist das, was dafür sorgt, dass der **zweite, fünfte und zehnte** Agent nicht bei null anfängt. Sie beantwortet drei Fragen, die die Anwendung allein nicht lösen kann: Wer darf auf welches System zugreifen, wie gut ist ein Agent, bevor man ihn ausliefert, und wie erfährt Team B, dass der Agent von Team A schon existiert.
Der Rest des Artikels nimmt die untere Schicht Stück für Stück auseinander.
## Der Agentenkatalog: Register plus Evaluierungen, kein Wiki
Der erste Baustein klingt banal und ist der am meisten unterschätzte: ein **internes Agentenregister**. Jeder Agent hat einen Eintrag mit Beschreibung, den Tools, auf die er zugreifen darf, dem verantwortlichen Team und der aktuellen Version. Teams schauen hinein, bevor sie etwas Neues bauen — genau wie in ein Service-Register oder einen internen API-Katalog.
| Feld | Beispiel |
|---|---|
| Name | `support-triage-agent` |
| Beschreibung | Triagiert Support-Tickets und schlägt eine Antwort vor |
| Owner | Team Customer Platform |
| Version | 1.4.2 |
| Tools (über Gateway) | `crm.search` · `tickets.update` · `kb.retrieve` |
| Eval-Scores | Qualität 92 · Korrektheit 96 · Sicherheit 100 |
| Letzter Regressionslauf | bestanden · 27. August 2026 |
Der Unterschied zu einem Wiki sind die letzten beiden Zeilen. Ein Katalog ohne Evaluierungen ist eine Liste von Versprechen; ein Katalog mit Evaluierungen ist ein Vertrag. Zu jedem Agenten gehören **Testsets** — reale Eingabeszenarien mit erwarteten Ergebnissen — und Scores auf drei Achsen: Qualität (wie nützlich die Antworten sind), Korrektheit (wie viele Aussagen faktisch stimmen, wie viele Aktionen die richtigen sind) und Sicherheit (er lehnt ab, was er ablehnen muss, leakt keine Daten zwischen Kunden, handelt nicht außerhalb seines Mandats).
Die Regel, die alles zusammenhält: **Eine neue Version wird nicht in den Katalog veröffentlicht, wenn sie die Evaluierungen nicht besteht.** Einschließlich — vor allem — der alten Suite. Ein Agent, der mit v1.4 einen neuen Fall löst, aber drei Fälle kaputtmacht, die mit v1.3 funktionierten, wird nicht ausgeliefert. Das ist CI/CD, angewendet auf Agenten:
Der nicht-deterministische Teil ist das einzig wirklich Neue. Ein Code-Test ist binär; eine Agentenantwort ist „gut genug" oder eben nicht. Deshalb kombinieren Evaluierungen exakte Checks (wurde das richtige Tool aufgerufen? wurde das Format eingehalten?) mit **LLM-as-Judge** — einem Modell, das die Antwort nach einer von Menschen geschriebenen Rubrik bewertet. Nicht perfekt, aber konsistent, günstig, und es läuft bei jedem Release — was ein menschliches Review nicht kann.
Auf AWS gibt es diesen Baustein als Service — die Evaluierungen in Amazon Bedrock AgentCore —, er lässt sich aber genauso gut als eigene Pipeline bauen: ein Satz Szenarien in Git, ein Job, der den Agenten durchlaufen lässt, und ein Judge, der bewertet. Entscheidend ist das Gate, nicht das Werkzeug.
## Das Gateway: ein einziger Ort, an dem Agenten die Welt berühren
Der zweite Baustein löst ein Rechenproblem. Drei Agenten, die direkt mit fünf Systemen sprechen, bedeuten fünfzehn Integrationen: fünfzehn Orte mit Credentials, fünfzehn Orte zum Auditieren, fünfzehn Implementierungen von Rate Limiting — meistens null. Jeder neue Agent multipliziert das Problem.
Das Gateway macht aus N × M ein N + M: Agenten sprechen mit einer einzigen Schicht, und diese Schicht weiß, **wer worauf zugreifen darf**.
Konkret zentralisiert das Gateway vier Dinge, die sonst jedes Team schlecht und unterschiedlich nachbaut: **Authentifizierung** (Agenten bekommen Identitäten, keine in Prompts kopierten API-Keys), **Autorisierung** (der Support-Agent sieht Tickets, nicht Gehälter), **Rate Limiting** (ein Agent in einer Schleife bringt das CRM nicht in die Knie) und **Logging** (jeder Tool-Aufruf, mit der Identität des Agenten — die einzige Art, jemals „wer hat diesen Datensatz geändert?" zu beantworten).
Die zweite, weniger offensichtliche, in der Praxis aber enorme Funktion: Das Gateway **übersetzt bestehende APIs in MCP-Tools, ohne sie neu zu schreiben**. Es gibt eine interne REST-API oder eine Lambda-Funktion? Am Gateway beschrieben, wird sie zum Tool, das jeder kompatible Agent aufrufen kann. Auf AWS macht genau das AgentCore Gateway; dasselbe Muster lässt sich auch eigenständig bauen.
## MCP-Server: die Schicht, die die Tools tatsächlich bereitstellt
Unter dem Gateway sitzen die Server, die Tools und Daten tatsächlich bereitstellen: CRM, Tickets, Dokumente, Datenbanken. Über [MCP aus der Perspektive eines lokalen Setups](/de/blog/mcp-lm-studio) habe ich schon geschrieben; auf Enterprise-Ebene ist die Logik identisch, nur der Einsatz höher — MCP verhindert, dass die Plattform zu einem Haufen proprietärer Integrationen wird.
Weil das Protokoll ein Standard ist, kann der MCP-Server für Tickets, den ein Team schreibt, von jedem Agenten im Unternehmen genutzt werden — egal, mit welchem Framework der Agent gebaut ist. Und wenn die eigenen Vendoren selbst MCP-Server anbieten — immer häufiger —, stellt man sie hinter dasselbe Gateway, und sie bekommen dieselben Zugriffsregeln und denselben Audit-Trail wie die internen Tools. Das Paar Gateway + MCP macht aus „Integration" statt eines Drei-Wochen-Projekts einen Konfigurationseintrag.
## RAG: geteilt, nicht pro Agent neu erfunden
Der letzte Baustein ist der, den man schon kennt — mit einer Positionskorrektur. RAG taucht in beiden Schichten auf, aber jede baut etwas anderes: Die Anwendung entscheidet, *was gefragt wird und was mit der Antwort passiert*; die Plattform besitzt *die Leitungen* — Dokumenten-Ingestion, Indexierung, Embeddings und vor allem **berechtigungsbewusstes Filtern zum Zeitpunkt der Suche**. Wenn jedes Team seine eigene Ingestion-Pipeline baut, bekommt man fünf Indizes, die unterschiedlich schnell altern, und mindestens einen, der vertrauliche Dokumente an das falsche Publikum ausliefert. Retrieval ist Infrastruktur, wie die Datenbank; die Frage „welche Dokumente darf dieser Agent sehen" gehört der Plattform, nicht den guten Absichten jedes einzelnen Prompts.
## Warum man eine Agentenarchitektur braucht
Weil sich keines der obigen Probleme innerhalb eines Agenten lösen lässt. Man kann den besten Agenten der Welt schreiben und hat trotzdem keine Antwort auf „wer darf worauf zugreifen", „wie gut ist er vor dem Release" und „was geht beim nächsten kaputt" — das sind Eigenschaften des Systems um die Agenten herum, nicht eines einzelnen Agenten.
Und betrachtet man die vier Bausteine zusammen, fällt auf: Keiner davon handelt im engeren Sinne von KI. Der Katalog ist Governance. Die Evaluierungen sind QA. Das Gateway ist Security und Networking. Geteiltes RAG ist eine Datenplattform. Das Modell — der „KI"-Teil — ist eine Abhängigkeit, nicht das Produkt. Deshalb ist das ein Architekturproblem, kein Problem besserer Prompts.
Das ist, glaube ich, die nützlichste Linse für diesen Moment: Bei Agenten stehen wir dort, wo Software vor DevOps stand. Jeder kann einen schreiben; fast niemand hat die Pipeline, die ihn sicher ausliefert, misst und aussortiert, wenn er abbaut. Die Lücke zwischen Demo und Produktion ist kein besseres Modell — sondern die Architektur drumherum.
Und die praktische Reihenfolge, wenn man bei null anfängt, ist die umgekehrte des Enthusiasmus: zuerst ein Gateway mit einem einzigen MCP-Server dahinter und Logging auf jedem Aufruf. Dann ein Eval-Set für den ersten Agenten — selbst 30 Szenarien schlagen null. Der Katalog kommt als Drittes, wenn es etwas hineinzustellen gibt. Geteiltes RAG, wenn das zweite Team dieselben Dokumente braucht wie das erste.
Ein Agent, der in der Demo funktioniert, ist ein Wochenende. Eine Fabrik, über die zehn Teams Agenten ausliefern, ohne sich gegenseitig anzuzünden, ist eine Architektur. Wenn bei Ihnen das Erste existiert und das Zweite fehlt: [Sprechen wir](/contact).