Warum weniger Tools einen besseren AI-Agenten ergeben

Geben Sie einem AI-Agenten zehn Tools, erhalten Sie in der Regel schlechtere Ergebnisse – keine zusätzliche Leistungsfähigkeit. Jedes weitere Tool ist ein weiterer Punkt, an dem das Modell falsch wählen, fehlerhafte Argumente übergeben oder still das Falsche tun kann – und dabei trotzdem eine selbstsicher klingende Antwort liefert. Agenten, die in der Praxis tatsächlich funktionieren, arbeiten in der Regel mit zwei bis fünf Tools – jedes auf eine Aufgabe ausgerichtet.

Das ist keine theoretische Präferenz. Es zeigt sich immer wieder in der Beschreibung gut entwickelter Agenten: ein Skript, das GitHub-Issues und Dependency-Manifeste liest und echte Sicherheitshinweise findet, ohne den Code anzufassen – oder ein Scanner, der Subdomains allein auf Basis von DNS-Lookups als wahrscheinlich wildcard-basiert klassifiziert. Der gemeinsame Nenner ist kein cleveres Prompting. Es ist, dass jeder Agent einen kleinen, festen Werkzeugkasten hat und nie raten muss, welche von fünfzehn Optionen er verwenden soll.

Die Tool-Anzahl-Falle

Beim Planen eines agentenbasierten Systems ist der Instinkt oft, großzügig zu sein: Geben Sie dem Agenten ein Such-Tool, ein Datenbank-Tool, ein Datei-Tool, ein E-Mail-Tool, ein Kalender-Tool – „nur für den Fall", dass er sie braucht. Das fühlt sich sicher an. Ist es aber nicht – und die beiden Beispiele oben zeigen, warum jeder Fehlermodus konkret ist, nicht hypothetisch:

• Die Auswahlgenauigkeit sinkt. Der Dependency-Manifest-Scanner funktioniert, weil er nur zwischen „Manifest lesen" und „Issue lesen" wählt. Fügen Sie eine dritte Option hinzu – etwa ein allgemeines Web-Such-Tool –, muss das Modell bei jedem Durchlauf entscheiden, ob der benötigte Sicherheitshinweis im Repo liegt oder im Web, und es wird oft genug falsch raten, um relevant zu sein.
• Argumentfehler summieren sich. Der DNS-basierte Subdomain-Klassifikator nimmt eine einzige Eingabe: einen Hostnamen. Das ist das gesamte Schema. Sobald Sie ein zweites Tool mit eigenen Parametern hinzufügen, haben Sie die Angriffsfläche für fehlerhafte Aufrufe verdoppelt – und bei einer Schreibaktion ist der Preis eines solchen Fehlers nicht mehr „falsche DNS-Antwort", sondern „falscher Datensatz übermittelt".
• Fehler werden lautlos. Beide Tools sind read-only, also produziert eine falsche Auswahl lediglich eine fehlerhafte Klassifikation, die im Output sichtbar ist. Ein Agent, der zusätzlich ein Schreib-Tool besitzt, kann es missbrauchen, Erfolg protokollieren und weitermachen – und niemand bemerkt es, bis ein Kunde sich beschwert.
• Die Kosten steigen schleichend. Jede Tool-Definition wird bei jedem Aufruf im Context Window mitgeführt – unabhängig davon, ob der Manifest-Scanner sein zweites oder drittes Tool je verwendet. Eine aufgeblähte Tool-Liste ist ein aufgeblähter Prompt bei jedem einzelnen Turn.

Anthropics eigene Empfehlungen zum Agenten-Design betonen dasselbe aus Entwicklerperspektive: Die zuverlässigsten agentenbasierten Systeme bestehen aus einfachen, gut getesteten Komponenten – nicht aus einem einzigen Agenten, der jede Fähigkeit gleichzeitig jongliert (siehe Anthropics technischer Beitrag zum Entwickeln effektiver Agenten). Einfachheit ist kein Ausgangspunkt, den man hinter sich lässt. Sie ist das, was in großem Maßstab funktioniert.

Wie enge Abgrenzung in der Praxis aussieht

