ki-engineeering/14-agents-und-workflows.md

Agents und Workflows

Tools und Contracts stehen (Kapitel 13). Im Planning-Meeting fällt trotzdem das Wort Agent — oft als Synonym für „LLM mit Tools“, manchmal für „Chatbot“, selten für eine spezifizierte Runtime mit Caps. Drei Sprints später: unbegrenzte Loops, unklare State-Lage, Kosten ohne Ceiling, und niemand kann eine Trajectory auditieren.

Die teure Frage ist nicht „Agent: ja/nein?“, sondern: fester Workflow (Pipeline) oder Produkt-Agent (Loop) — und mit welchen Stopps.

Kern in einem Satz: Default ist der feste Workflow (Pipeline im Code) mit LLM-Knoten; ein Produkt-Agent (Modell wählt Schritte in einer Schleife) nur wenn der Pfad echt offen ist — mit Step-/Cost-Caps, Allowlist, State außerhalb des Transcripts, HITL und Trajectory-Eval (agent-readiness.md).

Ladder-Stufe 4 vs. 5 (Kapitel 08). Produkt-Agent ≠ Coding-Agent (ki-praxis): hier Nutzer, Daten und Wirkung im Produkt.

---

Bridge: Klassisches SE → AI Engineering

Klassisches SE	Agents & Workflows …
State Machine / Saga / Workflow-Engine	Pipeline-Graph mit optionalen LLM-Knoten
Orchestrator vs. Worker	Harness orchestriert; Modell plant/formuliert in Limits
Idempotente Steps, Compensation	dieselben Regeln für Tool-Writes im Loop
Circuit breaker / bulkhead	max steps, max cost, kill-switch, timeout
Human approval gates	HITL als First-Class State, nicht Chat-Nachgedanke
Job-Replay / Audit log	Trajectory: steps, tools, decisions, versions
„Smart“ Retry-Logik	bounded Repair; kein unendliches Replan

Die Brücke: Agent-Runtime ist verteilte Workflow-Komplexität plus Non-Determinismus — ohne SE-Disziplin multipliziert ihr nur Chaos.

---

Begriffe (kanonisch)

Begriff	Bedeutung in diesem Buch
Tool-Workflow / Pipeline	Reihenfolge und Verzweigungen primär im Code; Modell an benannten Stationen
Produkt-Agent	Modell wählt in einer Schleife Tools/Schritte bis Ziel, Limit oder Mensch
Trajectory	protokollierte Schrittfolge eines Laufs (für Eval, Audit, Debug)
HITL	Mensch gibt frei, korrigiert oder übernimmt vor riskanter Wirkung
Coding-Agent	Dev-Harness zum Software-Bauen — orthogonal; nicht 1:1 kopieren

Pipeline:   [A] → [LLM?] → [B] → [LLM?] → [C]     Code besitzt den Graphen
Agent:      [LLM ⇄ Tools]*  until stop               Code besitzt Caps & Policy

Beide brauchen Tools-Contracts. Der Unterschied ist wer den nächsten Schritt wählt.

---

Wann Pipeline — wann Agent?

Pipeline ist besser, wenn

• Ablauf bekannt (Onboarding, Triage→Draft→Approve→Write)
• strenge Kosten-/Latency-SLOs
• Audit: jeder Schritt erklärbar und testbar
• Team noch ohne Agent-Ops-Reife
• Verzweigungen endlich und modellierbar

Agent lohnt eher, wenn

• Schritte nicht a priori festlegbar
• Tool-Wahl stark kontextabhängig über viele Systeme
• HITL akzeptabel oder ohnehin nötig
• Eval für Trajectories existiert (oder verbindlich geplant)
• Scope eng: ein Job-to-be-done, nicht „unser Super-Assistent“

Decision Frame (schnell)

Signal	Tendenz
„Wir kennen die 5 Schritte“	Pipeline
„40 Sonderfälle in if/else“	Scope schneiden oder Agent eng — nicht beides halb
p95 hart interaktiv	Pipeline / wenige Steps
Hohe Write-Risiken	Pipeline + HITL; Agent nur mit Gates
Kein Trajectory-Eval	kein Agent in Prod

