KI-Workflows per Keyword: Wie wir wiederkehrende Abläufe erzwingbar machen

Wenn man jeden Tag mit KI arbeitet, merkt man schnell, dass sich bestimmte Abläufe ständig wiederholen. Eine Aufgabe ist fertig, also muss sie dokumentiert werden. Code soll live gehen, also müssen vorher die Tests laufen. Ein Datenbank-Schema ändert sich, also braucht es eine kontrollierte Migration. Lange habe ich diese Abläufe als kleine Anleitungs-Dateien im Projekt liegen gehabt, verstreut über das ganze Repository. Das Problem dabei: Jede dieser Dateien musste man einzeln pflegen, und keine Garantie, dass die KI sich auch wirklich an alle Schritte hält.

Inzwischen läuft das anders. Wir haben die wichtigsten dieser Abläufe als zentrale KI-Workflows per Keyword gebaut. Man tippt ein Stichwort — DEPLOYMENT, RECAP, DB MIGRATION — und das löst einen festen, hinterlegten Ablauf aus. Dieser Beitrag erklärt, wie das funktioniert, warum manche dieser Abläufe aus vielen kleinen Schritten bestehen und andere aus einem einzigen, und vor allem: warum jeder einzelne Schritt „committet” werden muss. Genau das ist nämlich der Kern, der alles zusammenhält.

Was hinter dem Keyword passiert

Die Mechanik ist eigentlich simpel. Hinter jedem Keyword steckt ein Eintrag in einer zentralen Datenbank. Tippt man das Keyword, läuft im Hintergrund eine kleine Schleife: Erst wird das Keyword zu einer Workflow-Kennung aufgelöst, dann holt sich die KI den nächsten Schritt ab, führt ihn aus, reicht das Ergebnis ein — und bekommt daraufhin den übernächsten Schritt. Das geht so weiter, bis der Workflow als abgeschlossen gemeldet wird.

Der entscheidende Unterschied zu früher ist die zentrale Ablage. Statt zehn verstreuter Anleitungs-Dateien gibt es jetzt eine einzige Quelle. Jede KI-Session zieht exakt denselben Stand — kein Auseinanderdriften, kein Nachpflegen an mehreren Stellen. Wer den Ablauf verbessert, verbessert ihn für alle auf einmal.

Der Kern-Mechanismus: jeder Schritt wird committet

Jetzt zum eigentlichen Herzstück. Jeder Workflow besteht aus nummerierten Schritten. Zu jedem Schritt bekommt die KI eine Anweisung und dazu ein festes Antwort-Format. Und sie muss ihr Ergebnis einreichen — wir nennen das „committen” —, und zwar in genau diesem Format, bevor sie überhaupt den nächsten Schritt zu sehen bekommt.

Das klingt nach einer Kleinigkeit, ist aber der ganze Trick. Vier Gründe, warum:

• Es erzwingt, dass jeder Schritt wirklich passiert. Die KI kann keinen Schritt überspringen oder nur oberflächlich abhaken, denn ohne gültigen Commit gibt es den nächsten Schritt schlicht nicht. Sie kommt nicht weiter, wenn sie schummelt.
• Es erzwingt überprüfbare Ergebnisse. Weil jeder Schritt ein festgelegtes Format einhalten muss, bekommt man strukturierte, prüfbare Antworten statt Freitext-Prosa, bei der man nie genau weiß, ob die Arbeit gemacht wurde.
• Es trägt den Kontext sauber weiter. Das eingereichte Ergebnis bleibt in der Session erhalten, und spätere Schritte greifen darauf zu. So wandert das Wissen kontrolliert von Schritt zu Schritt.
• Es ist das Tor für bedingte Schritte. Bei einer Datenbank-Migration etwa läuft der Ausführungs-Schritt nur dann, wenn der vorige Freigabe-Schritt tatsächlich eine echte Freigabe eingereicht hat. Sonst wird das Ausführen automatisch übersprungen. Eine Sicherheitsregel wird damit maschinell erzwungen, statt nur als höfliche Bitte im Text zu stehen.

Warum manche Abläufe viele Schritte haben — und andere nur einen

Nicht jeder Workflow ist gleich gebaut, und das hat einen Grund.

