Arten von Agentic AI und wie du deinen ersten Agenten baust

Agentische Systeme sind kein Monolith. Sie bestehen aus Bausteinen, und die Art, für die du dich entscheidest, bestimmt, was im Betrieb zuerst kaputtgeht.

Das ist der letzte Teil der Serie. In den ersten drei ging es darum, was Agenten sind, wie sie sich von generativer KI unterscheiden und wie sie im Inneren funktionieren. Dieser Teil ist praktisch: Welche Arten von Agenten gibt es, wofür taugt jede, wo scheitert sie typischerweise, und wie gehst du beim Bau deines ersten Agenten vor?

Fünf Arten von Agenten

Eine offizielle Einteilung gibt es nicht. Die meisten Agenten, denen du begegnest, fallen aber in eine von fünf Gruppen, je nachdem, wie viel Freiheit sie haben und wie viele von ihnen zusammenarbeiten.

1. Aufgabenagenten

Die einfachste Sorte. Ein Aufgabenagent erledigt genau eine klar umrissene Aufgabe: ein Dokument zusammenfassen, die wichtigen Felder aus einer E-Mail ziehen, einen Wochenbericht erstellen. Er hält kaum oder gar keinen Zustand und hat wenig Autonomie. Meist besteht er aus einer Prompt-Vorlage, ein paar Funktionsaufrufen und vielleicht einer Suche (RAG) über einen Dokumentenbestand. Aufgabenagenten passen gut zu engen, wiederholbaren Abläufen wie Compliance-Berichten. Sie scheitern, wenn die Eingaben aus dem Rahmen fallen, den der Prompt vorgesehen hat. Prüfe ihre Ausgaben also, statt ihnen blind zu vertrauen.

2. Schnittstellenagenten

Schnittstellenagenten haben mit Menschen zu tun: virtuelle Assistenten, Support-Chatbots, Verkaufsberater. Sie müssen sich an das Gespräch erinnern, neben Text oft auch Bilder oder Sprache verarbeiten und entscheiden, wann sie handeln und wann sie nachfragen. Ein typischer Aufbau besteht aus einem Sprachmodell, etwas Gedächtnis und einem Frontend, sei es React, Streamlit oder einfach Slack. Ihre Schwachstelle ist Mehrdeutigkeit. Menschen sagen selten genau, was sie meinen, und ein Schnittstellenagent, der auf eine falsche Vermutung hin handelt, ist schlechter als einer, der kurz nachfragt.

3. Reflexionsagenten

Ein Reflexionsagent prüft Arbeit, seine eigene oder die eines anderen Agenten. Code-Reviewer, Bewerter von Antworten und Sicherheitsprüfer gehören hierher. Das übliche Muster ist ein Generator und ein Kritiker, entweder als zwei verkettete Prompts oder als zwei getrennte Agenten, manchmal unterstützt durch ein Belohnungsmodell. Reflexion verbessert die Qualität spürbar, aber nur, wenn der Kritiker etwas weiß, das der Generator nicht wusste, etwa Testergebnisse oder ein Bewertungsschema. Ein Modell, das seine eigene Ausgabe ohne neue Informationen bewertet, winkt sie meistens durch.

4. Planungsagenten

Planungsagenten nehmen ein Ziel mit vielen Schritten und legen den Weg fest: ein Projekt koordinieren, Anfragen an den passenden Ablauf weiterleiten, eine Reise organisieren. Sie wählen ihren Weg zur Laufzeit und setzen meist auf ein Framework mit guter Werkzeugunterstützung wie LangGraph oder AutoGen. Ihre Schwäche liegt im langen Schwanz: Ein Plan, der bei Schritt eins vernünftig aussieht, kann bei Schritt sechs unmöglich sein. Planungsagenten brauchen deshalb Kontrollpunkte, an denen der Plan neu bewertet wird.

5. Multi-Agenten-Systeme