Checkliste: agent-readiness.md. Unklar → Pipeline. Agent ist die teurere Runtime (Varianz × Steps × Tokens).

---

Workflow-Patterns (Pipeline)

1. Linear mit Validate

extract → validate → enrich(tool) → draft → present

Klassiker für Extraktion und Assistenz ohne offene Planung.

2. Branch im Code

Feature-Flags, Business-Rules und Risk-Scores wählen den Pfad; LLM füllt nur Knoten.

3. Map-Reduce light

Viele Items: parallel billige Knoten, dann Aggregate — Caps pro Item.

4. HITL-Gate

Vor Write/External: State awaiting_approval; Timeout und Default-Deny.

State

State lebt außerhalb des Chat-Transcripts: Workflow-DB, Ticket-Status, Saga-Log. Transcript/Memory sind Inputs, nicht Source of Truth (Kapitel 10).

---

Produkt-Agent: Runtime-Minimalgerüst

Wenn Agent, dann als explizite Runtime, nicht als Prompt „denk nach und handle“.

state = init(goal, budget)
loop:
  if steps >= max_steps or cost >= max_cost or timeout: stop(degraded|human)
  if needs_hitl(state): wait_or_abort()
  observation = view(state)          # kuratierter Context
  action = model.propose(observation, allowlisted_tools)
  action = policy.check(action)      # schema, authz, side-effect
  if deny: feedback → continue
  result = execute(action)           # idempotent wo write
  state = update(state, result)
  audit.append(...)
  if goal_reached(state): stop(success)

Caps (nicht verhandelbar in Prod)

Cap	Zweck
max_steps	Loop-Bremse
max_cost / token budget	Unit Economics
wall-clock timeout	UX und On-Call
tool allowlist	Blast Radius
max writes / max external	Wirkung deckeln
kill-switch / feature flag	Incident

Ohne Caps ist „Agent“ ein Cost- und Safety-Spike mit Demo-Charme.

Stop-Bedingungen

Erfolg, Refuse, Budget, Policy-Block, User-Cancel, HITL-Timeout, unrecoverable tool errors. Degraded mode in der Spec: was sieht der Nutzer, wenn der Loop stirbt?

Replan vs. thrash

Wiederholte gleiche Tool-Fails → Circuit öffnen, eskalieren, nicht 15× denselben Call. Harness zählt Duplicates.

---

Human-in-the-loop

HITL ist Pattern, nicht Schwäche:

Stufe	Beispiel
Soft	Nutzer sieht Entwurf, kann senden
Hard gate	ohne Approve kein Tool-Write
Async review	Queue, SLA, Eskalation
Pair	Mensch wählt Optionen, Modell formuliert

Produktfrage: wer haftet bei Fehler — und sieht der Mensch genug Context (Diff, Evidenz, Tool-Plan), um zu entscheiden?

---

Eval für Workflows und Agents

Objekt	Pipeline	Agent
Knoten	Golden Sets pro LLM-Knoten	zusätzlich Tool-Wahl-Qualität
Graph	Integrationstests der State-Machine	Trajectory-Success, Step-Histogramme
Safety	policy an Gates	policy an jeder Action
Regressions	Prompt/Model pin pro Knoten	pin + max_steps-Verhalten

Metriken: Task Success, steps_p50/p95, €/success, hitl_rate, tool_error_rate, loop_abort_rate, unsafe_attempt_rate (blockiert). Ohne Trajectory-Logging kein Agent-Ops.

Methodik: Kapitel 17.

---

Patterns und Trade-offs

Pattern: Pipeline first, agent later

Ship den bekannten Graphen; öffne nur den Teil-Loop, der messbar explodiert.

Trade-off: weniger Keynote-Glanz; höhere Ship-Wahrscheinlichkeit.

Pattern: Agent als Ausnahme-Pfad

80 % Cascade/Pipeline, 20 % Agent mit Strong-Tier und engen Tools (Kapitel 09).

Trade-off: zwei Runtimes; klarere Unit Economics.

Pattern: Plan-then-execute

Erst strukturierter Plan (validate), dann Execute-Schritte mit Caps — Plan sichtbar für HITL.