Die mehrstufigen Abläufe sind für Pflicht- und Sicherheits-Sequenzen gedacht, bei denen jeder einzelne Schritt nachweislich passieren muss. Die feine Granularität ist Absicht: Ein Doku-Workflow mit neun Schritten garantiert, dass keiner der neun Aspekte vergessen wird. Beispiele sind die Pflicht-Doku nach einer Aufgabe (9 Schritte), die Datenbank-Migration (8 Schritte) und das Deployment (8 Schritte).

Die einstufigen Abläufe sind dagegen für Einmal-Einschätzungen gedacht, die in einem Rutsch erledigt sind — eine Anweisung, ein Ergebnis-Block, kein ständiges Hin und Her mit Werkzeugen. Dazu gehören Summary, Recap, Triage und das RAG-Update, jeweils mit einem einzigen Schritt.

Die einzelnen Workflows im Überblick

• KIDOKU (9 Schritte) und Pflicht (9 Schritte): Beides sind Doku-Sequenzen nach einer Arbeits-Session beziehungsweise nach einer manuellen Aufgabe. Sie führen sauber durch alles vom Umsetzen über den Architektur-Check und die Verifikation bis zum Arbeits-Log und der Abschluss-Einschätzung. Die Doku-Schritte greifen dabei auf Such- und Schreib-Werkzeuge der Wissensbasis zu, nicht direkt auf die Datenbank.

• DB Migration (8 Schritte): Der Sicherheits-Workflow für Änderungen am Live-Schema. Drei nicht verhandelbare Verteidigungslinien werden maschinell erzwungen: Es darf nur auf einem dedizierten Migrations-Zweig gearbeitet werden, es braucht eine ausdrückliche Freigabe mit konkretem Bezug zum tatsächlichen Befehl, und interaktive Rückfragen werden sofort abgebrochen, damit nichts unbeabsichtigt durchläuft.

Mit dem Keyword für Datenbank-Migrationen haben wir keine Probleme mehr gehabt. Das ist früher öfter mal durcheinandergelaufen, aber seitdem wir das hierüber machen, läuft es einwandfrei.

• Deployment (8 Schritte): Eine Vorflug-Kette aus Typprüfung, Stilprüfung, Tests und Build, dazu eine automatische Reparatur-Schleife und am Ende der Push.

Deployment finde ich persönlich sehr angenehm, weil es so ein Abschicken-und-Vergessen ist. Wir haben einen Git-Haken eingebaut, der gewisse Tests durchführt — alle Typprüfungen, alle echten Tests müssen grün sein, sonst geht kein Push hoch. Ein Arbeiter schaut: Bin ich auf dem richtigen Zweig, habe ich alles drin, laufen alle Tests? Und wenn nein, repariert er die Tests gleich, versucht das Deployment mit Push, und sollte es nochmal einen Fehler geben, behebt er den auch. Wenn man sich sicher ist, dass keine Bugs und keine Merge-Fehler dabei sind, ist das wirklich einfach — sonst ist man immer wieder selbst dran und muss es einzeln prüfen und mit der KI durchgehen. So schickt man es einfach ab, und irgendwann geht es live.

• DB Backup (4 Schritte): Ein Voll-Backup in einem einzigen Lauf — und zwar immer alle drei Artefakte zusammen: ein Abzug der Nutzer-Datenbank, ein Abzug der zentralen Datenbank und alle tatsächlich ausgerollten Server-Funktionen. Nie nur eine Datenbank, das ist bewusst unverhandelbar.

• Summary (1 Schritt): Die Entscheidung über die Session-Übergabe. Die KI schätzt die Lage ein — wie voll ist der Kontext, was ist noch offen — und gibt eine Empfehlung, ob man weitermacht, verdichtet oder in eine neue Session übergibt.

Summary nutze ich vor allem, wenn man anfängt, Themen zu wechseln, oder merkt, die KI-Leistung lässt nach und man will lieber in eine zweite Session rüber — dann hat man einen sauberen Abschluss. Seitdem Opus mit einer Million Kontext im Einsatz ist, ist das relativ selten geworden; die Sessions laufen teils vier-, fünfhunderttausend Tokens lang. Früher wurde es mehr genutzt.

• Recap (1 Schritt): Eine Verständnis-Rückspiegelung des letzten Inputs, bevor die KI loslegt. Sie sagt also erst, wie sie die Aufgabe verstanden hat, und fängt erst dann an.

Recap nutzen wir sehr oft. Einfach damit ich weiß: Hat die KI wirklich verstanden, was das Ziel eigentlich ist? Finde ich immer sehr sinnvoll.

