Containerizing Agents: Agenten stabil in Produktion betreiben

Die Idee in 30 Sekunden

Containerizing Agents ist ein Architekturansatz, bei dem ein Agent als isolierter und reproduzierbarer Service in einem Container läuft.

Das ist nicht nur ein Dockerfile. Es ist eine kontrollierte Grenze zwischen Agent-Code und Production-Umgebung: Abhängigkeiten, Konfig, Secrets, Ressourcen, Health Checks und Service-Updates.

Wann man es braucht: wenn der Agent nicht nur lokal läuft, sondern als echter Service mit Last, Updates und Zuverlässigkeitsanforderungen.

Ein LLM sollte die Infrastruktur nicht selbstständig steuern. Die Container-Schicht erzwingt Ausführungsgrenzen, damit der Agent nach dem Deploy stabil bleibt.

Problem

Lokal funktioniert ein Agent oft gut, aber nach dem Deploy beginnen instabile Ausfälle.

Typische Probleme ohne gesteuerte Containerisierung:

• unterschiedliche Umgebungen erzeugen unterschiedliches Verhalten für denselben Code;
• Abhängigkeiten oder Systembibliotheken unterscheiden sich zwischen Maschinen;
• Secrets landen versehentlich im Image oder in Logs;
• es gibt keine klaren CPU-/Memory-Limits, dadurch kommt es zu OOMKill;
• es gibt keine Readiness-/Health-Checks, und Traffic geht auf eine "ungesunde" Instanz;
• Rollout und Rollback werden manuell und langsam durchgeführt.

Das Ergebnis: Das System wirkt "laufend", verkraftet aber Peaks, Updates und partielle Ausfälle schlecht.

Lösung

Containerizing Agents als explizite operative Schicht für den Agent-Betrieb in Production hinzufügen.

Diese Schicht fixiert:

• ein reproduzierbares Image;
• Runtime-Konfig und Secrets außerhalb des Image;
• Ressourcenlimits und Timeout-Verhalten;
• Health-/Readiness-Checks;
• kontrolliertes Rollout/Rollback.

Analogie: wie ein standardisierter Frachtcontainer.

Wichtig ist nicht nur, was drin ist, sondern auch standardisierte Regeln für Transport, Sicherheit und Prüfungen.

Containerizing Agents macht genauso den Agent-Run in jeder Umgebung vorhersagbar.

Wie Containerizing Agents funktioniert

Containerizing Agents ist eine gesteuerte Schicht zwischen Agent-Code und Ausführungsplattform, die definiert, wie der Agent gebaut, gestartet, geprüft und aktualisiert wird.

Dieser Zyklus reduziert Infrastruktur-Chaos und macht Agent-Verhalten unter Last vorhersagbar.

Im Code sieht es so aus

FROM python:3.12.2-slim AS builder

WORKDIR /build
COPY requirements.lock ./
RUN pip install --no-cache-dir --require-hashes -r requirements.lock --prefix=/install

FROM python:3.12.2-slim AS runner

RUN useradd --create-home --uid 10001 appuser

WORKDIR /app
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

COPY --from=builder /install /usr/local
COPY . .

USER appuser
EXPOSE 8080
CMD ["python", "main.py"]

.dockerignore ist ebenfalls kritisch: meist schließt man .git, __pycache__, .venv, tests, lokale Artefakte und .env aus.

import os


class ContainerizedAgentApp:
    def __init__(self, agent_runtime):
        self.agent_runtime = agent_runtime
        self.max_steps = int(os.getenv("AGENT_MAX_STEPS", "20"))
        self.max_seconds = int(os.getenv("AGENT_MAX_SECONDS", "45"))
        self.max_tool_calls = int(os.getenv("AGENT_MAX_TOOL_CALLS", "10"))

    def run(self, task: str):
        # Die Container-Schicht erzwingt Runtime-Budgets.
        result = self.agent_runtime.run(
            task=task,
            max_steps=self.max_steps,
            max_tool_calls=self.max_tool_calls,
            max_seconds=self.max_seconds,
        )
        return {
            "ok": result.get("ok", False),
            "result": result.get("result"),
            "reason_code": result.get("reason_code", "runtime_unknown"),
        }

    def readiness(self):
        # Prüft, dass der Service bereit ist, Traffic anzunehmen.
        return {"ok": True}

    def liveness(self):
        # Prüft, dass der Prozess nicht hängt.
        return {"ok": True}

