Production Stack: Verlässliche Agent-Systeme aufbauen

Die Idee in 30 Sekunden

Production Stack ist keine einzelne Komponente, sondern ein abgestimmtes Set von Architektur-Schichten, die ein Agent-System in Production gemeinsam steuerbar machen.

Das ist nicht "mehr Prompts". Es sind explizite Verantwortungsgrenzen:

• wer Entscheidungen trifft;
• wer eine Aktion erlaubt oder blockiert;
• wo State gespeichert wird;
• wie Risiken, Budgets und Ausfälle kontrolliert werden.

Wann man es braucht: wenn ein Agent lange laufen, state-changing Aktionen ausführen, viele Kunden bedienen und unter Last vorhersagbar bleiben muss.

Das LLM schlägt den nächsten Schritt vor, aber der Production Stack entscheidet, ob der Schritt ausgeführt werden darf, wo er ausgeführt wird und wie der Prozess sicher gestoppt wird.

Problem

Wenn man einen Agenten als "Modell + ein paar Tool Calls" baut, wird das System schnell fragil.

Typische Folgen:

• keine klaren stop conditions, daher bleibt der Agent in Loops hängen;
• keine Policy-Grenzen, daher gehen riskante Aktionen ohne Kontrolle durch;
• keine Memory-Qualität, daher entstehen Duplikate, Rauschen oder falsche Personalisierung;
• keine Tenant-Isolation, daher steigt das Risiko für cross-tenant Leaks;
• keine operative Disziplin, daher werden Rollout, Rollback und Incident Response chaotisch;
• kein End-to-End-Audit, daher ist nach einem Ausfall schwer erklärbar, was passiert ist.

In Production bedeutet das meist Sicherheitsvorfälle, Budgetüberschreitungen und instabile Antwortqualität.

Lösung

Production Stack als explizites Architektur-Schema hinzufügen, in dem jede Schicht einen klaren Vertrag und ihre eigene Verantwortungszone hat.

Typische Stack-Zusammensetzung:

1. Ingress + Auth (actor/tenant bestimmen);
2. Orchestration Topology (route, handoff, stop);
3. Agent Runtime (steps, Limits, reason_code);
4. Tool Execution Layer (Validierung und Kontrolle von side effects, also Zustandsänderungen);
5. Memory Layer (gesteuertes Memory-Retrieve/Write);
6. Policy Boundaries + Human-in-the-Loop (erlauben, blockieren, freigeben);
7. Containerization + Observability + Operations (reproduzierbarer Run, Health Checks, Rollback);
8. Multi-Tenant Isolation (Isolation von Kontext, Zugriffen und Ressourcen).

Analogie: wie ein moderner Flughafen.

Es gibt Check-in, Sicherheitskontrolle, Routing, Dispatch, Event-Log und Notfallverfahren.

Production Stack verwandelt genauso "ein einzelnes smartes Modul" in ein gesteuertes System mit Ausführungsregeln.

Wie Production Stack funktioniert

Production Stack verbindet alle wichtigen Grenzen in einen gesteuerten Zyklus: von der eingehenden Anfrage bis zur kontrollierten Ausführung, Audit und Recovery.

Dieser Zyklus nimmt dem Agent-System die "Magie" und macht es unter realer Last vorhersagbar.

Im Code sieht es so aus

class ProductionStack:
    def __init__(self, ingress, topology, runtime, memory, policy, hitl, tools, audit):
        self.ingress = ingress
        self.topology = topology
        self.runtime = runtime
        self.memory = memory
        self.policy = policy
        self.hitl = hitl
        self.tools = tools
        self.audit = audit

    def run(self, request, auth_token):
        ctx = self.ingress.identify(request=request, auth_token=auth_token)
        if not ctx.get("ok", False):
            return {"ok": False, "reason_code": ctx.get("reason_code", "auth_failed")}

        state = self.runtime.start(
            request=request,
            tenant_id=ctx["tenant_id"],
            budgets=ctx["budgets"],
        )

        while not self.runtime.should_stop(state):
            route = self.topology.next_step(state=state)
            route_mode = route.get("mode")

            if route_mode == "finish":
                return {
                    "ok": True,
                    "result": route.get("final_answer", ""),
                    "reason_code": "completed",
                }
            if route_mode != "action":
                return {"ok": False, "reason_code": "unknown_route_mode"}

            memory_items = self.memory.retrieve(
                tenant_id=ctx["tenant_id"],
                query=route["query"],
                top_k=4,
                min_score=0.7,
                exclude_expired=True,
            )

            action = self.runtime.decide(route=route, memory_items=memory_items)
            decision = self.policy.check(action=action, context=ctx)
            mode = decision.get("mode")

            if mode == "deny":
                self.audit.log(context=ctx, action=action, outcome="blocked", reason_code=decision.get("reason_code", "policy_denied"))
                return {"ok": False, "reason_code": decision.get("reason_code", "policy_denied")}
            elif mode == "require_approval":
                approval = self.hitl.review(action=action, context=ctx)
                if not approval.get("approved", False):
                    reason = approval.get("reason_code", "approval_rejected")
                    self.audit.log(context=ctx, action=action, outcome="blocked", reason_code=reason)
                    return {"ok": False, "reason_code": reason}
                action = approval.get("action_override", action)
            elif mode != "allow":
                reason = decision.get("reason_code", "policy_mode_invalid")
                self.audit.log(context=ctx, action=action, outcome="blocked", reason_code=reason)
                return {"ok": False, "reason_code": reason}

            result = self.tools.execute(action=action, context=ctx)
            self.audit.log(
                context=ctx,
                action=action,
                outcome="executed" if result.get("ok", False) else "failed",
                reason_code=result.get("reason_code", "tool_unknown"),
            )

            self.runtime.observe(state=state, action=action, result=result)
            self.memory.write_if_useful(
                tenant_id=ctx["tenant_id"],
                state=state,
                result=result,
            )

        return {"ok": False, "reason_code": self.runtime.stop_reason(state)}

