Agentic AI im Einsatz ->

Agentic AI in der Praxis: Was beim Bau produktiver KI-Agenten wirklich zählt

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

Dr. Andreas Ejupi

Dr. Andreas Ejupi

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.


Was einen Agenten ausmacht

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.


Lektion 1: Werkzeug-Design ist das eigentliche Handwerk

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:

EingriffWerkzeugEffekt
Eine Frage umformulierenpunktuelles Edit-Werkzeugminimale Fehlerfläche
Titel oder Begrüßung änderneigenes Meta-WerkzeugStruktur bleibt unangetastet
Fragen hinzufügen/entfernenVoll-Updatenur 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.


Lektion 2: Ein Agent sollte sich nicht selbst benoten

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.


Lektion 3: Offene Protokolle statt Insellösungen

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:

NutzerWeb-OberflächeAgentLLMHarnessWerkzeugeTools & Datenexterne SystemeWeitere AgentenAG-UIMCPA2A
EbeneProtokoll / BeispielZweck
Agent ↔ Nutzer-InteraktionAG-UI (Agent–User Interaction Protocol)Offener, event-basierter Standard, der Agenten mit nutzerseitigen Anwendungen verbindet – für interaktive Erlebnisse in Echtzeit.
Agent ↔ Tools & DatenMCP (Model Context Protocol)Offener Standard (initiiert von Anthropic), über den Agenten sicher auf externe Systeme zugreifen – Tools, Workflows und Datenquellen.
Agent ↔ AgentA2A (Agent to Agent)Offener Standard (initiiert von Google), der definiert, wie Agenten in verteilten agentischen Systemen koordinieren und Arbeit teilen.

Quelle: ag-ui.com


Was der Produktivbetrieb lehrt

Fünf Lektionen, die in keinem Framework-Tutorial stehen:

  1. Agenten scheitern leise: Ein klassischer Dienst wirft bei einem Fehler eine Exception. Ein Agent liefert stattdessen eine plausible, aber falsche Antwort – oder verstummt einfach. Eine subtil fehlerhaft aufgebaute Konversationshistorie kann einen Agenten ohne jede Fehlermeldung lahmlegen. Ohne Beobachtbarkeit bis auf die Ebene der rohen Modell-Anfragen sind solche Fehler nicht auffindbar.
  2. Evals ersetzen Unit-Tests: Agenten sind nicht deterministisch – derselbe Prompt liefert morgen eine andere Antwort. Klassische Tests prüfen die Werkzeuge, aber nicht das Verhalten. Was hilft, sind Evaluations-Suiten aus realistischen Dialogen: Erledigt der Agent die Aufgabe? Wählt er das richtige Werkzeug? Jede Prompt-Änderung und jeder Modellwechsel läuft dagegen – sonst ist jede Änderung ein Blindflug.
  3. Die Schleife multipliziert alles: Ein Chatbot macht einen Modellaufruf pro Antwort, ein Agent macht fünf bis zwanzig. Jede Ineffizienz – zu große Werkzeug-Payloads, unnötige Lesezugriffe, aufgeblähte Prompts – multipliziert sich mit jedem Schleifendurchlauf in Kosten und Latenz. Tool-Zuschnitt ist deshalb nicht nur eine Qualitätsfrage, sondern eine Wirtschaftlichkeitsfrage.
  4. Sicherheit auf API-Ebene, nicht in der UI: Alles, was die Oberfläche verbirgt, ist per API trotzdem erreichbar – und ein Agent mit schreibenden Werkzeugen ist ein mächtiger API-Client. Schreibschutz, Bestätigungspflichten, Ratenlimits und Größenbeschränkungen gehören auf den Server.
  5. Das Modell ist die austauschbarste Komponente: Werkzeug-Zuschnitt, Prompts, Evals und Prüfkataloge überleben jeden Modellwechsel. Das einkodierte Domänenwissen – im Umfrage-Beispiel: kurze Fragebögen, neutrale Formulierungen, intelligente Nachfragen statt starrer “Sonstiges”-Optionen – ist der eigentliche Kern des Systems.

Wer 2026 mit Agentic AI gewinnen will, gewinnt nicht durch das größte Modell, sondern durch vertikales Fachwissen, sauberes Werkzeug-Design und offene Protokolle.


Weiterführende Artikel


Einen solchen Agenten live erleben

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.

Jetzt Demo testen