Die meisten Gespräche über AI Agents fangen falsch an. Jemand hat irgendwo gelesen, dass Agents jetzt alles automatisieren, und will einen. Die erste Frage ist dann nie "was soll er tun", sondern "was kann er tun". Das ist der falsche Startpunkt.
Wir bauen bei blynx seit Jahren Automatisierungen. Früher fast alles in n8n, mit festen Abläufen und klaren Regeln. Seit einiger Zeit kommen Agents dazu. Und je mehr wir davon gebaut haben, desto klarer wurde: Ein Agent ist kein besserer Workflow. Er ist etwas anderes. Wer das verwechselt, baut entweder einen Agent wo ein Workflow gereicht hätte, oder einen Workflow wo ein Agent nötig gewesen wäre. Beides kostet.
Damit uns das nicht passiert, arbeiten wir nach einem festen Ablauf. Der ist bewusst einfach gehalten, damit er bei jedem Projekt gleich funktioniert. Hier ist er.
Zuerst die wichtigste Frage: Braucht es überhaupt einen Agent?
Ein Workflow macht immer dasselbe. Trigger kommt rein, Schritt eins, Schritt zwei, Schritt drei, fertig. Vorhersehbar, günstig, stabil. Wenn eine Aufgabe sich in feste Regeln packen lässt, gehört sie in einen Workflow und nicht in einen Agent.
Ein Agent entscheidet selbst, welcher Schritt als nächstes kommt. Er bekommt ein Ziel und Werkzeuge, und wählt den Weg. Das ist dann sinnvoll, wenn der Weg vorher nicht feststeht. Eine E-Mail kann eine Preisanfrage sein, eine Reklamation oder eine Terminverschiebung. Ein fester Ablauf müsste jeden Fall vorher kennen. Ein Agent liest, versteht und wählt.
Die Faustregel bei uns: Solange du den Ablauf als Flussdiagramm zeichnen kannst, ist es ein Workflow. Sobald du an jeder zweiten Verzweigung "kommt darauf an" schreiben müsstest, wird es ein Agent. Diese Entscheidung fällt bei uns immer zuerst. Nicht der Kunde entscheidet das, und auch nicht der Trend. Die Aufgabe entscheidet.
Wir denken dabei nicht in Software, sondern in Arbeit. Ein Agent übernimmt keine Funktion, er übernimmt eine Aufgabe, die heute ein Mensch macht. Die Anrufe an der Réception. Das Einteilen der Monteure. Das Beantworten der immer gleichen Anfragen. Wir suchen bewusst die Arbeit, für die schon heute jemand bezahlt wird. Denn wo Geld fliesst, ist der Schmerz echt und der Nutzen messbar.
Bevor wir bauen: dem Menschen zuschauen
Bevor auch nur eine Zeile entsteht, schauen wir dem Menschen zu, der die Aufgabe heute macht. Zehn bis zwanzig echte Fälle, live, während er laut erklärt, was er tut und warum. Das klingt aufwändig, spart aber die teuersten Fehler.
Denn die eigentliche Arbeit ist selten die, die im Prozesshandbuch steht. Es ist das, was der Mensch nebenbei prüft, ohne darüber nachzudenken. Welche Anfrage er sofort als heikel erkennt. Wo er kurz zögert, weil ein Fall komisch ist. Genau diese versteckten Handgriffe machen später den Unterschied zwischen einem Agent, der im Demo funktioniert, und einem, der im Alltag standhält. Wer diesen Schritt überspringt, baut einen Agent für die Aufgabe, wie man sie sich vorstellt, nicht für die Aufgabe, wie sie wirklich ist.
Das Framework: fünf Phasen
Wenn wir die Aufgabe verstanden haben, arbeiten wir in fünf Phasen. Wir nennen es intern das ZGFTÜ-Modell, was unelegant klingt, aber genau das ist, was ein Agent braucht: Zweck, Grenzen, Fähigkeiten, Test, Überwachung.
1. Zweck
Ein Agent braucht genau eine Aufgabe, die man in einem Satz sagen kann. "Beantwortet eingehende Kundenanfragen per E-Mail und bucht Termine" ist ein Zweck. "Kümmert sich um den Kundenservice" ist keiner. Je breiter der Auftrag, desto unberechenbarer der Agent.
In dieser Phase legen wir auch fest, woran wir Erfolg messen. Nicht "der Agent funktioniert", sondern "acht von zehn Anfragen werden ohne menschliches Eingreifen korrekt beantwortet". Ohne diese Zahl weiss später niemand, ob das Ding gut ist.
2. Grenzen
Das ist die Phase, die am meisten unterschätzt wird und am meisten Ärger spart. Ein Agent, der selbst entscheidet, entscheidet auch mal falsch. Also legen wir vorher fest, was er auf keinen Fall darf.
Er darf keine Rechnungen freigeben. Er darf keine verbindlichen Preise nennen, die nicht in der Preisliste stehen. Bei allem, was er nicht sicher lösen kann, übergibt er an einen Menschen statt zu raten. Diese Grenzen bauen wir nicht als Bitte an das Modell, sondern als harte Regeln drumherum. Ein Agent, dem man vertrauen kann, ist einer, der weiss, wann er aufhören muss.
3. Fähigkeiten
Jetzt bekommt der Agent seine Werkzeuge. Zugriff auf den Kalender, auf die Wissensdatenbank, auf das E-Mail-Postfach. Die Regel hier: so wenig wie möglich. Jedes Werkzeug, das er hat, ist ein Weg, auf dem etwas schiefgehen kann. Ein Agent, der nur lesen soll, bekommt keinen Schreibzugriff.
Dazu kommt das Wissen. Ein Agent ist nur so gut wie das, was er kennt. Preisliste, häufige Fragen, Firmenton, Ausnahmen. Das strukturieren wir vorher sauber, weil ein Agent auf schlechtem Wissen schlechte Antworten gibt, egal wie gut das Modell ist.
Wie viel ein Agent selbst entscheiden darf, hängt vom Vertrauen ab, das er sich verdient hat. Die erste Version ist bei uns fast immer eine von vier Formen, von vorsichtig bis eigenständig. Er schlägt vor und ein Mensch gibt frei. Er sortiert eingehende Fälle und leitet weiter. Er koordiniert zwischen Beteiligten, ohne selbst etwas Verbindliches zu tun. Oder er handelt eigenständig, aber nur innerhalb enger, klar gezogener Grenzen. Wir starten immer mit der vorsichtigsten Form, die die Aufgabe noch sinnvoll löst, und geben mehr Eigenständigkeit erst dazu, wenn er sich im echten Betrieb bewährt hat.
4. Test
Hier trennt sich seriöse Arbeit von Bastelei. Ein Workflow testet man mit ein paar Durchläufen, weil er immer gleich reagiert. Ein Agent nicht. Er kann auf dieselbe Anfrage heute anders antworten als morgen.
Deshalb bauen wir eine feste Sammlung echter Fälle, oft rund fünfzig, und legen für jeden fest, was die richtige Antwort gewesen wäre. Diese Sammlung wird zum Prüfstand. Wir lassen den Agent immer wieder gegen sie antreten, wie gegen ein Fitnessgerät, und sehen sofort, wenn eine Änderung ihn an einer Stelle besser und an einer anderen schlechter macht.
In der Sammlung stecken die einfachen Fälle, die schwierigen und bewusst die gemeinen, mit denen wir ihn aus dem Konzept bringen wollen. Die unklare Anfrage, die freche, die auf halbem Weg das Thema wechselt. Wir schauen nicht nur, ob die Antwort stimmt, sondern ob der Agent den richtigen Weg gewählt hat. Und wir prüfen, ob er seine Grenzen einhält, auch wenn man ihn dazu bringen will, sie zu überschreiten. Erst wenn er diese Sammlung sauber besteht, geht er live.
5. Überwachung
Ein Agent ist nicht fertig, wenn er live ist. Wir loggen, was er tut, welche Entscheidungen er trifft und wo er an einen Menschen übergibt. Aus diesen echten Fällen lernen wir, wo er noch schwächelt, und schärfen nach. Die Fälle, bei denen er falsch lag, wandern zurück in die Testsammlung aus Phase vier. So wird der Agent mit der Zeit besser statt schlechter.
Warum das so aussieht
Der ganze Ablauf hat einen roten Faden: Ein Agent ist umso brauchbarer, je enger sein Zweck und je klarer seine Grenzen sind. Der Reiz eines Agents ist, dass er viel kann. Die Kunst ist, ihm das meiste davon wegzunehmen, bis nur das übrig bleibt, was er wirklich zuverlässig tut.
Das ist auch der Grund, warum wir nicht jeden Auftrag in einen Agent verwandeln. Vieles läuft bei uns weiterhin als Workflow, weil das die stabilere und günstigere Lösung ist. Ein Agent kommt dann zum Einsatz, wenn die Aufgabe echte Entscheidungen verlangt. Diese Ehrlichkeit ist uns wichtiger als das Verkaufen von Buzzwords.
Den ganzen Ablauf zum Mitnehmen
Wir haben diesen Ablauf in eine kompakte Checkliste gepackt. Zwei Seiten, alles zum Abhaken: die Entscheidung Workflow oder Agent, und jede Phase vom Zuschauen bis zur Überwachung. Genau die Liste, die wir intern durchgehen, bevor wir einen Agent für ai-buero.ch bauen. Sie können sie kostenlos herunterladen und für Ihr eigenes Vorhaben nutzen.
Wenn Sie überlegen, ob in Ihrem Betrieb ein Agent Sinn macht oder ob ein einfacher Workflow reicht, schauen Sie einfach mit uns drauf. Wir sagen Ihnen ehrlich, was es braucht.
Kostenlos und unverbindlich · Antwort innerhalb 24h · Aus Lachen SZ
