Agenten scheitern nicht in Demos, sondern in der Orchestrierung: wofür Produktionsteams Haystack nutzen, um Routing, Memory und Retrieval zu steuern

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und ich realisiere bei DennisCraft AI Studio produktive KI-Systeme auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres für DACH-B2B-Kunden. In einer Demo wirken Agenten fast immer überzeugend; im Produktivbetrieb scheitern sie meist früher als erwartet, nicht am Reasoning, sondern an der Orchestrierung: Das Routing wählt die falsche Quelle, Memory hält veraltete Fakten fest, und Retrieval lädt zu viele ähnliche Textstellen in den Kontext.

Genau deshalb betrachten erfahrene Teams Haystack nicht primär als Chatbot-Framework, sondern als Mittel, um Routing, Memory und Retrieval als steuerbare Verarbeitungskette aufzubauen. Wenn ein System unter DSGVO, ISO 27001, BSI Grundschutz oder perspektivisch dem EU AI Act betrieben wird, zählt nicht nur die Antwort, sondern auch die Nachvollziehbarkeit ihres Entstehungswegs.

Im Produktivbetrieb liegt der Fehler oft zwischen den Bausteinen

Viele Probleme in Agentensystemen sind keine Modellprobleme. Es sind Architekturprobleme. Ein leistungsfähiges Modell innerhalb einer schwachen Orchestrierung liefert dennoch instabiles Verhalten, weil zuerst 3 Steuerflächen driften:

• Routing: Welche Datenquelle, welches Werkzeug oder welcher Ablauf wird gewählt?
• Memory: Welche Fakten bleiben erhalten und welche müssen verfallen?
• Retrieval: Welche Dokumente gelangen in den Kontext und auf welcher Grundlage?

Die Dokumentation von Anthropic zu Tool Use und strukturierten Ausgaben betont genau diese Punkte: klare Verträge, begrenzte Handlungsspielräume und überprüfbarer Systemzustand. Siehe https://docs.anthropic.com/ . In produktiven Umgebungen ist das meist wichtiger als ein weiterer Durchlauf am Prompt.

Was Produktionsteams konkret aus Haystack mitnehmen

Explizite Verarbeitungsketten statt verborgener Agentenlogik

Der praktische Wert von Haystack liegt nicht darin, Agenten besonders klug erscheinen zu lassen. Entscheidend ist, dass das System in explizite Bausteine zerlegt wird: Retriever, Router, Ranker, Prompt Builder, Generator, Validator. Wenn eine Antwort fehlerhaft ist, lässt sich gezielt fragen, welcher Schritt versagt hat.

Das ist für Sicherheitsprüfung, Ursachenanalyse und spätere Freigabeprozesse relevant. Wer nur die Endantwort protokolliert, erzählt im Fehlerfall eher eine Geschichte, als dass er den Ablauf belegen kann.

Routing wird zu einer geregelten Schicht

In vielen Demos entscheidet das Modell allein: welches Werkzeug, welcher Index, welcher nächste Schritt. Im Produktivbetrieb ist das zu offen. Haystack hilft, Routing als eigene Steuerungsschicht zu behandeln.

Eine sinnvolle Routing-Politik kann zum Beispiel so aussehen:

• Enthält die Anfrage eine Vertrags- oder Vorgangsnummer, erfolgt zuerst ein Abgleich in Postgres.
• Liegt ein frischer strukturierter Datensatz vor, wird kein Dokumenten-Retrieval gestartet.
• Liegt die Sicherheit des Retrievals unter einem Schwellwert, fordert das System eine Präzisierung an.
• Berührt die Anfrage einen regulierten Vorgang, wird vor einer schreibenden Aktion eine menschliche Freigabe verlangt.

Das ist keine Geschmacksfrage. OWASP führt Prompt Injection und übermäßige Handlungsfreiheit in den OWASP Top 10 for LLM Applications 2025 auf: https://genai.owasp.org/llm-top-10/ . Ohne begrenztes Routing lässt sich ein Agent leichter in den falschen Pfad lenken.

Memory ist eine Richtlinie, keine Chat-Funktion

Viele Teams behandeln Memory wie einen langen Gesprächsverlauf. Im Produktivbetrieb sollte mindestens zwischen Session Memory, Task Memory und verifizierter System Memory unterschieden werden. Genau diese Trennung macht Haystack als Denkmodell wertvoll.

Ohne Trennung werden Zwischenannahmen zu vermeintlichen Tatsachen, alte Statusinformationen tauchen als aktuelle Wahrheit wieder auf, und das System begründet Entscheidungen mit eigenen früheren Ausgaben. In mehreren meiner jüngeren Projekte war das häufiger die Ursache als klassische Halluzination.

Retrieval im Produktivbetrieb: enger, messbarer, nachvollziehbarer

Ein häufiger Fehler besteht darin, Retrieval-Probleme mit mehr Kontext lösen zu wollen. In produktiven Systemen funktioniert meist das Gegenteil besser: engeres Retrieval, strengere Metadatenfilter, besseres Reranking und klare Behandlung unsicherer Treffer. Das OpenAI Cookbook zeigt in seinen RAG-Beispielen immer wieder, dass Chunking, Filterung und Ranking ebenso wichtig sind wie Embeddings: https://cookbook.openai.com/ .

