Anti-Pattern Single-Step Agents: Agenten mit nur einem Schritt

Idee in 30 Sekunden

Single-Step Agents wird zum Anti-Pattern, wenn ein einzelner Schritt für Aufgaben mit tools, side effects oder Mehrdeutigkeit verwendet wird.

Dadurch gibt es keinen Platz für Validierung, Recovery und kontrolliertes Stoppen. Für Aufgaben mit tools oder side effects (Zustandsänderungen) wird das in Production schnell fragil.

Für sichere read-only Fälle kann single-step okay sein, aber für Aufgaben mit tools oder side effects braucht ihr eine bounded loop mit explizitem stop_reason.

Beispiel für das Anti-Pattern

Das Team baut einen Support-Agenten, der Daten suchen und Aktionen in externen Systemen ausführen soll.

Die Implementierung macht aber nur einen Schritt: eine Aktionsentscheidung und eine Ausführung.

decision = agent.decide(user_message)
result = run_tool(decision.tool, decision.args)
return result

In diesem Setup gibt es keine erneute Bewertung nach dem Tool-Result:

# kein validate_output(...)
# kein no_progress(...)
# kein stop_reason

Für diesen Fall braucht ihr eine kontrollierte Schleife mit Grenzen:

for step in range(MAX_STEPS):
    decision = agent.next_step(state)
    ...

In diesem Fall bringt der single-step Ansatz:

• frühes Risiko einer falschen Aktion
• kein Recovery nach Tool-Fehlern
• schwache Qualitätskontrolle der finalen Antwort

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn das Team "zur Vereinfachung" optimiert und das Agent-System auf einen einzigen Model-Call reduziert.

Typische Ursachen:

• Wunsch, latency um jeden Preis zu senken
• Verwechslung von "single LLM call" mit einem "vollwertigen Agenten"
• fehlende Anforderungen an stop reasons und Output-Validierung
• Hoffnung, dass der Prompt allein Recovery-Szenarien abdeckt

Daraus folgen Probleme:

• keine recovery-loop - nach einem Tool-Fehler kann der Agent nicht weiterarbeiten
• Risiko verfrühter write-Aktion - side effect kann vor Validierung passieren
• fragiler Output - keine Phase zur Prüfung "ist die Aufgabe wirklich gelöst"
• schwieriges Debugging - run endet ohne transparente Begründung
• Instabilität in Production - ein fehlerhafter Schritt wird sofort zum Incident

Im Unterschied zu No Stop Conditions gibt es hier nicht einmal einen kontrollierten Loop: das Problem beginnt früher, beim Design "ein Schritt und fertig".

Typische Production-Signale, dass single-step bereits gefährlich ist:

• Aufgaben mit tools und side effects laufen ohne max_steps/stop_reason
• ein fehlgeschlagener tool-call beendet den run sofort ohne sichere Recovery-Versuche
• ein Routing-Fehler führt zu einer externen Aktion ohne zusätzliche Prüfung
• das Team kann nicht erklären, warum genau diese Aktion in diesem run gewählt wurde

Wichtig: Jeder Agent-Schritt ist Teil der LLM inference. Im single-step Design erlaubt ihr effektiv einer einzigen inference, eine kritische Entscheidung ohne Prüfung zu treffen.

Richtiger Ansatz

Startet mit einer minimalen bounded loop für alle Szenarien mit tools oder side effects. Single-step bleibt nur für wirklich sichere read-only low-risk Fälle ohne tool-call.

Praktischer Rahmen:

• trennt Routen: read_only_single_step und loop_required
• definiert für den Loop-Pfad max_steps, timeout, stop_reason
• ergänzt Prüfungen validate_output und no_progress
• führt write-Aktionen nur nach expliziten policy-Prüfungen aus

MAX_STEPS = 6

def run_support_flow(user_message: str):
    route = classify_intent(user_message)  # simple classifier or rules

    if route == "read_only_faq":
        return run_single_step_answer(user_message)  # no tools, no side effects

    state = init_state(user_message)

    for step in range(MAX_STEPS):  # hard limit for unsafe loops
        decision = agent.next_step(state)

        if decision.type == "final_answer":
            if validate_output(decision.output):  # format and required fields
                return decision.output
            return stop("invalid_output")

        result = run_tool(decision.tool, decision.args)
        if no_progress(state, result):  # repeated pattern or no meaningful state change
            return stop("no_progress")
        state.append(result)

    return stop("max_steps_exceeded")

In diesem Setup werden Risiken steuerbar: Das System schließt die Aufgabe oder stoppt mit transparenter Begründung.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet sind, habt ihr ein Risiko für das Anti-Pattern Single-Step Agents:

• Werden Aufgaben mit tools und side effects über einen model call ausgeführt?
• Endet der run nach einem fehlgeschlagenen tool-result ohne Recovery-Schritt?
• Fehlt ein expliziter stop_reason, wenn das Szenario nicht korrekt abgeschlossen wird?

Worin es sich von anderen Anti-Patterns unterscheidet

Agent Everywhere Problem vs Single-Step Agents

Kurz gesagt: Agent Everywhere Problem betrifft die unnötige Wahl eines Agenten, Single-Step Agents betrifft eine gefährliche Ausführungsart des Agenten.

No Stop Conditions vs Single-Step Agents

Kurz gesagt: No Stop Conditions betrifft einen unkontrollierten Loop, Single-Step Agents betrifft das Fehlen eines Loops dort, wo er nötig ist.

Tool Calling for Everything vs Single-Step Agents

Kurz gesagt: Tool Calling for Everything erhöht die Zahl unnötiger Aufrufe, Single-Step Agents erhöht das Risiko eines unkontrollierten kritischen Aufrufs.

Selbstcheck: Habt ihr dieses Anti-Pattern?

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

Prüft euer System:

FAQ

Q: Ist single-step immer schlecht?
A: Nein. Es passt zu sicheren read-only Szenarien ohne tools und side effects. Das Problem beginnt, wenn es für Aufgaben mit Recovery- und Kontrollbedarf genutzt wird.

Q: Woran erkennen wir, dass wir auf Loop wechseln müssen?
A: Wenn es tool-calls, externe Aktionen, mehrdeutigen Output oder ein Risiko mit hohem Impact gibt, braucht ihr eine bounded loop mit explizitem stop_reason.

Q: Steigt die latency nach dem Wechsel zu Loop stark?
A: Kann steigen, aber das wird über budget limits gesteuert. In Production ist ein kontrolliertes und sicheres Ergebnis meist wichtiger als "schnell, aber fragil".

Was als Nächstes

Ähnliche Anti-Patterns:

• Agent Everywhere Problem - wenn ein Agent hinzugefügt wird, wo ein workflow reicht.
• No Stop Conditions - wenn ein Loop existiert, aber kein kontrollierter Stopp.
• Tool Calling for Everything - wenn tools ohne expliziten Bedarf aufgerufen werden.

Was ihr stattdessen bauen solltet:

• Stop Conditions - wie Abschlussbedingungen für einen kontrollierten run definiert werden.
• Routing Agent - wie read-only und side-effecting Routen getrennt werden.
• Tool Execution Layer - wie tool-calls sicher über policy und Limits ausgeführt werden.