Snack 12 – Workflow-Patterns: triage → execute → validate → summarize

In der Praxis scheitern Agenten-Systeme selten an „fehlender Intelligenz“, sondern an unzuverlässigen Abläufen: unklare Ziele, falsche Prioritäten, fehlende Checks, und am Ende niemand weiß, was eigentlich passiert ist. Ein robustes, exam-taugliches Standardpattern ist daher: triage → execute → validate → summarize. Du kannst es als minimalen „Produktions-Workflow“ verstehen, der aus einer unscharfen Aufgabe eine überprüfbare, dokumentierte Lieferung macht.

1) Triage (Einordnen, Klären, Planen)

Triage heißt: Was ist wirklich gefragt, wie riskant ist es, und was brauche ich dafür? Typische Schritte:

• **Goal + Constraints extrahieren:** Output-Format, Deadline, Qualitätskriterien, verboten/erlaubt.
• **Ambiguität reduzieren:** 1–3 klärende Fragen stellen oder Annahmen explizit machen.
• **Scope & Zerlegung:** Teilaufgaben identifizieren (z. B. Recherche, Umsetzung, Tests).
• **Risiko/Compliance:** sensible Daten, destructive Actions, Zugriff/Permissions, „human-in-the-loop“.

Exam-Perspektive: Triage zeigt, dass du Governance und Fehlerrisiken aktiv managst (statt blind auszuführen).

2) Execute (Deterministisch liefern, nicht improvisieren)

Execute ist die eigentliche Arbeit – aber mit einem Fokus auf Reproduzierbarkeit:

• **Tool-first, nicht Text-first:** Wenn ein Tool die Wahrheit liefern kann (API, Datenbank, Tests), nutze es.
• **Idempotenz & Zwischenschritte:** in kleinen, überprüfbaren Schritten arbeiten (z. B. erst Dry-Run, dann Apply).
• **State-Management:** welche Inputs/Artefakte wurden genutzt? (Dateien, URLs, Parameter)
• **Fehlerbehandlung:** klare Retry-Strategie (wann wiederholen, wann eskalieren), Timeouts, Fallbacks.

Wichtig: Execute ohne Triage führt zu „busy work“; Execute ohne Validate führt zu Halluzinations- oder Integrationsfehlern.

3) Validate (Beweise statt Behauptungen)

Validate ist der Schritt, der aus „klingt gut“ ein prüfbares Ergebnis macht:

• **Output-Validation:** entspricht der Output dem gewünschten Format? (Schema/Checkliste)
• **Reality-Checks:** existiert das Artefakt wirklich? (Datei vorhanden, API-Response ok, Tests grün)
• **Edge-Cases:** Off-by-one, leere Inputs, fehlende Berechtigungen, Rate Limits.
• **Policy-Checks:** keine Secrets geleakt, least-privilege eingehalten, keine unerlaubten Nebenwirkungen.

In Agentic-Architekturen ist Validate oft ein eigener „Evaluator“-Pass (auch mit separatem Prompt/Modell), um Selbstbestätigung zu reduzieren.

4) Summarize (Handoff + Audit Trail)

Summarize ist nicht „netter Abschluss“, sondern Operations-Interface:

• **Was wurde getan?** (kurz, bullet-proof)
• **Welche Quellen/Inputs?** (Artefakte, Parameter)
• **Was ist der Status?** (done / partial / blocked)
• **Nächste Schritte & Risiken:** was bleibt offen, was sollte ein Mensch entscheiden?

Damit werden Handoffs an Menschen oder andere Agenten möglich – und du bekommst Auditability.

3 Takeaways

1. Triage reduziert Ambiguität und entscheidet über Risiko, Scope und Human-in-the-loop.

2. Validate liefert Beweise (Checks/Tests/API-Responses) statt „klingt plausibel“.

3. Summarize macht das Ergebnis operierbar: Status, Artefakte, Entscheidungen, nächste Schritte.

Mini-Testfrage

Du baust einen Agenten, der automatisch Änderungen in einem Repo umsetzt. In den Logs sieht man oft „Change applied“, aber später stellt sich heraus, dass der Patch nicht committed wurde oder Tests fehlschlagen. In welchem Workflow-Schritt liegt die primäre Lücke – und wie würdest du sie konkret schließen?

Lösung

Die Lücke liegt in Validate (und teilweise in Summarize). Schließe sie durch deterministische Checks: `git status`/`git diff`, Commit-Existenz verifizieren, CI/Testlauf lokal oder via Pipeline triggern und das Ergebnis als Beweis in der Zusammenfassung ausgeben. Summarize sollte den finalen Status (committed? tests green?) explizit reporten, nicht nur „applied“.