Der schnellste Weg, ein Quartal Engineering zu verschwenden, ist einen Agenten zu bauen, wenn ein Workflow gereicht hätte. Der langsamste Weg, etwas Nützliches zu liefern, ist einen Workflow zu bauen, wenn die Arbeit wirklich einen Agenten verlangt.
Wir haben beides geliefert, und wir haben das Falsche geliefert. Das ist die Form der Frage, die wir uns jetzt stellen, bevor wir irgendeinen Code anfassen.
Workflows sind der Default
Ein Workflow ist eine Reihe von Schritten mit explizitem Branching. Du schreibst die Logik. Das System führt sie jedes Mal gleich aus. Wenn etwas bricht, kannst du auf die Zeile zeigen.
Wenn du die Arbeit als Flussdiagramm beschreiben kannst und das Diagramm nicht peinlich groß ist, baue einen Workflow. Sie sind billiger zu schreiben, billiger zu debuggen, und die Leute, die dich in drei Jahren ersetzen, werden dir danken.
Der Haken: "als Flussdiagramm beschreibbar" verlangt echte
Ehrlichkeit. Ein Diagramm mit 47 Zweigen und vier default-Fällen,
die meistens "frag Sarah" bedeuten, ist kein Workflow — es ist ein
Workflow, der versucht, aus seiner eigenen Haut zu entkommen.
Agenten sind für nicht reduzierbares Urteilen
Du greifst zu einem Agenten, wenn die Arbeit zwei Eigenschaften hat:
- Der Raum der Inputs ist zu groß, um ihn im Voraus aufzuzählen.
- Es gibt eine Urteilsentscheidung in der Schleife, die sich nicht in Regeln komprimieren lässt.
Customer Support ist das klassische Beispiel. Du kannst Regeln für die neunzig offensichtlichen Fälle schreiben. Die anderen zehn Prozent sind der Grund, warum dein Team erschöpft ist. Ein Agent verdient sich seinen Platz in diesen zehn Prozent — und in den neunzig langweiligen wickelst du ihn in einen Workflow.
Die Mitte, die Leute übersehen
Das meiste, was wir bauen, ist weder ein reiner Workflow noch ein reiner Agent. Es ist ein Workflow mit einem kleinen Agenten in einem Schritt: dem Schritt, der Urteil, Retrieval oder Umformulierung verlangt.
Diese Hybridform hat zwei riesige Vorteile:
- Observability bleibt vernünftig. Du kannst immer noch auf die Zeile zeigen, wo es kaputtging. Der Agent entscheidet nicht, was als Nächstes zu tun ist — er entscheidet eine spezifische Sache innerhalb eines bekannten Schritts.
- Du kannst den Agenten später ersetzen. Wenn das Modell besser wird, oder wenn dein Urteil sich in Regeln komprimiert, tauschst du den Schritt aus.
Wenn du die Arbeit in einen Workflow zerlegen kannst, in dem der Agent nur ein oder zwei Schritte übernimmt, tu das. Die reine Agent-Schleife ist selten die richtige Antwort.
Die Fragen, die wir zuerst stellen
Wenn ein Team zu uns kommt, gehen wir, bevor wir irgendetwas vorschlagen, durch:
- Kannst du mir die Regeln geben? Wenn ja, ist es ein Workflow. Wenn "naja, kommt drauf an" — sind wir näher an einem Agenten.
- Was kostet eine falsche Antwort? Höhere Kosten bedeuten mehr Guardrails, mehr Human-in-the-Loop, mehr deterministische Form.
- Wie oft ändert sich die Arbeit? Volatile Regeln → Agenten (sie generalisieren). Stabile Regeln → Workflows (sie sind billig zu pflegen).
- Wem gehört es, wenn wir weg sind? Wenn das Team keinen Python-Service warten kann, sollten wir ihnen keinen bauen. Das richtige Werkzeug ist das, das sie an einem Dienstagmorgen am Laufen halten können.
Eine nützliche Heuristik
Wenn du dir ein Notion-Doc vorstellen kannst, das den ganzen Prozess auf weniger als einer Seite beschreibt, ist es ein Workflow.
Wenn der Prozess immer wieder aus dem Doc rutscht — wenn jedes Quartal das Team fragt "moment, machen wir das immer noch so?" — ist ein agentenförmiges Problem darin versteckt. Find es.