Wir betreiben unsere eigene Outbound-Engine auf diese Weise. Sie scrapt die Website eines Interessenten, extrahiert die relevanten Fakten und entwirft eine maßgeschneiderte E-Mail – alles in einem einzigen fokussierten Aufruf, statt in einer mehrstufigen Kette aus Such-Tool, CRM-Tool und Entwurfs-Tool. Weniger bewegliche Teile bedeuteten weniger Stellen, an denen der Prozess still schieflaufen konnte – und geringere Kosten pro Lead. Die Erkenntnis lässt sich über Outreach hinaus verallgemeinern: Je weniger Tools ein Agent benötigt, desto einfacher ist es nachzuvollziehen, was er getan hat und warum. Das ist eine andere Frage als die, ob man für eine gegebene Aufgabe einen einzelnen LLM-Aufruf oder eine Agentenkette verwenden sollte – aber derselbe Instinkt gilt auf der Tool-Ebene: Geben Sie dem Modell keine Optionen, die es nicht braucht.

So überprüfen Sie die Tool-Liste Ihres Agenten

Wenn Sie eine Entwicklung evaluieren – intern oder von einer Agentur –, fragen Sie zuerst nach der Tool-Liste, bevor Sie nach dem Modell oder dem Prompt fragen. Einige Prüfpunkte:

• Können Sie die eine Aufgabe dieses Agenten in einem Satz benennen? Unsere Outbound-Engine besteht diesen Test in einem Satz: Sie verwandelt die Website eines Interessenten in einen fertigen E-Mail-Entwurf. Wenn die Antwort für den Agenten eines anderen einen ganzen Absatz braucht, sind es wahrscheinlich zwei Agenten in einem Mantel.
• Wird jedes Tool bei einem normalen Durchlauf verwendet – oder sind einige nur „für den Fall"? Der Scrape-Extrakt-Entwurf-Aufruf hat kein ungenutztes Tool im Schema. Ungenutzte Tools sind reiner Nachteil: Kosten und Verwirrung ohne Nutzen.
• Lassen sich zwei Tools allein anhand ihrer Namen und Beschreibungen leicht verwechseln? Wenn ein Mensch beim Überfliegen des Schemas zögern würde, wird es das Modell auch tun.
• Was passiert, wenn der Agent das falsche Tool wählt? Wenn kein Logging vorhanden ist, das einen falschen Aufruf sichtbar macht, erfahren Sie es erst dann, wenn der Kunde es merkt.
• Könnte dies zwei spezialisierte Agenten mit einem Router sein, statt eines breiten Agenten? Routing-Logik ist langweilig und testbar. Ein einzelnes Modell, das zwölf Tools jongliert, ist weder das eine noch das andere.

Wann mehr Tools wirklich sinnvoll sind

Das bedeutet nicht, dass jeder Agent ein Einzel-Tool-Skript sein sollte. Manche Aufgaben erstrecken sich tatsächlich über mehrere Systeme – ein Support-Agent, der eine Bestellung nachschlagen, einen Versanddienstleister prüfen und eine Rückerstattung ausstellen muss, tut legitim drei Dinge. Die Lösung ist in solchen Fällen meist nicht, einem Agenten weniger Tools zu geben, sondern die Aufgabe auf einen Workflow mit kleineren Schritten aufzuteilen – mit expliziten Übergaben, statt dass ein einzelnes Modell bei jedem Turn unter einem Dutzend Optionen entscheidet. Ein deterministischer Workflow, der drei spezialisierte Agenten der Reihe nach aufruft, ist weit einfacher zu debuggen als ein Agent mit neun Tools, der selbst die richtige Reihenfolge herausfinden muss.

Was Sie einen Anbieter dazu fragen sollten

Wenn Sie Agenturen oder interne Vorschläge für einen agentenbasierten Aufbau vergleichen, ist der Tool-Umfang eine günstige Frage mit hohem Aussagewert, die Sie Ihrer Anbieter-Evaluierungs-Checkliste hinzufügen sollten. Bitten Sie darum, die Tool-Liste des vorgeschlagenen Agenten durchzugehen und jedes Tool zu begründen. Ein Team, das sich damit auseinandergesetzt hat, wird für jedes Tool eine klare Antwort haben. Ein Team, das es nicht hat, wird beginnen, Tools anhand von Szenarien zu erklären – was meist das Geräusch von Scope Creep in Echtzeit ist.

Die Anzahl der Tools ist eine der wenigen Agenten-Design-Entscheidungen, die Sie ohne eine Zeile Code auf Plausibilität prüfen können – und sie korreliert stark damit, wie sich das gesamte System verhält, sobald es live ist und niemand mehr zuschaut.

Wenn Sie einen agentenbasierten Aufbau planen und vor der Entscheidung eine zweite Meinung zur Tool-Liste möchten, sprechen Sie mit uns.