Jedes Produktteam hat gerade eine Liste mit "Agent-Ideen". Das Problem: Die Liste enthält Dinge, die so unterschiedlich sind wie ein Toaster und ein Kernkraftwerk, aber alle heissen "KI-Agent". Ein Slack-Bot, der Support-Tickets klassifiziert, landet in derselben Priorisierung wie ein autonomer Assistent, der komplexe Geschäftsprozesse orchestriert. Das Ergebnis ist vorhersagbar: Teams over-engineeren einfache Probleme mit Reasoning-Frameworks und unterschätzen die Komplexität echter autonomer Systeme. Hamza Farooq und Jaya Rajwani haben in Lenny's Newsletter ein Framework vorgestellt, das dieses Problem löst.

Drei Kategorien, nicht eine

Das Framework unterscheidet drei Kategorien von KI-Agenten, die sich in Architektur, Aufwand, Team-Anforderungen und Timeline fundamental unterscheiden. Die Kategorie bestimmt, wie du priorisierst, budgetierst und baust.

Kategorie 1: Deterministic Automation. Feste Workflows mit einem LLM-Knoten darin. Wenn X passiert, tue Y, wobei ein Schritt ein LLM-Aufruf ist (Klassifikation, Zusammenfassung, Extraktion). Das ist kein "Agent" im engeren Sinne, weil das System nicht selbst entscheidet, was es als Nächstes tut. Aber es ist der mit Abstand häufigste und wertvollste Anwendungsfall. 60-70% aller "Agent-Ideen" in Product Backlogs sind Kategorie 1.

Kategorie 2: ReAct Agents. Systeme, die auf Basis von Beobachtungen entscheiden, welchen nächsten Schritt sie nehmen. Sie haben Zugriff auf Tools und wählen selbst, welches Tool sie wann einsetzen. Claude Code ist ein Beispiel: Es liest Code, entscheidet, was es ändern muss, schreibt die Änderung, testet, iteriert. Das erfordert Reasoning-Fähigkeiten und ist deutlich komplexer in Entwicklung und Testing als Kategorie 1.

Kategorie 3: Multi-Agent Networks. Mehrere Agenten koordinieren sich, um ein komplexes Ziel zu erreichen. Jeder Agent hat eigene Fähigkeiten und eigenes Wissen. Die Koordination selbst ist das schwierigste Problem. Diese Kategorie ist selten wirklich nötig und fast immer over-engineered, wenn sie zu früh eingesetzt wird.

Wie du triagierst

Die Triage-Frage ist einfach: Kannst du ein Flussdiagramm zeichnen? Wenn ja, ist es Kategorie 1. Baue einen deterministischen Workflow mit n8n oder Zapier, setze ein LLM an die Stellen, wo Klassifikation, Zusammenfassung oder Generierung nötig ist. Fertig. Kein LangGraph, kein Agent-Framework, kein Over-Engineering.

Wenn der Agent selbst entscheiden muss, was er als Nächstes tut (weil der Lösungsweg nicht vorhersagbar ist), ist es Kategorie 2. Das erfordert ein Reasoning-Framework, Tool-Integration und ein deutlich höheres Investment in Testing und Guardrails. Und wenn mehrere solcher Agenten koordiniert werden müssen, bist du in Kategorie 3, dem Enterprise-Bereich mit dediziertem Team und Quartals-Budgets.

Der häufigste Fehler: Teams sehen "Agent" im Backlog und greifen sofort zu LangGraph oder AutoGen. Aber die Idee ist ein Workflow mit einem LLM-Knoten. Das Over-Engineering kostet Wochen, die ein n8n-Workflow in Tagen gelöst hätte.

Anwendung auf eigene Projekte

Das Framework klärt auch die eigene Arbeit. Mamahood-Matching (eine App, die Mütter mit ähnlichen Interessen verbindet) ist Kategorie 1: ein deterministischer Score-Algorithmus, der Kompatibilität berechnet. Ein LLM kann Profiltexte analysieren und Interessen extrahieren, aber der Matching-Prozess selbst ist ein festes Regelwerk. Ein zukünftiger konversationaler Matching-Assistent, der durch Gespräch herausfindet, was eine Mutter sucht, wäre Kategorie 2, weil er selbst entscheidet, welche Fragen er stellt. Mein persönliches KI-Setup (Claude Code mit Skills, CLAUDE.md, Memory) ist ebenfalls Kategorie 2: Claude entscheidet, welche Tools es nutzt und wie es meine Anfragen bearbeitet.

Was ich mir vornehme

Ich möchte meine nächsten PM-Aufgaben mit einem Agenten vorab kategorisieren, bevor ich sie priorisiere. Die erste Frage soll dabei sein: Kann ich ein Flussdiagramm zeichnen? Wenn ja, baue ich einen Workflow (n8n, Zapier) und keinen Agent. Ich bin gespannt, welchen Unterschied dieser Ansatz für eine PM macht und ob ich dadurch auch in meinem Alltag, der ja weniger entwicklungsorientiert ist, wertvolle Zeit spare. Nur wenn der Lösungsweg nicht vorhersagbar ist, möchte ich zu Kategorie-2-Werkzeugen greifen. Kategorie 3 will ich vorerst bewusst vermeiden, weil die Koordinationskosten den Nutzen in meinem Kontext (Einzelperson, kleines Team) vermutlich nicht rechtfertigen.

Kritische Einordnung

Das Framework ist bewusst vereinfachend. In der Praxis dürfte es viele Hybride geben: ein Workflow, der an einer Stelle einen Reasoning-Schritt braucht, oder ein Agent, der 90% seiner Zeit deterministisch arbeitet. Die Grenzen zwischen den Kategorien sind vermutlich fliessender, als das Modell suggeriert, zumal mein Claude-Setup mir auch hilft, die richtigen Schritte zu planen, bevor ich sie ausführe. Ausserdem entwickelt sich die Tool-Landschaft schnell: Was heute ein Kategorie-2-Problem ist, kann morgen durch bessere Modelle zu Kategorie 1 werden. Ob die Triage-Frage ("Kann ich ein Flussdiagramm zeichnen?") in der Praxis wirklich so trennscharf funktioniert, muss sich erst zeigen.