• Triage (1 Schritt): Ein Selbst-Entscheid-Tor. Statt bei jeder Kleinigkeit zurückzufragen, entscheidet die KI umkehrbare Fragen selbst anhand der Projekt-Leitplanken. Nur echte Irreversibles — Daten löschen, Migration, Sicherheit, Breaking Change — eskalieren zurück an den Menschen. Das killt die Frage-Inflation.

• RAG-Update (1 Schritt): Pflegt eine Erkenntnis aus der Session in die bestehende Wissens-Doku ein. Gibt es eine eindeutige Fundstelle, geschieht das direkt; gibt es mehrere, wird zurückgefragt — kein blindes Überschreiben.

• Content Creation (5 Schritte): Verdichtet etwas in der Session Gebautes zu einem Content-Briefing und legt es als Aufgabe in eine Warteschlange. Genau dieser Artikel ist übrigens so entstanden.

Content Creation ist unser neuestes Keyword, und zusammen mit dem RAG-Update nutzt es schon eine ganze Pipeline. Wenn wir was Cooles entwickelt haben, schreibt man direkt „Content Creation” dahinter — dann macht das Werkzeug Vorschläge, an welcher Stelle im System gepostet werden soll: Ist das ein LinkedIn-Beitrag, eher ein Blogbeitrag, oder eine Kombination, dass erst ein Blogbeitrag angelegt und danach automatisch der ganze Ablauf für LinkedIn, Instagram und so weiter ausgelöst wird?

Ein bisschen Technik dahinter

Was das Ganze tragfähig macht, ist die zentrale Ablage in einer einzigen Datenbank statt verstreuter lokaler Anweisungen. Ein neuer Workflow ist dadurch im Grunde nur ein Daten-Eintrag — es braucht keinen eigenen Programmcode pro Ablauf, ein einziger generischer Lader liest sie alle. Die bedingten Schritte werden gegen die bereits eingereichten Ergebnisse früherer Schritte ausgewertet, und die Anweisungen bevorzugen bewusst die Werkzeuge der Wissensbasis gegenüber direktem Datenbank-Zugriff. Direkt an die Datenbank geht es nur dort, wo es inhärent nötig ist — bei Migration und Backup.

Unterm Strich macht das KI-gestützte Routine-Abläufe reproduzierbar, überprüfbar und über alle Sessions hinweg konsistent. Und das ist genau das, was ich von so einem System will.

Fazit

Der eigentliche Gewinn liegt nicht in der Bequemlichkeit eines getippten Stichworts — der liegt in der Verlässlichkeit. Solange ein Ablauf nur als Bitte im Prompt steht, hängt seine Ausführung von der Tagesform der KI ab. Sobald jeder Schritt einzeln committet werden muss, wird aus der Bitte eine erzwingbare Garantie. Genau das hat bei uns ganze Fehlerklassen verschwinden lassen, allen voran die früher chaotischen Datenbank-Migrationen.

Der Ausblick ist klar: Weitere Workflows sind in Arbeit, und vor allem wollen wir die einzelnen Content-Pipelines miteinander verketten — Blog, dann LinkedIn, dann Instagram — zu einem durchgehenden Fluss. Wenn das steht, reicht ein Keyword, und aus einer Erkenntnis wird automatisch ein ganzer Strauß fertiger Beiträge.

Entdecke mehr

Blog

Multi-AI-Orchestrierung ohne API-Kosten: warum dein bestehendes Abo reicht

Headless-Agenten auf dem eigenen Rechner, gespeist aus deinem vorhandenen Abo statt aus einer API-Rechnung — wie boostN viele Modelle orchestriert.

Glossar

Ensemble / Multi-Modell-Orchestrierung

Ensemble bezeichnet das Kombinieren mehrerer bewusst variierter LLM-Läufe oder Modelle, deren Funde sich ergänzen. Multi-Modell-Orchestrierung steuert diese Läufe über Orchestratoren mit Sub-Agenten, sodass die Vereinigung der Ergebnisse größer ist als jeder Einzellauf.

Lexikon

Function Calling / Tool Use

Wie ein LLM Werkzeuge aufruft: Tool-Definition als Schema, Modell wählt Funktion und Argumente, Ergebnis zurück ins Gespräch — der Grundbaustein jedes Agenten.

Themenuebersicht

Arbeiten mit KIWorkflowsKI-KonzepteAgenten