Es fängt als Erfolg an. Sie bauen einen KI-Agenten für ein klares Problem, er funktioniert, die Leute vertrauen ihm. Also wünschen sie sich mehr. Eine Fähigkeit, dann noch eine.
Jeder Wunsch ist vernünftig, jede Erweiterung klein. Sie schrauben das neue Verhalten an den Agenten, der schon da ist.
Ein paar Monate später hat der Systemprompt vierhundert Zeilen. Es gibt ein Dutzend Werkzeuge, drei davon kapseln still eigene Subagenten. Und das Ding, das verlässlich war, tut jetzt seltsame Dinge.
Es nimmt einen verschlungenen Weg zu einer Antwort, die es früher direkt fand. Es widerspricht sich. Gelegentlich verrechnet es eine Zahl, die es einmal richtig hatte.
Wenn das Ihr Agent ist, sind Sie in guter Gesellschaft. Es passiert Teams, die sonst alles richtig gemacht haben.
Der Agent wurde nicht schlechter, weil das Modell schlechter wurde. Er wurde schlechter, weil immer neue Fähigkeit dazukam, ohne dass der Bauplan mitwuchs, der sie tragen sollte.
Ein überkomplexer KI-Agent ist ein Kontextproblem, kein Modellproblem. Ein klügeres Modell repariert ihn selten.
In unserer eigenen Arbeit sehen wir denselben Bogen immer wieder. Nehmen wir als Beispiel einen Agenten, der den Einkauf eines Großhändlers unterstützt: knappe Bestände melden, Bedarf schätzen, Lieferanten vorschlagen, Bestellungen vorbereiten, den Wochenbericht schreiben.
Anfangs ein sauberer Helfer. Nach einem halben Jahr ein Geflecht, das niemand mehr durchblickt. An ihm lässt sich gut zeigen, wie man so etwas wieder geradezieht.
Warum ein KI-Agent zu komplex wird
Wenn ein überwachsener Agent versagt, sehen die Fehler verschieden aus. Bei unserem Einkaufs-Agenten erzählen drei davon die ganze Geschichte.
Der verschlungene Weg. Gefragt nach der täglichen Bestandsprüfung kommt er zur richtigen Antwort, aber auf einem umständlichen, mäandernden Umweg. Korrekt, doch langsam und teuer.
Die kaputte Übergabe. Eine Teilaufgabe geht an einen Subagenten. Der erledigt sie richtig, aber das Ergebnis kommt auf dem Rückweg zum Koordinator verstümmelt an. Die Arbeit war gut, die Kommunikation scheiterte.
Der Widerspruch. Bei einer Bedarfsschätzung während einer Aktion zieht er die richtige Basis und den richtigen Faktor von 3,1, und rechnet dann, irgendwo zwischen zwei Regeln im vierhundert Zeilen langen Prompt, die sich leise widersprechen, mit 1,35 weiter. Eine erfundene Zahl, geboren aus verwirrtem Kontext.
Sehen Sie, was alle drei verbindet. Keiner ist ein Denkfehler des Modells. Jeder ist ein Fehler der Information rund um das Modell.
Ein Weg, für den es kein passendes Werkzeug bekam. Eine Übergabe ohne sauberen Vertrag. Ein Prompt, so voll, dass das Modell nicht erkennt, welche Regel gilt.
Die Arbeit ist deshalb nicht prompte härter. Die Arbeit ist, für jede Fähigkeit zu entscheiden, wohin sie gehört. Dafür braucht es ein Bild davon, welche Plätze es überhaupt gibt.
Die drei Bausteine: Werkzeuge, Routinen, Subagenten
Alles, was ein Agent kann, setzt sich aus drei Bausteinen zusammen. Die meisten überwachsenen Agenten sind überwachsen, weil alles in einen davon gepresst wurde, meist in den Systemprompt und einen Stapel Werkzeuge.
Werkzeuge sind Dinge, die der Agent tun kann. Handlungen in der Welt: eine Datei lesen, Code ausführen, eine Schnittstelle aufrufen, ein System abfragen. Die Hände des Agenten.
Skills sind Dinge, die der Agent bei Bedarf wissen kann. Verpackte, dokumentierte Routinen, eine Richtlinie, ein Verfahren, eine Schätzmethode, die der Agent nur dann in den Kontext zieht, wenn eine Aufgabe sie braucht. Wissen, das er nicht ständig mit sich tragen muss.
Subagenten sind eigene Köpfe. Ein frischer, getrennter Kontext mit eigener Schleife, gut, um Arbeit zu parallelisieren oder eine unabhängige Sicht hereinzuholen.
Es gibt eine Reihenfolge, in der man danach greift, und sie beginnt tiefer, als die meisten Teams erwarten.
Wenn Sie sich an die Arbeit setzen, haben Sie schon einen mächtigen, allgemeinen Werkzeugkasten. Ein Dateisystem, die Fähigkeit, Code zu schreiben und auszuführen, eine Suche, einen Notizzettel für die To-do-Liste. Sie bekommen nicht für jede Aufgabe ein Spezialwerkzeug, Sie nutzen diese allgemeinen gut.
Produktive Agenten arbeiten am besten genauso. Fangen Sie mit denselben menschennahen Grundwerkzeugen an, lesen und schreiben, Code ausführen, suchen, eine Liste führen, und lehnen Sie sich darauf, bevor Sie etwas Eigenes bauen.
Der Grund ist greifbar. Nehmen wir an, der Agent soll einen Stapel Tabellen auswerten. Der Reflex ist, die Daten in den Prompt zu laden, damit das Modell sie lesen kann. Das kann zweihunderttausend Token und mehr verbrennen und das Modell in rohen Zeilen ersticken.
Geben Sie ihm stattdessen ein Werkzeug zum Ausführen von Code. Er schreibt ein paar Zeilen, lässt sie laufen und denkt über das Ergebnis nach. Ein Bruchteil der Token, schneller, meist korrekter. Der Agent brauchte kein eigenes Werkzeug zur Bestandsanalyse. Er brauchte einen Computer.
Die meisten Teams greifen zuerst ganz oben zu und landen bei einem Wust überlappender Spezialwerkzeuge. Fangen Sie unten an und steigen Sie nur auf, wenn es sein muss.
Eigene Werkzeuge haben ihren Platz, Sie ergänzen sie, wo ein Grundwerkzeug wirklich nicht hinreicht. Und ein gemeinsamer Werkzeugstandard für mehrere Agenten hat ihn auch. Aber das Fehlermuster ist, oben anzufangen, bevor die Grundwerkzeuge versucht wurden.
Die eine Entscheidung, die einen Agenten wartbar hält
Unser Einkaufs-Agent kam in die Krise, weil jede neue Anforderung an dieselben zwei Stellen ging. Ein paar Zeilen mehr im Systemprompt und noch ein Werkzeug, oft ein Subagent, als Werkzeug verkleidet.
Niemand stellte die Frage, die Wildwuchs verhindert.
Gehört diese Fähigkeit in ein Werkzeug, eine Routine oder einen Subagenten, oder sollte der Hauptagent sie einfach selbst erledigen?
Einmal beiläufig gestellt klingt sie banal. Bei jeder Erweiterung gestellt ist sie die eine Disziplin, die einen Agenten, der skaliert, von einem trennt, der verrottet. So beantworten Sie sie.
- Ist es Information, die der Agent nur manchmal braucht, eine Richtlinie, ein Verfahren, eine Methode? Dann eine Routine, die erst bei Bedarf geladen wird.
- Ist es eine Handlung oder der Zugriff auf ein System, den ein Grundwerkzeug nicht schon kann? Dann ein Werkzeug, und ein eigenes nur, wenn Ausführen, Lesen, Schreiben und Suche es nicht abdecken.
- Braucht es parallele Arbeit oder einen wirklich frischen, unabhängigen Kontext? Dann ein Subagent.
- Nichts davon? Dann erledigt der Hauptagent es bereits. Fügen Sie nichts hinzu.
- Brauchen mehrere Agenten denselben kontrollierten Werkzeugsatz? Erst dann ein gemeinsamer Standard.
Die Grundeinstellung ist weniger. Nichts hinzuzufügen ist eine gültige und oft die beste Antwort.
Routinen statt einem längeren Prompt
Ein Systemprompt sollte nur tragen, was der Agent unabhängig von der Aufgabe im Kopf behalten muss. Wer er ist, wie er sich verhält, was nicht verhandelbar ist.
Alles, was nur manchmal gebraucht wird, die Aktionspreis-Regel, die Lieferantenauswahl, die Schätzmethode, gehört nicht dorthin. In den Prompt gestopft richtet es zweierlei Schaden an.
Es belastet jede Anfrage mit Information, die die meisten Aufgaben nicht brauchen. Und während es sich stapelt, beginnen Regeln einander zu widersprechen. Genau das hat bei unserem Agenten die erfundene Zahl erzeugt.
Die Lösung sind dokumentierte Routinen, die der Agent erst dann in den Kontext zieht, wenn eine Aufgabe sie wirklich verlangt. Fragen Sie nach einer Schätzung, lädt die Schätzmethode. Fragen Sie nach etwas anderem, lädt sie nicht.
Beim Einkaufs-Agenten schrumpfte der Prompt von rund vierhundert auf etwa fünfzehn Zeilen, die Geschäftslogik wanderte in Routinen. Und die Klasse der Widerspruchsfehler verschwand mit.
Subagenten: mächtig und meist zu oft genutzt
Ein Subagent fühlt sich wie der naheliegende Weg an, Fähigkeit zu ergänzen. Gib dem neuen Job seinen eigenen Agenten und häng ihn ein.
Aber jeder Subagent fügt eine Kontextgrenze hinzu, die Sie nun verwalten müssen, und die Übergabe über diese Grenze ist eine klassische Bruchstelle. Genau die kaputte Übergabe von oben war das.
Behandeln Sie einen Subagenten darum als bewusste Wahl mit zwei guten Gründen und wenigen sonst.
- Viele Köpfe auf ein Problem werfen, wo Breite hilft: tiefe Recherche, ein großes System absuchen, viele Optionen gleichzeitig durchspielen.
- Eine frische, unabhängige Sicht, also Trennung der Zuständigkeiten. Wer prüft, sollte nicht der sein, der geschrieben hat. Unser Agent behält genau einen Subagenten, die Bedarfsschätzung, aus diesem Grund: Die Schätzung soll aus einem sauberen Kontext kommen, nicht aus demselben Gespräch, das gerade mit dem Nutzer geplaudert hat, damit nichts aus dem Verlauf die Zahlen verzerrt.
Außerhalb dieser zwei Fälle sind heutige Modelle fähig genug, die Arbeit in den Hauptagenten aufzunehmen. Weniger Grenzen, weniger Übergaben, weniger zum Zerbrechen.
Und wenn Sie einen Subagenten behalten, geben Sie ihm einen echten Vertrag und gute Beobachtbarkeit, damit seine Schritte so nachvollziehbar sind wie die des Koordinators, statt dass Sie hinterher Protokolle von Hand zusammenstückeln.
Messen, ändern, nachmessen
Einen Agenten nach Gefühl zu renovieren tauscht ein Problem gegen das nächste. Der Weg, mit Sicherheit umzubauen, ist, zuerst zu messen. Eine kleine Suite aus Prüfaufgaben, die den Agenten an dem bewertet, was Ihnen wirklich wichtig ist.
Zwei Arten arbeiten zusammen. Zählbares, harte Fakten über einen Lauf: Schritte, Dauer, verbrauchte Token. Billig, objektiv, gut, um Rückschritte bei der Effizienz zu fangen.
Und Bewertbares, ein Modell, das benotet, was sich nicht zählen lässt: Ton, Klarheit, Qualität der Ausgabe. Für die Teile der Arbeit, die ein Urteil brauchen.
Damit wird Verbesserung zu einer Schleife. Eine Basis festlegen, eine Sache am Bauplan ändern, neu messen, behalten was steigt, verwerfen was nicht steigt.
Bei unserem Einkaufs-Agenten lag die gemessene Basis bei 62 Prozent. Jeder Umbau, Routinen für den Prompt, Grundwerkzeuge für die Werkzeuge, ein Subagent bewusst behalten, blieb nur, weil die Zahl stieg. Am Ende standen rund 92 Prozent.
Eine Regel hält das ehrlich: Die Prüfungen müssen mit dem Produkt wachsen. Kommt eine Fähigkeit dazu, kommt die Prüfung dazu, die sie schützt. Sonst misst die Suite langsam nicht mehr, was der Agent tut, und Sie steigen den falschen Berg hinauf.
Warum jeder Fehler verschwand
Zurück zu den drei Fehlern vom Anfang. Jeder bildet eine Entscheidung ab.
Der verschlungene Weg war Effizienz. Der Agent dachte über Daten nach, für die er kein gutes Werkzeug hatte. Code ausführen ließ ihn direkt rechnen, statt sich durch den Kontext zu mahlen. Behoben durch Grundwerkzeuge statt Spezialwerkzeug.
Die kaputte Übergabe war Subagenten-Kommunikation. Ein Subagent, als Werkzeug verkleidet, mit lückigem Vertrag. Ihn in den Hauptagenten aufzunehmen entfernte die Grenze ganz. Behoben durch weniger Subagenten, mit Absicht.
Der Widerspruch war die erfundene Zahl. Zwei Regeln, die sich im vierhundert Zeilen langen Prompt bekämpften. In getrennte Routinen verschoben lädt nur noch die passende. Behoben durch Laden bei Bedarf.
Das Muster: Jeder Fix legte ein Stück Information oder Fähigkeit in den richtigen Baustein. Kein einziger verlangte ein klügeres Modell. Kontextproblem, Kontextlösung.
Wo das in Ihren Betrieb gehört
Sie haben jetzt die Entscheidung, die die meisten Teams nie ausdrücklich treffen. Pro Fähigkeit: Werkzeug, Routine, Subagent oder nichts, gestützt auf Prüfungen, mit denen sich jede Änderung belegen lässt.
Der Rahmen ist an einem Nachmittag lernbar. Die Disziplin zu halten, die Frage bei jeder Anforderung zu stellen, den Prompt schlank zu lassen, die Prüfungen aktuell zu halten, während das Geschäft weiter mehr wünscht, ist eine Übung, und Übungen brauchen ein Team, das sie teilt.
Die meisten Betriebe lassen ihre Agenten nicht aus Unwissen verrotten. Sie verrotten, weil es keine geteilte Gewohnheit gibt, Fähigkeit auf die richtige Art zu ergänzen, und der, der es wusste, ist weitergezogen.
Wir halten dazu eine klare Grenze. Was wir hosten, pflegen wir. Was Sie hosten, pflegen Sie. Wir hängen keine Subagenten und keine gemeinsamen Werkzeugstandards an, nur weil es sie gibt, und wir raten dazu, Fähigkeit zu entfernen, wo sie sich nicht auszahlt.
Bevor Sie überhaupt umbauen, steht eine frühere Frage. Braucht dieser Schritt das Urteil eines Modells? Eine Regel kostet nichts, irrt nie und läuft in zehn Jahren noch. Erst danach kommt Code, dann Automatisierung, dann ein Mensch, dann ein Agent.
Wenn Sie unsicher sind, ob Ihr Agent zu komplex geworden ist oder wo seine Last unnötig sitzt, schafft ein kostenloses Erstgespräch Klarheit. Wir sehen uns den Aufbau an und sagen ehrlich, was in eine Routine gehört, was ein Grundwerkzeug erledigt und wo ein Subagent eher schadet.
Wer das Fundament zuerst legen will, wo KI in Ihrem Betrieb hingehört und wo ein einfacherer Weg sich mehr lohnt, beginnt mit der AI Readiness, einem Befund mit benannten Eigentümern und nächsten Schritten. Wer das Handwerk im eigenen Haus aufbauen will, lernt es in der AI Academy an der eigenen Arbeit. Wer einen wartbaren Agenten lieber betreiben lässt, findet bei den Managed KI-Mitarbeitern Abläufe, die wir bereits führen und schlank halten.
Ein Agent muss nicht komplex werden, um mehr zu können. Er wird es nur, wenn niemand die Frage stellt, wohin die nächste Fähigkeit gehört. Stellen Sie sie jedes Mal.
Häufige Fragen
- Warum wird ein KI-Agent mit der Zeit unzuverlässig?
- Fast nie, weil das Modell schlechter wird. Sondern weil immer neue Fähigkeit dazukommt, ohne dass der Bauplan mitwächst. Logik staut sich im Systemprompt, Werkzeuge überlappen sich, Regeln widersprechen einander. Das ist ein Kontextproblem, kein Modellproblem, und ein klügeres Modell repariert es selten.
- Tools, Skills oder Subagenten, woran entscheide ich das?
- An einer Frage pro Fähigkeit. Information, die nur manchmal gebraucht wird, gehört in eine dokumentierte Routine. Eine Handlung oder ein Systemzugriff, den ein Grundwerkzeug nicht kann, in ein Werkzeug. Paralleler oder wirklich getrennter Kontext in einen Subagenten. Trifft nichts davon zu, erledigt der Hauptagent es bereits, und Sie fügen nichts hinzu.
- Wann lohnt sich ein Subagent wirklich?
- Aus zwei Gründen und wenigen sonst. Wenn breite, parallele Arbeit hilft, etwa tiefe Recherche oder das Absuchen eines großen Systems. Oder wenn eine frische, unabhängige Sicht zählt, also wer prüft, nicht der sein soll, der geschrieben hat. Sonst nimmt ein heutiges Modell die Arbeit besser in den Hauptagenten auf, denn jeder Subagent ist eine Übergabe, die brechen kann.
- Wie weiß ich, ob ein Umbau den Agenten wirklich besser gemacht hat?
- Indem Sie messen, nicht raten. Legen Sie eine kleine Prüfsuite an, zählbare Fakten wie Schritte und Token plus ein Modell, das Qualität benotet. Dann eine Basis festlegen, eine Sache ändern, neu messen, behalten was steigt. Und jede neue Fähigkeit kommt mit der Prüfung, die sie schützt, sonst misst die Suite bald das Falsche.