Anti-Pattern Tool Calling for Everything: Tool-Aufrufe für alles

Idee in 30 Sekunden

Tool Calling for Everything ist ein Anti-Pattern, bei dem ein Agent fast jede Anfrage automatisch in einen Tool-Call umwandelt.

Dadurch laufen sogar einfache Szenarien durch unnötige Schritte, latency und cost steigen, und das System wird durch Abhängigkeit von externen Calls fragiler.

Einfache Regel: Ruft ein Tool nur dann auf, wenn die Aufgabe ohne externe Daten oder externe Aktion nicht zuverlässig lösbar ist.

Beispiel für das Anti-Pattern

Das Team baut einen Support-Agenten für Fragen zu Bestellungen, Rückgaben und Service-Policies.

Selbst für eine einfache Policy-Frage ruft der Agent zuerst Tools auf.

response = agent.run(
    "User: Wie lang ist die Rückgabefrist für ein Produkt?"
)

In diesem Setup läuft eine typische Antwort durch eine unnötige Tool-Kette:

tool_result = run_tool("get_return_policy")
answer = agent.summarize(tool_result)
return answer

Für diesen Fall reicht ein kurzer workflow ohne tool-call:

policy = RETURN_POLICY_BY_REGION[region]
return format_return_policy(policy)

In diesem Fall erzeugt übermäßiges tool-calling:

• unnötige externe Aufrufe
• höhere Kosten pro Anfrage
• zusätzliche Ausfallpunkte

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn ein Team eine "tool-first" Architektur baut und keinen einfachen Pfad ohne Tools lässt.

Typische Ursachen:

• kein expliziter no_tool Pfad für deterministische Fälle
• ein Ausführungs-Template wird auf alle Anfrage-Typen angewendet
• Sorge, ohne externe Prüfung zu antworten, selbst wenn Daten bereits deterministisch sind
• fehlende Metriken, die den Nutzen jedes tool-calls zeigen

Daraus folgen Probleme:

• höhere latency - jeder tool-call fügt Netzwerk- und Rechenschritt hinzu
• höhere cost - Anzahl von LLM/tool-Calls wächst pro typische Anfrage
• fragile Szenarien - selbst ein einfacher Fall wird vom externen Service abhängig
• Risiko für Seiteneffekte (Zustandsänderungen) - ein unnötiger Call kann Status erneut updaten oder externe Aktion duplizieren
• schwieriges Debugging - schwerer zu erklären, warum eine einfache Anfrage überhaupt im tool-path landete

Anders als bei Too Many Tools liegt das Hauptproblem hier nicht in der Auswahl zwischen vielen Tools, sondern in der Entscheidung, überhaupt einen tool-call zu machen, obwohl er nicht nötig ist.

Typische Production-Signale, dass tool-calling bereits übermäßig ist:

• die meisten FAQ- oder Policy-Anfragen gehen durch tool-call, obwohl Antwort deterministisch ist
• tool_call_rate für FAQ- oder Policy-Routen bleibt hoch (z. B. 80%+)
• cost per request steigt, während success rate kaum verändert ist
• Ausfall eines Tools bricht ein Szenario, das lokal funktionieren könnte
• Team kann nicht klar erklären, wann tool-call verpflichtend ist und wann nicht

Wichtig: Jeder tool-call bedeutet meist einen neuen Prompt und eine neue LLM inference. Wenn es viele unnötige Aufrufe gibt, wächst die Schrittzahl ohne Zuwachs an nützlichem Ergebnis.

Ohne trace und Ausführungsvisualisierung ist schwer zu sehen, welcher Anteil einfacher Anfragen wirklich über no_tool Route geht und welcher Anteil noch durch unnötige tool-calls läuft.

Richtiger Ansatz

Startet mit einem Pfad ohne Tools als Standard. Ergänzt tool-call nur dann, wenn externe Daten, Prüfung des aktuellen Zustands oder eine externe Aktion wirklich nötig ist.

