LLM Agents vs Workflows (Production-Vergleich) + Code

Problem (aus der Praxis)

Du hast eine Aufgabe: “Support-Tickets bearbeiten”, “Alerts triagen”, “Leads enrichen”, “Code reviewen”.

Jemand schlägt einen Agent vor. Jemand anders einen Workflow.

In der Demo gewinnt der Agent. In Production gewinnt meistens: das Ding, das du betreiben kannst.

Der teuerste Fehler: Agent wählen, obwohl ein Workflow reicht — und dann Governance draufkleben, bis es eh ein Workflow ist. Nur mit mehr Varianz.

Schnelle Entscheidung (wer sollte was wählen)

• Workflow, wenn du Schritte, Inputs und Erfolgskriterien definieren kannst. Du shippst schneller und schläfst besser.
• Agent, wenn die Umgebung messy ist (unknown Docs, noisy Tools) und du nicht alle Pfade enumerieren kannst — aber nur mit Budgets/Permissions/Monitoring.
• Ohne Control Layer: kein Agent.

Warum man in Prod die falsche Wahl trifft

1) “Flexibel” ≠ “zuverlässig”

Agents sind flexibel. Zuverlässigkeit kommt von:

• Budgets
• Validierung
• Idempotency
• Approvals
• Monitoring

Ohne das sind Agents flexibel im Erzeugen von Incidents.

2) Governance-Kosten werden unterschätzt

Erster Loop → Step Limits. Erstes Tool-Spam → Tool Budgets. Erster falscher Write → Approvals.

Und plötzlich ist es ein Workflow… nur nondeterministisch.

3) Man startet mit Writes

Write Tools in Woche 1 sind ein planbarer Prod-Fail. Start read-only.

Vergleichstabelle

| Kriterium | Workflow | LLM Agent | Was zählt in Prod | |---|---|---|---| | Determinismus | Hoch | Niedrig/mittel | Replay + Tests | | Failure Handling | Explizit | Emergent | Stop Reasons | | Observability | Einfacher | Absichtlich bauen | “Was hat er getan?” | | Kosten | Predictable | Budgets nötig | Spend spikes | | Change Safety | Standard | Drift-prone | Canary + golden tasks | | Best for | Known paths | Unknown paths | Realität matchen |

Wo das in Production bricht

Workflow bricht laut (Step error). Agent bricht leise (langsamer, teurer, weirder).

Das ist Drift.

Implementierungsbeispiel (echter Code)

Framework-egal: Boundary zählt. Tool Gateway + Budgets + Stop Reasons funktionieren für beides.

from dataclasses import dataclass
from typing import Any


@dataclass(frozen=True)
class Budgets:
  max_steps: int = 25
  max_tool_calls: int = 12


class Stop(RuntimeError):
  def __init__(self, reason: str):
      super().__init__(reason)
      self.reason = reason


class ToolGateway:
  def __init__(self, *, allow: set[str]):
      self.allow = allow
      self.calls = 0

  def call(self, tool: str, args: dict[str, Any], *, budgets: Budgets) -> Any:
      self.calls += 1
      if self.calls > budgets.max_tool_calls:
          raise Stop("max_tool_calls")
      if tool not in self.allow:
          raise Stop(f"tool_denied:{tool}")
      return tool_impl(tool, args=args)  # (pseudo)

export class Stop extends Error {
constructor(reason) {
  super(reason);
  this.reason = reason;
}
}

export class ToolGateway {
constructor({ allow = [] } = {}) {
  this.allow = new Set(allow);
  this.calls = 0;
}

call(tool, args, { budgets }) {
  this.calls += 1;
  if (this.calls > budgets.maxToolCalls) throw new Stop("max_tool_calls");
  if (!this.allow.has(tool)) throw new Stop("tool_denied:" + tool);
  return toolImpl(tool, { args }); // (pseudo)
}
}

Echter Incident (mit Zahlen)

Ein Team hat einen simplen Workflow durch einen Agent ersetzt “für Flexibilität”. Der Agent fing an zu browsen “weil vielleicht hilft’s”.

Impact in Woche 1:

• p95 latency: 1,9s → 9,7s
• spend: +$640 vs baseline
• Debugging war schwerer, weil Verhalten nicht deterministisch war

Fix:

1. 80% zurück in Workflow (happy path)
2. Agent nur als bounded “Investigation Step”
3. Writes nur mit Approval

Hybrid gewinnt oft: Workflow für known path, Agent für messy edge.

Migrationspfad (A → B)

• Workflow → Agent: Agent nur für Subtasks, Governance zuerst, Canary + golden tasks.
• Agent → Workflow: common path extrahieren, deterministic steps bauen, Agent nur für Exceptions.

Entscheidungshilfe

• Wenn du eine State Machine schreiben kannst → Workflow.
• Wenn nicht, aber bounded und low-stakes → Agent (mit Guardrails).
• Wenn high-stakes → Workflow + Approvals oder nicht automatisieren.

Abwägungen

• Workflows weniger flexibel.
• Agents brauchen Governance.
• Hybrid ist komplexer, aber oft weniger Incidents.

Wann du es NICHT nutzen solltest

• Keine Agents für irreversible Writes ohne Approvals.
• Keine Agents, wenn Steps bekannt und crisp sind.
• Keine Workflows, wenn Input-Space zu offen ist (sonst baust du einen schlechten Agent).

Checkliste (Copy/Paste)

• [ ] Steps enumerierbar? Dann Workflow.
• [ ] Agent → Budgets + Tool Gateway zuerst.
• [ ] Read-only start; Writes mit Approvals.
• [ ] Stop Reasons (keine silent timeouts).
• [ ] Monitor tool calls, tokens, latency, stop reasons.
• [ ] Canary Changes; Drift ist real.

Sicheres Default-Config-Snippet (JSON/YAML)

mode:
  default: "workflow"
  agent_for_exceptions: true
budgets:
  max_steps: 25
  max_tool_calls: 12
  max_seconds: 60
tools:
  allow: ["kb.read", "search.read", "http.get"]
writes:
  require_approval: true
monitoring:
  track: ["tool_calls_per_run", "tokens_per_request", "latency_p95", "stop_reason"]

FAQ (3–5)

Q: Kann man Agents ohne Tool Gateway nutzen?
A: Wenn es keine Tools und keine Side Effects gibt, vielleicht. Sobald Tools da sind: Gateway als Policy Choke Point.

Q: Was ist der sicherste Hybrid?
A: Workflow für happy path, bounded Agent für Investigation, Approvals für Writes.

Q: Warum driften Agents mehr?
A: Model/Prompt/Tool Änderungen verschieben Entscheidungen. Ohne golden tasks + canary shippst du Regressionen leise.

Q: Welche Metric zuerst?
A: Tool calls/run. Das driftet früh, bevor correctness complaints und bevor die Rechnung kommt.

Verwandte Seiten (3–6 Links)

• Foundations: Workflow vs agent · Planning vs reactive
• Failure: Tool spam loops · Silent drift
• Governance (EN): Budget controls · Tool permissions
• Production stack: Production stack