Anti-Pattern Too Many Tools: zu viele Tools für Agenten

Idee in 30 Sekunden

Too Many Tools ist ein Anti-Pattern, bei dem ein Agent zu viele Tools ohne klare Aufgabengrenzen bekommt.

Dadurch entsteht Rauschen bei der Aktionswahl: Der Agent wählt häufiger ein irrelevantes Tool und verbraucht Schritte für erneute Auswahl. Das erhöht latency, cost und Instabilität der Antwort.

Einfache Regel: Für jedes Szenario sollte der Agent nur das minimale Set an Tools sehen, das wirklich nötig ist.

Beispiel für das Anti-Pattern

Das Team baut einen Support-Agenten für Anfragen zu Bestellungen, Rückgaben und Zahlungen.

Statt eines engen Sets gibt das Team dem Agenten eine große Tool-Liste "für alle Fälle".

response = agent.run(
    "User: Warum schlägt die Zahlung für Bestellung #8341 fehl?"
)

In diesem Setup hat der Agent Dutzende Optionen und kann in die falsche Richtung gehen:

tools = ["get_payment_status", "get_invoice", "get_order"]
selected_tool = agent.pick_tool(tools)
result = run_tool(selected_tool, order_id)

# der Agent kann zuerst get_invoice wählen,
# die Ursache nicht finden
# und erst danach zu get_payment_status wechseln

Für diesen Fall reicht ein kurzer Ablauf mit wenigen Tools:

payment_data = get_payment_status(order_id)
return format_payment_answer(payment_data)

In diesem Fall erzeugt ein Tool-Übermaß:

• Rauschen bei der Aktionswahl
• unnötige Tool-Aufrufe
• höheres Risiko für falsches Routing

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn ein Team sofort einen "universellen" Agenten für alle Anfragen bauen will.

Typische Ursachen:

• neue Tools werden ergänzt, alte aber nicht entfernt
• keine per-task Allowlist für Tools
• Sorge, dass "ein Tool nicht reicht"
• große Toolsets aus Demos werden übernommen, ohne Production-Cases zu validieren

Daraus folgen Probleme:

• instabile Auswahl - der Agent wählt ein Tool, das formal passt, aber nicht das beste ist
• höhere latency - Auswahlschleifen und wiederholte Calls kosten mehr Zeit
• höhere cost - unnötige Tool- oder LLM-Schritte für typische Anfragen
• aufgeblähter Kontext - im Prompt landen viele Tool-Beschreibungen und Zwischenresultate
• schwieriges Debugging - schwer nachzuvollziehen, warum genau dieser Pfad gewählt wurde

Typische Production-Signale, dass bereits zu viele Tools vorhanden sind:

• eine typische User-Anfrage löst 3-5 Tool-Calls aus, obwohl 1-2 reichen würden
• dieselbe Aufgabe läuft in verschiedenen Runs über unterschiedliche Pfade
• das Team kann nicht klar erklären, warum Tool A statt Tool B gewählt wird
• ein neues Tool verschlechtert die Quality bestehender Szenarien

Dadurch verbringt der Agent mehr Schritte mit Aktionswahl als mit der eigentlichen Lösung. Wichtig: Tool-Auswahl ist Teil der LLM inference. Das Modell wählt eine Aktion aus den Optionen, die es im Prompt sieht. Mit mehr Tools wächst die Zahl möglicher Pfade, und die Auswahl wird instabiler: Das Modell wählt häufiger ein Tool, das formal passt, aber nicht optimal ist.

Wenn dieses Setup wächst, ist ohne trace und Ausführungsvisualisierung kaum nachvollziehbar, warum der Agent genau diesen Tool-Pfad gewählt hat. Deshalb haben Production-Systeme meist eine dedizierte Observability-Schicht für Agent-Runs.

Richtiger Ansatz

Startet mit dem einfachsten Pfad, der heute die meisten Anfragen stabil löst. Fügt Tools nur hinzu, wenn es einen messbaren Ausfall, ein Risiko oder eine Grenze im aktuellen Design gibt.

Praktischer Rahmen:

• definiert pro Aufgabentyp eine klare Tool-Allowlist
• haltet ein kleines Tool-Set pro Route
• ergänzt ein neues Tool nur bei messbarem Grund (zum Beispiel bessere success rate oder weniger Fehler ohne starken Anstieg von latency und cost per request)

def answer_payment_question(order_id: str, user_message: str) -> str:
    route = classify_intent(user_message)  # einfacher Klassifikator oder Regeln

    if route == "payment_status":
        allowed_tools = ["get_payment_status"]
        data = run_tool("get_payment_status", order_id)
        return format_payment_answer(data)

    allowed_tools = ["get_payment_status", "get_invoice"]
    return agent.run(
        user_message=user_message,
        allowed_tools=allowed_tools,
    )

In diesem Setup arbeitet der Agent mit einem kleinen, relevanten Tool-Set, dadurch wird die Aktionswahl stabiler.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet werden, habt ihr ein Too-Many-Tools-Risiko:

• Braucht eine typische Anfrage regelmäßig 3+ Tool-Calls, obwohl 1-2 reichen sollten?
• Läuft dieselbe Anfrage in verschiedenen Runs über unterschiedliche Tool-Pfade?
• Werden neue Tools schneller ergänzt, als das Team sie begrenzen, entfernen oder reviewen kann?

Worin es sich von anderen Anti-Patterns unterscheidet

Tool Calling Everywhere vs Too Many Tools

Multi-Agent Overkill vs Too Many Tools

Giant System Prompt vs Too Many Tools

Selbstcheck: Habt ihr dieses Anti-Pattern?

Schnellcheck für das Anti-Pattern Too Many Tools.
Markiert die Punkte für euer System und prüft den Status unten.

Prüft euer System:

FAQ

Q: Bedeutet das, dass viele Tools immer schlecht sind?
A: Nein. Das Problem ist nicht die Menge an sich. Das Problem ist, dass der Agent in einem konkreten Szenario zu viele irrelevante Optionen sieht.

Q: Wann sollten wir ein neues Tool ergänzen?
A: Wenn es ein konkretes Signal gibt: Lücken in der Aufgabenabdeckung, Quality-Fehler oder Limits der aktuellen Route, die ohne unverhältnismäßigen Anstieg von latency, cost oder Debugging-Komplexität nicht lösbar sind.

Q: Wie reduzieren wir Tool-Auswahl-Chaos ohne großen Refactor?
A: Startet einfach: führt Allowlists pro Aufgabentyp ein, setzt Schritt-Limits und entfernt Tools, die selten genutzt werden oder nur doppelte Ergebnisse liefern.

Was als Nächstes

Ähnliche Anti-Patterns:

• Agent Everywhere Problem - wenn ein Agent sogar für deterministische Aufgaben ergänzt wird.
• Overengineering Agents - wenn das System ohne messbaren Nutzen zusätzliche Schichten aufbaut.
• Multi-Agent Overkill - wenn es zu viele Agenten mit unscharfer Rollenabgrenzung gibt.

Was ihr stattdessen bauen solltet:

• Allowed Actions - wie ihr klare Grenzen dafür setzt, was der Agent tun darf.
• Routing Agent - wie ihr Aufgaben routet und dem Agenten nur relevante Tools gebt.
• Tool Execution Layer - wo Tool-Calls und Zugriffsregeln in der Architektur kontrolliert werden.