KI-Agenten produktiv einsetzen: Praxiserkenntnisse zu Tool-Design, Multi-Agenten-Mustern und offenen Protokollen wie MCP und AG-UI.

AI Research
Agentic AI ist das Thema des Jahres 2026. Doch zwischen einer beeindruckenden Demo und einem KI-Agenten, der zuverlässig im Produktivbetrieb läuft, liegt viel Ingenieursarbeit. Die Demo entsteht in einer Woche – die Zuverlässigkeit danach ist die eigentliche Aufgabe.
Dieser Beitrag fasst zusammen, welche Muster sich beim Bau produktiver Agenten in der Praxis bewährt haben – und welche Ansätze sich als Sackgasse herausstellen. Als durchgehendes Beispiel dient ein konversationeller Agent, der im Dialog Umfragen erstellt, überarbeitet und veröffentlicht.
Ein Chatbot beantwortet Fragen. Ein Agent handelt: Er wählt eigenständig Werkzeuge aus, führt mehrstufige Aufgaben aus und reagiert auf Zwischenergebnisse. Die Formel ist einfach:
Agent = LLM + Harness + Werkzeuge
Der Harness ist dabei alles, was das Sprachmodell umgibt und steuert: der Systemprompt, die Ablaufschleife, die Zustandsverwaltung und die Leitplanken. Der Nutzer sagt: “Erstelle mir eine Kundenzufriedenheitsumfrage mit drei Fragen” – und der Agent plant, erstellt, zeigt eine Vorschau und fragt bei kritischen Schritten nach. Die Qualität eines Agenten entsteht dabei fast vollständig außerhalb des Modells: im Harness und im Zuschnitt der Werkzeuge. Genau dort passieren die interessanten Entscheidungen.
Der naheliegende Entwurf ist ein einziges, mächtiges Werkzeug, das bei jeder Änderung das komplette Objekt entgegennimmt. Das skaliert schlecht: Für jede Kleinigkeit muss das Modell die gesamte Struktur reproduzieren – das kostet Zeit, Tokens und erzeugt Fehler an Stellen, die gar nicht angefasst werden sollten.
Bewährt hat sich stattdessen eine Hierarchie nach Eingriffstiefe:
| Eingriff | Werkzeug | Effekt |
|---|---|---|
| Eine Frage umformulieren | punktuelles Edit-Werkzeug | minimale Fehlerfläche |
| Titel oder Begrüßung ändern | eigenes Meta-Werkzeug | Struktur bleibt unangetastet |
| Fragen hinzufügen/entfernen | Voll-Update | nur wenn wirklich strukturell nötig |
Der Agent wird angewiesen, immer das kleinstmögliche Werkzeug zu wählen. Das Modell kann nichts kaputt machen, worauf das Werkzeug keinen Zugriff hat.
Die zweite Erkenntnis: Sicherheitsregeln gehören in den Werkzeug-Code, nicht in den Prompt. Will der Agent etwa eine veröffentlichte Umfrage mit echten Antworten verändern, sollte das Werkzeug selbst die Ausführung verweigern und eine explizite Bestätigung des Nutzers verlangen. Der Prompt kann solche Regeln ergänzen – aber nur Code macht sie deterministisch.
Kann ein Agent seine eigene Arbeit objektiv prüfen? Nein – die eigene Konversationshistorie wirkt als Bias, er nickt seine Ergebnisse ab. Hier kommt ein klassisches Multi-Agenten-Muster zum Einsatz: Die Qualitätsprüfung ist selbst ein Werkzeug, das intern einen zweiten, frischen Agenten startet – mit eigenem Prüfkatalog und bewusst ohne Zugriff auf den bisherigen Gesprächsverlauf:
@tool
def review(document_id):
reviewer = Agent(
system_prompt=REVIEW_RUBRIC, # eigener Prüfkatalog
# bewusst: keine Historie des Builder-Agenten
)
return reviewer.structured_output(Review, load(document_id))
Der Gutachter sieht nur das Ergebnis, nicht den Entstehungsprozess – und liefert kein Fließtext-Urteil, sondern strukturierte Findings mit Schweregrad (kritisch, Warnung, Vorschlag) und einer klaren Freigabe-Empfehlung. Damit lässt sich das Review auch programmatisch nutzen, etwa als Veröffentlichungs-Schranke.
Auffällig in der Praxis: Komplexere Architekturen – Orchestratoren mit Sub-Agenten, Schwärme, Router – funktionieren zwar, sind aber oft schwerer zu debuggen, als sie Nutzen bringen. Wenige spezialisierte Agenten mit klarer Arbeitsteilung schlagen kompliziertere Topologien regelmäßig in Zuverlässigkeit und Wartbarkeit. Die minimale Topologie, die das Problem löst, gewinnt.
Ein Agent, der nur in einer einzigen Oberfläche lebt, ist eine Sackgasse. Eine tragfähige Architektur trennt deshalb konsequent Agenten-Logik und Oberfläche – der Agent selbst weiß nichts vom Frontend und wird über offene Protokolle angebunden:
| Ebene | Protokoll / Beispiel | Zweck |
|---|---|---|
| Agent ↔ Nutzer-Interaktion | AG-UI (Agent–User Interaction Protocol) | Offener, event-basierter Standard, der Agenten mit nutzerseitigen Anwendungen verbindet – für interaktive Erlebnisse in Echtzeit. |
| Agent ↔ Tools & Daten | MCP (Model Context Protocol) | Offener Standard (initiiert von Anthropic), über den Agenten sicher auf externe Systeme zugreifen – Tools, Workflows und Datenquellen. |
| Agent ↔ Agent | A2A (Agent to Agent) | Offener Standard (initiiert von Google), der definiert, wie Agenten in verteilten agentischen Systemen koordinieren und Arbeit teilen. |
Quelle: ag-ui.com
Fünf Lektionen, die in keinem Framework-Tutorial stehen:
Wer 2026 mit Agentic AI gewinnen will, gewinnt nicht durch das größte Modell, sondern durch vertikales Fachwissen, sauberes Werkzeug-Design und offene Protokolle.
Bei Feedbk.ai lässt sich ein Builder-Agent nach diesen Prinzipien direkt im Browser ausprobieren – eine KI-moderierte Umfrage entsteht im Dialog, ohne Formulare.