Anti-Pattern Overengineering Agents: zu komplexe Agent-Architektur

Idee in 30 Sekunden

Overengineering Agents ist ein Anti-Pattern, bei dem für eine einfache Aufgabe eine zu komplexe Agentenarchitektur gebaut wird: zu viele Schichten, Rollen, Router und Checks ohne echten Nutzen.

Das System wird dadurch teurer, langsamer und schwerer wartbar. Das Team verbringt mehr Zeit mit Architekturpflege als mit Nutzerwert.

Einfache Regel: Wenn eine Aufgabe mit einem workflow oder einem Agenten stabil lösbar ist, baut keine mehrstufige Architektur.

Beispiel für das Anti-Pattern

Das Team möchte typische Fragen zur Rückgabe beantworten.

Statt eines einfachen Szenarios baut das Team eine Kaskade aus mehreren Agenten und Zwischenschichten.

response = gateway_agent.run(
    "User: Wie kann ich einen Artikel aus Bestellung #7342 zurückgeben?"
)

Praktisch läuft eine einfache Anfrage durch diese Kette:

plan = planner_agent.run(user_message)
routed = router_agent.run(plan)
draft = faq_agent.run(routed)
checked = policy_agent.run(draft)
final = critic_agent.run(checked)
return final

Für diesen Fall reicht ein kurzer workflow:

policy = get_return_policy(order_id)
return format_return_answer(policy)

In diesem Fall fügt die überladene Architektur nur hinzu:

• unnötige Schichten zwischen Anfrage und Antwort
• mehr potenzielle Ausfallpunkte
• höhere Kosten pro Run

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn Teams sofort eine "Enterprise-Lösung" bauen wollen, selbst für Basisszenarien.

Typische Ursachen:

• Sorge, dass eine einfache Architektur "nicht skaliert"
• Übernahme komplexer Schemata aus fremden Fällen ohne Validierung der eigenen Aufgabe
• Wunsch, Komponenten "vorsorglich" hinzuzufügen
• fehlende Metriken, die den Nutzen jeder Schicht belegen

Daraus folgen Probleme:

• höhere latency - Antworten laufen durch unnötige Stufen
• schwieriges Debugging - Fehler kann in jeder Schicht liegen
• höhere Kosten - mehr LLM-Calls und technische Zwischenschritte
• aufgeblähter Kontext - Agenten reichen Historie und Zwischenresultate weiter
• niedrigere Zuverlässigkeit - mehr Komponenten = mehr potenzielle Ausfälle

Typische Production-Signale, dass ein System bereits überengineered ist:

• Änderung einer Policy-Regel erfordert Anpassungen in mehreren Schichten
• das Team kann nicht schnell zeigen, wo die finale Entscheidung getroffen wird
• eine typische User-Anfrage startet 4-6 LLM/tool-Schritte, obwohl 1-2 ausreichen würden
• das Entfernen einer Zwischenschicht bricht bereits ein Basisszenario

Am Ende kann das Team nicht mehr schnell erklären, welche Schicht wirklich nötig ist, und jede Änderung an einem einfachen Szenario betrifft sofort mehrere Komponenten. Wenn ein System komplex wird, ohne trace und Ausführungsvisualisierung, wird Debugging sehr schwierig. Deshalb haben Production-Systeme meist eine eigene Observability-Schicht für Agent-Runs.

Richtiger Ansatz

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

Praktischer Rahmen:

• workflow für deterministische Szenarien
• ein Agent für komplexe oder nicht-standardisierte Fälle
• neue Schicht nur bei messbarem Grund (zum Beispiel bessere success rate oder weniger Fehler ohne starken Anstieg von latency und cost per request)

def answer_return_question(order_id: str, user_message: str) -> str:
    policy = get_return_policy(order_id)

    if policy.is_standard_case:
        return format_return_answer(policy)

    return agent.run(
        f"Erkläre diesen nicht standardmäßigen Rückgabefall: {policy.context}"
    )

In diesem Setup bleibt das System einfach, und der Agent wird nur dort eingesetzt, wo er wirklich nötig ist.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet werden, habt ihr Overengineering-Risiko:

• Habt ihr 4+ Schichten, könnt aber für keine den Nutzen in Metriken zeigen?
• Erfordert ein einfacher Fehler den Durchlauf durch viele Komponenten fürs Debugging?
• Laufen die meisten Anfragen aktuell durch zusätzliche Agentenstufen, obwohl es einfacher lösbar wäre?

Worin es sich von anderen Anti-Patterns unterscheidet

Multi-Agent Overkill vs Overengineering Agents

Giant System Prompt vs Overengineering Agents

Agent Everywhere Problem vs Overengineering Agents

Selbstcheck: Habt ihr dieses Anti-Pattern?

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

Prüft euer System:

FAQ

Q: Bedeutet das, dass komplexe Architektur immer schlecht ist?
A: Nein. Komplexität ist gerechtfertigt, wenn sie ein reales Problem löst und das in Metriken sichtbar ist. Problematisch ist unnötige Komplexität ohne Nutzen.

Q: Wann sollten wir einen neuen Agenten oder eine neue Schicht hinzufügen?
A: Wenn es ein konkretes Signal gibt: Incidents, Qualitätsfehler, Limit-Verletzungen oder eine neue Aufgabenklasse, die das aktuelle Design nicht ohne unverhältnismäßiges Wachstum bei latency, cost oder Debugging-Komplexität abdeckt.

Q: Sollen wir alle Schichten sofort entfernen?
A: Nein. Besser schrittweise: Komponenten ohne messbaren Effekt entfernen und nach jeder Vereinfachung die Metriken prüfen.

Was als Nächstes

Ähnliche Anti-Patterns:

• Agent Everywhere Problem - wenn ein Agent selbst dort ergänzt wird, wo ein normaler workflow ausreicht.
• Multi-Agent Overkill - wenn das System zu viele Agenten ohne klare Rollenaufteilung hat.
• Too Many Tools - wie ein Übermaß an Tools das Agentenverhalten instabil macht.

Was ihr stattdessen bauen solltet:

• Hybrid Workflow + Agent - praktischer Weg, einfachen workflow mit einem Agentenpfad zu kombinieren.
• Production-Ready Agent - Kernprinzipien, damit die Architektur in realen Umgebungen steuerbar bleibt.