Praktischer Rahmen:

• definiert pro Anfrage-Typ: no_tool oder tool_required
• versucht zuerst, Anfrage ohne tool-call zu lösen
• haltet deterministische Antworten in workflow oder Code
• für tool-Pfad: enge allowlist und klarer Trigger
• ergänzt einen neuen tool-call nur mit messbarem Grund (z. B. bessere success rate ohne starken Anstieg von latency und cost per request)

def answer_support_question(user_message: str, order_id: str, region: str) -> str:
    route = classify_intent(user_message)  # simple classifier or rules

    if route == "return_policy":
        return format_return_policy(local_return_policy(region))  # static config or local rules

    if route == "order_status":
        data = run_tool("get_order_status", order_id)
        return format_order_status(data)

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

In diesem Setup wird tool-call gezielt: Tools werden dort aufgerufen, wo sie wirklich nötig sind, nicht standardmäßig.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet werden, habt ihr ein tool-calling-for-everything Risiko:

• Löst eine einfache FAQ- oder Policy-Anfrage regelmäßig mindestens einen tool-call aus?
• Bricht ein Tool-Ausfall manchmal ein Szenario, das ohne externen Call funktionieren könnte?
• Ist bei einem typischen Fall die Anzahl von tool/LLM-Schritten höher als nötig (wo 0-1 Calls reichen würden)?

Worin es sich von anderen Anti-Patterns unterscheidet

Too Many Tools vs Tool Calling for Everything

Kurz gesagt: Too Many Tools betrifft die instabile Auswahl zwischen vielen Tools, Tool Calling for Everything den unnötigen Tool-Call an sich.

Agent Everywhere Problem vs Tool Calling for Everything

Kurz gesagt: Agent Everywhere Problem betrifft unnötiges Agenten-Reasoning, Tool Calling for Everything unnötige externe Aufrufe selbst innerhalb eines Agentenpfads.

Giant System Prompt vs Tool Calling for Everything

Kurz gesagt: Diese Anti-Patterns überschneiden sich, wenn always call tool in großem Prompt versteckt ist statt in expliziter Routing-Logik.

Selbstcheck: Habt ihr dieses Anti-Pattern?

Schnellcheck für Anti-Pattern Tool Calling for Everything.
Markiert die Punkte für euer System und prüft den Status unten.

Prüft euer System:

FAQ

Q: Bedeutet das, dass Tools kaum genutzt werden sollten?
A: Nein. Tools sind nötig, wenn externe Daten gebraucht werden, aktueller Zustand geprüft werden muss oder eine externe Aktion auszuführen ist. Problematisch wird es nur, wenn tool-call für alle Fälle zum Standard wird.

Q: Wann ist tool-call wirklich gerechtfertigt?
A: Wenn ohne ihn in diesem Szenario kein korrektes Ergebnis zuverlässig erreichbar ist, ohne unverhältnismäßigen Anstieg von latency, cost oder Debugging-Komplexität.

Q: Wie reduziert man unnötige tool-calls ohne großen Refactor?
A: Startet mit einem Schritt: ergänzt eine no_tool Route für den häufigsten deterministischen Fall und definiert eine Regel, wann tool-call verpflichtend ist.

Was als Nächstes

Ähnliche Anti-Patterns:

• Too Many Tools - wenn in einer Route zu viele Tools liegen und Aktionswahl instabil wird.
• Agent Everywhere Problem - wenn Agenten auch für Aufgaben genutzt werden, die besser in workflow laufen.
• Giant System Prompt - wenn Regeln in einem Prompt stabiles Verhalten erschweren.

Was ihr stattdessen bauen solltet:

• Allowed Actions - wie erlaubte Aktionen pro Szenario im Code festgelegt werden.
• Routing Agent - wie deterministische Routen und komplexe Fälle getrennt werden.
• Tool Execution Layer - wo tool-calls, Policies und Limits zentral kontrolliert werden.