Hier arbeiten mehrere Agenten mit unterschiedlichen Rollen zusammen und stimmen sich über Nachrichten oder einen gemeinsamen Speicher ab. Denk an ein Rechercheteam, in dem ein Agent sucht, einer liest und einer schreibt, oder an eine Gruppe von Coding-Agenten, die ein Feature unter sich aufteilen. CrewAI und AutoGen sind die üblichen Einstiegspunkte. Das skaliert gut für große Aufgaben, doch dann wird die Koordination selbst zum schwierigen Teil. Ohne klare Rollen und eine Regel, wann Schluss ist, drehen sich Agenten im Kreis, machen doppelte Arbeit oder entfernen sich vom ursprünglichen Ziel.

Die Bausteine eines minimalen Agenten

Egal welche Art du baust, es tauchen immer dieselben Bausteine auf. Die Tabelle zeigt sie mit einigen verbreiteten Optionen. Das ist keine Empfehlungsliste, sondern eine Landkarte.

Ein erstes Projekt: ein Reiseassistent

Ein Reiseassistent ist ein guter erster Agent, weil er alle Bausteine braucht und trotzdem überschaubar bleibt. Angenommen, das Ziel lautet: „Plane eine Reise von Istanbul nach Berlin im nächsten Monat, innerhalb meines Budgets und passend zu meinem Kalender.“

Zerlegt muss der Agent Folgendes können:

• Planen: die Anfrage in Schritte aufteilen, etwa Visabestimmungen prüfen, Termine finden, Flüge und Hotels suchen und eine Route vorschlagen.
• Werkzeuge nutzen: eine Flugsuch-API, den Kalender und E-Mail für Bestätigungen.
• Sich erinnern: bevorzugte Airlines, Budgetgrenzen, welchen Reisepass der Nutzer hat.
• Reflektieren: prüfen, ob der Plan wirklich zu Budget und Kalender passt, bevor er gezeigt wird, und mit Problemen wie einem ausverkauften Tarif umgehen.

Anfrage → Plan → Schritte → Werkzeugaufrufe → Vorschlag
             ↑                       │
        Gedächtnis ← Ergebnis prüfen, anpassen

Fang damit an, dass der Agent nur einen Plan vorschlägt und ein Mensch bucht. Sobald die Vorschläge zuverlässig stimmen, darf er selbst buchen, mit einem Bestätigungsschritt vor jeder Zahlung. Diese Reihenfolge (erst vorschlagen, dann handeln) ist der sicherste Weg, Vertrauen in einen Agenten aufzubauen.

Gewohnheiten, die Agenten zuverlässig machen

• Mach ihn anhaltbar. Ein Mensch sollte den Agenten jederzeit pausieren oder übersteuern können.
• Halte das Gedächtnis sauber. Trenne Kurzzeit-, Langzeit- und semantisches Gedächtnis und räume sie auf, sonst lenken veraltete oder falsche Informationen spätere Entscheidungen.
• Halte die Teile klein. Getrennte Komponenten für Planung, Werkzeugnutzung und Validierung lassen sich viel leichter debuggen als ein Agent, der alles macht.
• Kontrolliere die Werkzeuge. Gib jedem Werkzeug ausdrückliche Berechtigungen und logge jeden Aufruf.
• Teste zuerst in einer Simulation. Lass den Agenten gegen nachgebildete Werkzeuge und aufgezeichnete Szenarien laufen, bevor er echten Systemen nahekommt.

Framework oder eigener Code?

Früher oder später musst du entscheiden, ob du bei einem High-Level-Framework wie LangChain oder AutoGen bleibst oder die Schicht für das Werkzeug-Routing selbst schreibst. Beides ist vernünftig, es kostet nur unterschiedliche Dinge.

Meine Faustregel: Nimm ein Framework, um zu experimentieren und schnell einen Prototyp vor echte Nutzer zu bringen. Wenn der Agent für das Geschäft wichtig wird, lohnt es sich, die entscheidenden Teile durch einen kleinen eigenen Router zu ersetzen, mit strenger Schema-Validierung, lesbaren Stacktraces und direkter Kontrolle über die Modell-API. Du verzichtest auf etwas Komfort und siehst dafür, was dein System tatsächlich tut.