Trade-off: Extra-Latenz; bessere Auditierbarkeit.

Pattern: Typed state, thin transcript

State-Objekt mit Feldern; Memory-Summary statt voller History im Loop.

Trade-off: Mapping-Aufwand; stabile Loops und weniger Injection aus Altlast-Chat.

Decision Frame: Scope des Agents

Zu breit	Besser
„Alles im Workspace“	ein Job: z. B. „Refund-Vorbereitung“
30 Tools	5–10 allowlisted
unbegrenzte Web-Suche + Write	read-only research oder write mit HITL, getrennt

Trade-off: Flexibilität vs. Steuerbarkeit

Mehr Agent	Mehr Pipeline
offene Pfade	vorhersagbare Kosten/Latenz
schwerer e2e zu evalen	Knoten-evalbar
größere Abuse-Fläche	kleinere Oberfläche
beeindruckt in Demos	überlebt On-Call

Wähle Steuerbarkeit, bis Evidenz Flexibilität erzwingt (T5, T6).

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
Agent by Default	jedes Feature „ist ein Agent“	Pipeline; Readiness-Check
Chat als State Machine	Business-State nur im Transcript	externes State
Unbegrenzter Loop	steps ohne Cap	max_steps/cost/timeout
Coding-Agent-Kopie	Dev-Shell-Tooling im Produkt	Produkt-Threat-Model
Plan nur im Prompt	„erst planen“ ohne Enforce	structured plan + validate
HITL-Theater	Approve-Button ohne Diff/Risk	kontextreiche Freigabe
Tool-Spaghetti	Agent umgeht defekte APIs mit Workarounds	Adapter und Contracts fixen
Eval = Happy Transcript	ein Demo-Pfad	Trajectory-Set inkl. Fails
Silent degradation	Abbruch → leere 200	degraded UX spezifiziert
Ein Agent für die Firma	unendliche Failure Surface	enge Capabilities

---

Production Notes

Cost. Steps multiplizieren Tokens und Tool-€. Histogramme und Caps in der Spec-Envelope; Alerts auf step_count und €/session (T7).

Latency. Interaktive Agents brauchen harte Timeouts oder async Jobs mit Status-API. Streaming der Zwischenstände ändert UX, nicht die Step-Rechnung.

Observability. Trajectory-ID, step index, action type, tool_name, policy decision, budgets remaining, prompt/model versions. Ohne das sind „Agent-Bugs“ Mythen. Minimum: observability-minimum.md.

Security. Größere Tool-Oberfläche + Loop = größere Injection- und Abuse-Fläche. Allowlist, least privilege, HITL auf high side effects, kill-switch (Kapitel 19).

Lifecycle. Agent-Policy (Caps, Tools, Prompts) versionieren wie Code. Model-Update ändert Tool-Wahl — Canary auf Task Success und step stats (T9). Owner für Runtime und für Tool-Allowlist (T10).

---

Key Takeaways

• Pipeline default, Agent Ausnahme — wer den nächsten Schritt wählt, definiert die Runtime.
• Produkt-Agent braucht Caps, Allowlist, externes State, HITL-Policy und Trajectory-Eval.
• State und Audit leben nicht im Chat-Log.
• HITL ist First-Class Pattern bei Wirkung und Risiko.
• Coding-Agents (ki-praxis) nicht 1:1 ins Produkt kopieren.
• Readiness: agent-readiness.md; Tools: Kapitel 13.

Praktische nächste Schritte

1. Zeichne euer Feature als Graph: welche Knoten müssen LLM sein, welche Code/Tools?
2. Geh agent-readiness.md ehrlich durch — bei Nein-Pipeline bleiben.
3. Wenn Agent: setze max_steps, max_cost, Allowlist und kill-switch vor dem ersten Prod-Traffic.
4. Spezifiziere HITL-Gates und Degraded Mode in der Feature-Spec.
5. Logge Trajectories (redacted) und definiere 10 Fail-Trajectories für Regression.
6. Plateau bei Format/Kosten trotz stabiler Pipeline? Erst dann Fine-Tuning und Distillation — nicht als Agent-Ersatz.