Für eine belastbare Bewertung verlange ich zuerst 3 Kennzahlen:

• Retrieval-Precision auf einer manuell bewerteten Stichprobe,
• Anteil der Anfragen mit Rückfallpfad oder menschlicher Eskalation,
• Anzahl der Routen, in denen eine nicht maßgebliche Quelle ausgewählt wurde.

Ohne diese Zahlen wird “klingt plausibel” schnell mit “ist steuerbar” verwechselt.

Ein praktisches Muster mit Postgres, Supabase und n8n

Sie müssen nicht jede Komponente in Haystack abbilden, um dieselbe Orchestrierungslogik zu nutzen. Entscheidend sind explizites Routing und sichtbare Entscheidungswege. Das folgende Python-Beispiel prüft zuerst strukturierte Daten und greift erst dann auf das Modell zurück.

import os
import psycopg
from anthropic import Anthropic

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

def fetch_case(case_id: str):
    with psycopg.connect(os.environ["DATABASE_URL"]) as conn:
        with conn.cursor() as cur:
            cur.execute(
                "select status, summary from cases where id = %s",
                (case_id,)
            )
            return cur.fetchone()

def handle_request(query: str, case_id: str | None = None):
    if case_id:
        row = fetch_case(case_id)
        if row:
            status, summary = row
            return f"Case {case_id}: {status}. {summary}"
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=300,
        messages=[{"role": "user", "content": query}],
    )
    return msg.content[0].text

Dasselbe Prinzip lässt sich in einem Ablauf mit n8n sichtbar halten:

steps:
  - name: classify_request
    type: llm
  - name: lookup_postgres
    type: postgres
    run_if: "{{ $json.route == 'structured_lookup' }}"
  - name: retrieve_docs
    type: http
    run_if: "{{ $json.route == 'retrieval' }}"
  - name: human_review
    type: manual
    run_if: "{{ $json.confidence < 0.75 }}"

Wichtig ist weniger die Syntax als die Disziplin: Route, Sicherheitsschwelle und menschliche Eskalation müssen sichtbar sein. Genau das hilft später bei Prüfung, Freigabe und Störungsanalyse.

Warum das für regulierte Märkte besonders relevant ist

In regulierten europäischen Märkten ist Orchestrierung nicht nur eine Qualitätsfrage, sondern eine Governance-Frage. Wenn ein Agent mit Kundendaten, Vertragsstatus, Zahlungsabläufen oder internen Verfahrensanweisungen arbeitet, müssen Sie begründen können, warum genau diese Quelle gewählt wurde und warum ein bestimmter Fakt in den Kontext gelangt ist.

Deshalb übernehmen viele Teams aus Haystack vor allem eine Pipeline-First-Disziplin:

• explizite Verarbeitungsschritte,
• Trennung verifizierter Daten von generiertem Text,
• protokollierte Routing-Entscheidungen,
• kontrollierte Rückfallpfade und menschliche Prüfung.

Spätestens unter Anforderungen aus DSGVO, NIS2 oder dem EU AI Act reicht ein selbstsicher formulierter Modelltext nicht als Begründung.

FAQ

Ist Haystack nur für RAG sinnvoll?

Nein. Der größere Nutzen liegt in der klaren Strukturierung von Verarbeitungsschritten und Entscheidungswegen. RAG ist nur ein häufiger Anwendungsfall.

Kann ich dieselben Muster ohne Haystack umsetzen?

Ja. Ich setze häufig direkt auf Anthropic SDK, Postgres, Supabase und n8n. Wichtig ist nicht der Name des Frameworks, sondern die saubere Orchestrierung.

Was verursacht im Produktivbetrieb mehr Probleme: Memory oder Retrieval?

Meist deren Zusammenspiel. Schwaches Retrieval bringt unzuverlässigen Kontext ein, und schwache Memory-Politik macht daraus eine dauerhafte Annahme.

Sollte das Modell Werkzeuge selbst auswählen dürfen?

Teilweise, aber nur innerhalb enger Grenzen. In sensiblen Abläufen ist eingeschränkte Auswahl mit sichtbaren Rückfallpfaden meist sicherer als vollständige Autonomie.

Wo beginnt eine sinnvolle Prüfung der Orchestrierung?

Bei Routenübersicht und Protokollen je Verarbeitungsschritt. Wenn Sie nicht nachvollziehen können, warum das System eine Quelle oder Aktion gewählt hat, steuern Sie den Agenten nicht wirklich.

An welcher Stelle Ihrer LLM-Pipeline entstehen im Produktivbetrieb derzeit die meisten Probleme: beim Routing, in der Memory-Politik, in der Retrieval-Qualität oder beim fehlenden Rückfall auf menschliche Prüfung? Ich würde das gern mit den Mustern vergleichen, die ich aktuell in DACH-Projekten sehe.
I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.