Wenn man „agentisches System“ hört, klingt das oft nach Magie: ein Modell, das einfach alles alleine kann. In der Praxis ist es genau andersrum: Gute Agentik ist strukturiertes Engineering. Der Unterschied zwischen einem netten Demo-Agenten und einem produktionsfähigen Agenten liegt weniger im Modell selbst und mehr in der Architektur drumherum.
Ein klassischer Chatbot beantwortet eine Eingabe direkt. Ein agentisches System darf zusätzlich entscheiden, welche Zwischenschritte nötig sind: planen, Tool aufrufen, prüfen, nachbessern, zusammenfassen. Genau dadurch wird es mächtiger – aber auch fehleranfälliger. Jede zusätzliche Freiheit erzeugt neue Failure-Modes: falscher Tool-Call, zu viele Schritte, Kontextverlust, Kostenexplosion.
Deshalb ist die erste Kernregel: Agentik ist kontrollierte Autonomie. Du gibst dem System nicht „maximale Freiheit“, sondern einen klaren Rahmen. Dieser Rahmen besteht aus: Zieldefinition, erlaubten Aktionen, Qualitätskriterien und Stop-Bedingungen. Ein gutes Setup sagt nicht nur „Löse Aufgabe X“, sondern auch „nutze nur diese Tools, liefere JSON-Schema Y, stoppe nach Z Versuchen, frage bei Unsicherheit nach“.
Zweite Kernregel: Nicht jede Aufgabe braucht Agentik. Viele Workflows sind linear und lassen sich mit einem gut formulierten Prompt + einem Tool-Call lösen. Agentisches Verhalten lohnt sich erst, wenn die Aufgabe echte Entscheidungspunkte enthält: z. B. unklare Datenlage, mehrere Informationsquellen, Validierungszyklen oder priorisierte Teilziele. Ein häufiger Anfängerfehler ist Over-Orchestration: Multi-Agent-System bauen, obwohl ein Single-Agent-Flow ausreichend wäre.
Dritte Kernregel: Explizite Zwischenergebnisse schlagen „Black Box“-Runs. In der Prüfung (und später im Betrieb) zählt, ob dein System nachvollziehbar ist. Plane daher in Phasen:
1. Problemverständnis und Plan
2. Datensammlung / Tooling
3. Validierung gegen Kriterien
4. Finale Antwort mit Unsicherheiten
Dieses Phasenmodell reduziert Halluzinationen, weil jeder Schritt überprüfbar wird. Es verbessert auch Debugging: Wenn etwas schiefgeht, weißt du, ob der Fehler in der Planung, im Tooling oder in der Validierung lag.
Wichtig ist außerdem das Spannungsfeld zwischen Leistung, Kosten und Zuverlässigkeit. Mehr autonome Schritte erhöhen oft die Trefferquote bei komplexen Aufgaben – aber auch Tokenverbrauch und Latenz. Für die Architekturentscheidung brauchst du daher immer ein Zielprofil: „billig und schnell“ vs. „maximal robust“ vs. „hohe Genauigkeit bei begrenzter Laufzeit“.
Fürs Exam solltest du dir merken: Gute Antworten argumentieren in Trade-offs, nicht in Absoluten. Also nicht „Multi-Agent ist besser“, sondern „Multi-Agent ist sinnvoll, wenn Isolation oder Spezialisierung nötig ist; sonst Single-Agent wegen geringerer Komplexität und Kosten.“
Wenn du das verinnerlichst, hast du bereits den wichtigsten Foundations-Move: Du denkst nicht in Features, sondern in Systemdesign unter Constraints.
Du sollst ein System bauen, das Support-Tickets klassifiziert und bei Bedarf Antworten vorschlägt. Wann würdest du kein Multi-Agent-Setup wählen – und warum?
Kein Multi-Agent-Setup, wenn Klassifizierung + Antwortvorschlag mit einem klaren, linearen Single-Agent-Flow zuverlässig lösbar sind. Das reduziert Komplexität, Latenz und Kosten sowie Fehlerflächen (Koordination, Context-Handover). Multi-Agent lohnt sich erst bei klarer Spezialisierung oder Isolation (z. B. getrennte Rechte/Tools pro Schritt).