So sieht es während der Ausführung aus

Anfrage: "Erstelle ein kommerzielles Angebot, gleiche riskante Punkte ab und sende die finale Version an den Kunden"

Step 1
Ingress + Auth: bestimmt actor, tenant, Budgets und request_id
Orchestration Topology: teilt die Aufgabe in Phasen "sammeln", "entwurf", "finalisieren"

Step 2
Agent Runtime: bildet action
Policy + HITL: aktiviert require_approval für den Versand an den Kunden
Human gibt die finale Version frei

Step 3
Tool Execution Layer: führt die freigegebene Aktion aus
Memory Layer: speichert wichtige Fakten mit TTL
Audit + Trace: protokolliert decision, reason_code, outcome

Production Stack ersetzt keine einzelnen Patterns. Er verbindet sie zu einem gesteuerten Production-System.

Wann es passt und wann nicht

Production Stack wird dort gebraucht, wo ein Agent als Service laufen muss, nicht als einmaliges Demo-Skript.

Passt

Passt nicht

Für einen minimalen Prototyp reicht manchmal ein einfacher Run:

result = runtime.run(task=request["text"], max_steps=8, max_seconds=20)

Typische Probleme und Ausfälle

Die meisten Production-Probleme entstehen nicht durch einen einzelnen "Modellfehler", sondern durch schwache Grenzen zwischen Architektur-Schichten.

Wie es mit anderen Patterns zusammenspielt

Production Stack konkurriert nicht mit anderen Patterns. Er bündelt sie in ein abgestimmtes System.

• Agent Runtime — steuert den Schrittzyklus und stop conditions.
• Tool Execution Layer — kontrolliert Tool-Ausführung und side effects (Zustandsänderungen).
• Memory Layer — liefert und schreibt nur nützliche Memory nach Qualitätskriterien.
• Policy Boundaries — definiert allow/deny/require_approval für riskante Aktionen.
• Orchestration Topologies — legt die Task-Route zwischen Agenten fest.
• Hybrid Workflow Agent — trennt deterministischen workflow und bounded Agent-Entscheidungen.
• Human-in-the-Loop Architecture — ergänzt menschliche Kontrolle an kritischen Punkten.
• Containerizing Agents — liefert reproduzierbare Ausführung, health checks und rollout-Kontrolle.
• Multi-Tenant — isoliert Kontext, Ressourcen und Zugriffe zwischen Kunden.

Anders gesagt:

• Production Stack definiert wie all diese Schichten zusammen als ein System arbeiten
• Jedes einzelne Pattern deckt seinen eigenen spezifischen Risikotyp ab

Kurz gesagt

FAQ

Q: Womit starten, wenn es nicht sofort Ressourcen für den ganzen Stack gibt?
A: Mit Runtime (Limits + stop reasons), Tool Execution Layer (Validierung + timeout) und Audit starten. Danach schrittweise policy/HITL, Memory-Qualität und Multi-Tenant-Isolation ergänzen.

Q: Kann man Production Stack mit nur einem Agenten haben, ohne Multi-Agent-Topologie?
A: Ja. Die Topologie kann einfach sein, aber die anderen Schichten bleiben nötig, wenn riskante Aktionen oder Production-Last vorhanden sind.

Q: Ersetzt Production Stack Observability oder SRE-Praktiken?
A: Nein. Es enthält sie als Teil der Architektur, braucht aber weiterhin operative Disziplin: Monitoring, Alerts, Rollout und Incident Response.

Q: Was bricht zuerst, wenn der Stack unvollständig ist?
A: Meist brechen zuerst Ausführungsgrenzen: entweder unkontrollierte Tool Calls, noisy Memory oder Policy-Lücken ohne Audit.

Was als Nächstes

Production Stack ist die Karte des Gesamtsystems. Jetzt kannst du tiefer in die Schichten gehen, die am häufigsten zuerst ausfallen:

• Tool Execution Layer — Kontrolle von Tools, Timeouts und side effects (Seiteneffekten, also Zustandsänderungen).
• Memory Layer — Memory-Qualität, TTL und Kontrolle sensibler Daten.
• Policy Boundaries — allow/deny/approval für riskante Aktionen.
• Multi-Tenant — Isolation von Kontext, Ressourcen und Budgets über Kunden hinweg.