So sieht es während der Ausführung aus

Anfrage: "Aktualisiere den Status von 500 Bestellungen und erstelle einen Bericht"

Step 1
Ingress: sendet Traffic nur an ready Container
Agent Container: startet mit Env-Konfig und Runtime-Secrets
Agent Runtime: prüft Budgets (steps/tool_calls/time)

Step 2
Tool Execution Layer: ruft API mit Timeout- und Retry-Policy auf
Observability: schreibt metrics + trace + reason_code

Step 3
Deployment Control: erkennt steigende error-rate
Deployment Control: stoppt Rollout und macht Rollback auf das vorherige Image

Containerizing Agents ändert die Agent-Logik nicht. Es macht sie in einer realen Ausführungsumgebung vorhersagbar.

Wann es passt und wann nicht

Containerizing Agents wird dort benötigt, wo der Agent als Production-Service läuft und Updates sowie Last aushalten muss.

Passt

Passt nicht

In einfachen Szenarien reicht manchmal ein lokaler Run:

result = local_agent.run(task)

Typische Probleme und Ausfälle

Die meisten solcher Ausfälle löst man nicht mit "Docker-Magie", sondern mit klaren operativen Regeln rund um den Container.

Wie es mit anderen Patterns zusammenspielt

Containerizing Agents ist das Infrastruktur-Fundament für den stabilen Betrieb anderer Architektur-Schichten.

• Agent Runtime — Runtime läuft im Container und erhält stabile Limits.
• Tool Execution Layer — Netzwerk- und Timeout-Regeln für Tools werden zusammen mit dem Container-Start definiert.
• Memory Layer — der Container sollte langfristigen Speicher meist nicht lokal halten; der Memory Store sollte extern sein.
• Policy Boundaries — Policy Checks bleiben eine separate Schicht, aber der Container garantiert kontrollierte Ausführung.
• Orchestration Topologies — jeder Agent in einer Topologie läuft häufig als eigener Container-Service.
• Hybrid Workflow Agent — Workflow-Commits und Agent-Schritte lassen sich leichter skalieren, wenn beide in kontrollierten Containern laufen.
• Human-in-the-Loop Architecture — Approval-Services und Agent-Container sollten abgestimmte Timeout/SLA-Werte für einen stabilen Review-Flow haben.

Anders gesagt:

• Containerizing Agents definiert wo und innerhalb welcher Grenzen der Agent läuft
• Andere Architektur-Schichten definieren was der Agent tut und welche Aktionen erlaubt sind

Kurz gesagt

FAQ

Q: Garantiert Containerisierung, dass der Agent nicht abstürzt?
A: Nein. Sie beseitigt nicht alle Fehler, reduziert aber Umgebungschaos stark und vereinfacht Recovery.

Q: Kann ich Secrets im Dockerfile oder Image speichern?
A: Besser nicht. Secrets sollten nur zur Runtime über einen Secrets Manager kommen.

Q: Was ist zuerst wichtiger: Kubernetes oder korrekte Runtime-Limits?
A: Für die meisten Teams sind zuerst Limits, Health Checks und Rollback-Prozess wichtig. Der Orchestrator ersetzt diese Grundregeln nicht.

Q: Kann ich mehrere Agenten in einem Container ausführen?
A: Kannst du, aber Isolation, Metriken und Rollback sind dann oft schwerer zu steuern. Meist ist ein separater Service pro Agent-Rolle einfacher.

Was als Naechstes

Container geben dir eine stabile Umgebung. Als Naechstes hilft es zu sehen, wie du diese Umgebung in Production kontrollierst:

• Production Stack - wie runtime, policy, memory und ops zu einem System werden.
• Multi-Tenant - wie Ressourcen, Daten und Budgets zwischen Kunden isoliert werden.
• Tool Execution Layer - wie Aktionen sicher mit timeout, retry und audit ausgefuehrt werden.
• Human-in-the-Loop Architecture - wo manuelle Freigabe fuer riskante Aktionen noetig ist.