Ich sitze im Homeoffice. Coaching-Sitzung gerade zu Ende, Transkript liegt vor. Und jetzt erkläre ich wieder — zum dritten Mal diese Woche — welche Schritte passieren müssen.
"Erstell eine Zusammenfassung. Trag das Engagement ein. Update das MANIFEST. Kümmere dich um die Erkenntnisse für den nächsten Termin." Jedes Mal die gleiche Prozedur. Jedes Mal erkläre ich aufs Neue, als hätte der Agent es nie gehört.
Das war der Moment, in dem mir klar wurde: Ich kann Regeln bauen. Ich kann Rollen bauen. Aber ich delegiere immer noch nicht wirklich. Weil der Agent eine Erklärung braucht — jedes Mal.
Das ändert sich heute. Mit Workflows.
Was Du brauchst
Du brauchst Tutorial 1, Tutorial 2 und Tutorial 3. Dein About Me steht. KONTEXT.md liegt im Root. Dein Regelsystem funktioniert. Dein Rollensystem auch — einschließlich Deines Sparringpartners.
Falls nicht: Das ist die Grundlage. Ohne die baut sich das hier auf Sand auf.
Warum noch ein Werkzeug?
Du kennst den Unterschied zwischen Regeln und Rollen mittlerweile. Regeln sagen dem Agenten, was er nicht tun soll — Grenzen. Rollen sagen ihm, wer er ist — eine Denkschule.
Aber keine dieser beiden beschreiben, was der Agent konkret tut. Nicht im Detail. Nicht Schritt für Schritt.
Ein echtes Projekt braucht Abläufe. Du führst ein Kundengespräch. Das wird transkribiert. Dann passiert etwas Kompliziertes: Das Transkript wird gelesen, eine Zusammenfassung geschrieben, nächste Schritte identifiziert, Events vielleicht im Kalender eingetragen, Erkenntnisse dokumentiert, ein Handout generiert. Es ist immer dasselbe. Und jedes Mal erklärst du es aufs Neue. So delegierst du nichts. Du wiederholst dich nur.
Workflows sind der Mechanismus für echte Delegation. Ein Workflow ist ein definierter Ablauf — Trigger, Schritte mit klaren Übergaben, ein definiertes Ergebnis. Einmal formuliert. Ab dann: Dein Agent kennt ihn. Du sagst ein Wort, und der ganze Ablauf läuft ab.
Das ist das dritte Werkzeug. Drei Werkzeuge, drei Fragen:
Regeln fragen: Wie soll der Agent sich verhalten? Sie setzen Grenzen und Verbote.
Rollen fragen: Wer führt das aus? Sie geben dem Agenten eine Denkschule und Persönlichkeit.
Workflows fragen: Welcher Ablauf wiederholt sich? Sie beschreiben mehrstufige Abläufe mit definierten Übergaben und Halte-Punkten.
Bevor es losgeht
Zwei Dinge, bevor Du Deinen ersten Workflow baust.
Die Weiche: Reden oder Ablaufen?
Du hast jetzt Regeln und Rollen. Damit kommt eine Frage, die auf den ersten Blick trivial klingt.
Du hast einen wiederkehrenden Vorgang. "Das will ich mit der Werkbank lösen." Gut. Aber wie genau?
Willst Du damit reden — oder soll das ablaufen?
Reden heißt: Du bringst jedes Mal andere Substanz. Du brauchst ein Gegenüber, das mitdenkt, einordnet, widerspricht. Kein fester Ablauf, kein definiertes Endprodukt. Das Ergebnis ist das Gespräch selbst. "Ich will meine Marketing-Ideen regelmäßig challengen lassen." Das ist eine Rolle.
Ablaufen heißt: Auslöser, feste Schrittfolge, jedes Mal dasselbe definierte Ergebnis. "Nach jedem Kundengespräch soll eine Zusammenfassung mit nächsten Schritten entstehen." Das ist ein Workflow.
Manchmal beides: Ein Ablauf läuft, aber ein Schritt darin braucht echtes Fachurteil. Dann läuft genau dieser Schritt in einer Rolle — der Workflow gibt den Ablauf vor, die Rolle liefert an einer Stelle die Substanz. Dazu gleich mehr.
Die Weiche ist die wichtigste Frage, bevor du irgendetwas baust. Dein Sparringpartner stellt sie dir, wenn du mit einem neuen Vorgang kommst. Aber es hilft, sie selbst im Kopf zu haben.
Dieses Tutorial baut Workflows.
Werkbank-Upgrade
Für Workflows braucht Deine Werkbank ein Upgrade. Die Werkbank-Regel, die Du in Tutorial 2 gebaut hast, kennt Regeln und Rollen. Jetzt kommen Workflows dazu — und dafür brauchst Du die aktuelle Version.
Starte eine neue Konversation in Deinem Cowork-Projekt und gib das hier ein:
Meine Werkbank braucht ein Upgrade für Workflows.
Vier Schritte:
1. Lade die aktuelle Werkbank-Regel herunter:
https://holderbaum.io/werkstatt/bauanleitung/werkbank-regel.md
Ersetze damit die bestehende Datei: Werkbank/Regeln/werkbank.md
2. Erstelle das Verzeichnis Werkbank/Workflows/ falls es noch
nicht existiert. Lade die Workflow-Format-Referenz herunter:
https://holderbaum.io/werkstatt/bauanleitung/format.md
Speichere sie als: Werkbank/Workflows/FORMAT.md
3. Trage die werkbank.md in den Regel-Index Deiner KONTEXT.md
ein:
Werkbank-Regel | 'Mach eine Regel draus', 'Mach das zur
Regel', 'Das soll immer so sein', 'Leg eine Rolle an',
'Leg einen Workflow an', oder Kontext: der Agent wird
korrigiert | Werkbank/Regeln/werkbank.md
4. Erstelle einen Abschnitt "Workflows" in Deiner KONTEXT.md
mit diesem Inhalt:
## Workflows
Workflows leben in Werkbank/Workflows/. Jeder Workflow ist
eine Markdown-Datei im Workflow-Format (definiert in
FORMAT.md). Wenn der Nutzer einen bestehenden Workflow
triggert (durch Schlüsselwörter oder Kontext), diese
Tabelle prüfen und den Workflow ausführen.
| Workflow | Trigger | Datei |
|----------|---------|-------|
(Die Tabelle füllt sich, wenn Workflows angelegt werden.)
Ab jetzt kann Dein Agent Workflows. Die neue Werkbank-Regel ist die zentrale Weiche für alles: Regeln, Rollen und Workflows. Sie erkennt, was Du willst, und routet zum richtigen Ort. Die FORMAT.md beschreibt, wie ein Workflow aufgebaut sein muss.
Zwei Mechanismen, sauber getrennt — dasselbe Muster wie bei Rollen in Tutorial 3:
Anlegen: Du sagst "Leg einen Workflow an" → Die Werkbank-Regel erkennt das und aktiviert Deinen Sparringpartner. Er führt Dich durch ein Interview — vom Ergebnis rückwärts zum Auslöser — und erzeugt den Workflow im richtigen Format.
Ausführen: Du nennst einen Trigger → Der Agent findet ihn im Workflow-Index der KONTEXT.md, liest die Workflow-Datei, arbeitet die Schritte ab.
Erstellen und Ausführen sind zwei verschiedene Dinge, und das System spiegelt das wider. Die Werkbank-Regel dispatcht, der Sparringpartner baut, der Workflow-Index steuert die Ausführung.
Der Vorher-Zustand: Wiederholung
Bevor wir einen Workflow bauen, schaust du dir an, warum du ihn brauchst.
Bei mir: Ein Coaching-Gespräch mit Lisa, einer Klientin. Transkript liegt vor. Die Prozedur ist immer die gleiche. Zusammenfassung → Erkenntnisse extrahieren → Nächste Schritte definieren → In ACTIONS.md dokumentieren → Ggf. ein Handout generieren. Und jedes Mal erkläre ich das.
Bei Lisa von berger+partner — einer 8-köpfigen Agentur in Frankfurt — ist es ähnlich. Nach jedem Kundengespräch: Transkript → Zusammenfassung → drei Key Takeaways → Vereinbarungen überprüfen → in die Projekt-KONTEXT.md eintragen. Auch das jeden Termin neu erklärt.
Das ist das Erkennungszeichen für einen Workflow: Du machst den gleichen Ablauf mehrfach. Du erklärst ihn dem Agenten mehrfach. Du denkst: "Warum erkläre ich das nicht einfach einmal?"
Das ist der Moment. Dort setzt der Workflow an.
Dein erster Workflow: Meeting-Nachbereitung
Du sagst: "Leg einen Workflow an: Meeting-Nachbereitung."
Dein Sparringpartner fängt am Ende an — nicht am Anfang:
- "Was soll am Schluss fertig dasein — welche Datei, welches Dokument?"
- "Und was muss da sein, bevor das entstehen kann?" — Schritt für Schritt rückwärts, bis ihr beim Auslöser seid.
- "Wo willst du draufschauen, bevor etwas rausgeht oder sich nicht mehr rückgängig machen lässt?"
Drei Fragen, rückwärts vom Ergebnis. Aus Deinen Antworten baut der Sparringpartner den Workflow — im Workflow-Format, das er aus der FORMAT.md kennt. Du musst das Format nicht selbst schreiben. Du musst nur die Fragen beantworten.
Das Ergebnis sieht so aus:
---
name: Meeting-Nachbereitung
version: 1
status: aktiv
---
# Meeting-Nachbereitung
Verarbeitet ein Meeting-Transkript zu einer archivierten
Zusammenfassung mit nächsten Schritten.
## Was dein Agent tut
Dein Agent liest das Transkript, schreibt eine Zusammenfassung
mit Kernthemen und nächsten Schritten, und archiviert das
Ergebnis im Projekt-Verzeichnis. Bevor die Datei abgelegt
wird, siehst du sie — nichts wird gespeichert, was du nicht
freigegeben hast.
## Worauf es ankommt
Nächste Schritte müssen konkret sein: wer, was, bis wann.
Keine vagen Absichtserklärungen.
## Trigger
"Nachbereitung", "Transkript verarbeiten", oder Kontext:
ein Meeting-Transkript soll verarbeitet werden.
## Bevor es losgeht
Ein Transkript liegt vor (als Text oder Datei).
## Zonen
- Quelle: Transkript, Projekt-KONTEXT.md
- Kladde: Werkbank/tmp/runs/meeting-nachbereitung-<Zeitstempel>/kladde/
- Ziel: [Projekt]/nachbereitungen/
## Die Schritte
### 1. Transkript erfassen
Liest das Transkript und erfasst Kontext, Teilnehmer,
Kernthemen.
*Anspruch: Handgriff*
- liest: Transkript, Projekt-KONTEXT.md
- schreibt: kladde/rohnotizen.md
Form: Stichpunkte zu Kernthemen, Teilnehmern, offenen Fragen
### 2. Zusammenfassung und nächste Schritte
Destilliert die Rohnotizen zu einer strukturierten
Nachbereitung.
*Anspruch: Urteil*
- liest: kladde/rohnotizen.md
- schreibt: kladde/zusammenfassung.md
Form: Kernthemen, Erkenntnisse, nächste Schritte
(wer | was | bis wann)
### Halt 1 — Zusammenfassung prüfen · DU BIST DRAN
- legt vor: kladde/zusammenfassung.md
- Passt die Zusammenfassung? Stimmen die nächsten Schritte?
### 3. Archivieren
Speichert die freigegebene Zusammenfassung im
Projekt-Verzeichnis.
*Anspruch: Handgriff*
- liest: kladde/zusammenfassung.md
- schreibt: [Projekt]/nachbereitungen/YYYY-MM-DD-session.md
Der Agent erstellt den Workflow, trägt den Trigger im Workflow-Index der KONTEXT.md ein.
Das Wichtige: Keine Magie dabei. Nur die Prozedur, die Du bereits tausendmal erklärt hast — aufgeschrieben, lesbar, maschinell ausführbar. Mit einem Unterschied: Jeder Schritt sagt, was er liest und was er schreibt. Und bevor das Ergebnis gespeichert wird, siehst du es — das ist der Halt.
Dieser erste Workflow kommt aus Deinem echten Arbeitsort. Lisa nimmt ihre Kundengespräch-Nachbereitung, ich meine Coaching-Session-Nachbereitung. Beides ist sofort nützlich — deshalb funktioniert die Übung.
Der Aha-Moment: Ein Satz, der Agent arbeitet
Starte eine neue Konversation. Das ist wichtig — damit der Agent beweist, dass er den Workflow nicht aus dem Gesprächsverlauf kennt, sondern aus der Datei.
Neue Situation. Transkript liegt vor. Du sagst:
Führe die Meeting-Nachbereitung aus.
[Transkript hier reinpasten]
Der Agent:
- Findet den Trigger im Workflow-Index
- Liest den Workflow
- Sieht die Schritte und die Halte
- Arbeitet die Schritte ab, legt dir das Ergebnis am Halt vor
- Archiviert nach deiner Freigabe
- Keine Nachfragen. Keine Umschweife. Nur Arbeit.
Du hattest das Problem — "Ich muss diese Prozedur immer erklären" — gelöst. Mit einem Satz. "Führe die Meeting-Nachbereitung aus." Nichts mehr. Der Agent kennt den Rest.
So fühlt sich Delegation an.
Ich sage dir ehrlich: Das hat bei mir einen Monat gedauert, bis ich es verstanden habe. Ich hatte Regeln. Ich hatte Rollen. Und trotzdem erklärte ich dem Agenten jeden zweiten Tag die gleiche Prozedur, weil ich dachte: "Das ist doch einfach, das merkt er sich beim dritten Mal." Tut er nicht. Nicht, weil er dumm ist. Weil der nächste Chat bei Null anfängt. Das war die bittere Erkenntnis — ich hatte Werkzeuge gebaut, aber das Werkzeug für wiederholte Arbeit gefehlt.
Wenn du merkst, dass du einen Ablauf mehrfach erklärst, legst du ihn als Workflow an. Ab dann: Ein Satz, und dein Agent erledigt die ganze Arbeit — ohne weiteren Input, ohne Fragen, ohne dass du den Ablauf zum vierten, fünften, zehnten Mal erklären musst.
Wenn ein Schritt eine Rolle braucht
Ein Workflow-Schritt kann in einer Rolle laufen. Dort wird es richtig mächtig.
Nimm ein Angebot. Du brauchst Struktur: Kundendaten zusammentragen, Leistung definieren, Preis kalkulieren. Aber der Angebotstext — der braucht mehr als Struktur. Er braucht Rahmung, Überzeugung, Tonalität. Also baust du einen Workflow, in dem ein Schritt deinen Verkaufspsychologen (aus Tutorial 3) aktiviert.
Das Workflow-Format kann das direkt. Ein Schritt trägt Rolle: Verkaufspsychologe, und genau dieser Schritt läuft in dieser Denkschule. Die anderen Schritte bleiben normal. Im fertigen Workflow sieht das zum Beispiel so aus:
### 3. Angebotstext schreiben
Schreibt den überzeugenden Text für das Angebot.
*Anspruch: Fachurteil*
*Rolle: Verkaufspsychologe*
- liest: kladde/leistungsbeschreibung.md, kladde/kundenprofil.md
- schreibt: kladde/angebotstext.md
Form: Problem, Aha-Moment, Lösung, Beweis, Call-to-Action
Später brauchst du nur noch den Satz "Führe 'Angebot vorbereiten' aus" — und den Kontext (Kunde, Thema, Gesprächsverlauf) unten dran. Der Agent findet den Workflow, arbeitet die Schritte ab, aktiviert den Verkaufspsychologen genau dort, wo der Workflow ihn anfordert, und legt dir den Draft am Halt vor.
Regeln, Rollen und Workflows greifen jetzt zusammen. Der Workflow sagt, was passiert. Die Rolle sagt, wie ein bestimmter Schritt denkt. Die Regeln sagen, wo die Grenzen sind.
Was kein Workflow wird
Nicht jeder Ablauf verdient einen Workflow. Einmalige Projekte brauchen keinen. Kreative Arbeit ohne klare Schritte auch nicht — die gehört in eine Rolle. Und manche Prozesse wirst du dreimal durchlaufen und dann nie wieder — einen Workflow dafür zu bauen, ist überengineered.
Die Faustregel: Erklärst du diesen Ablauf zum dritten Mal? Erst dann lohnt sich der Aufwand. Davor: Spontan delegieren und abwarten, ob ein Muster entsteht. Workflows sind für das, was wirklich wiederkehrt — nicht für jedes kleine Ritual. Und denk an die Weiche: Wenn es kein festes Ergebnis gibt, willst du reden, nicht ablaufen.
Was Du jetzt hast
Die Verzeichnisstruktur Deiner Werkbank sieht jetzt so aus:
berger+partner/
├── KONTEXT.md
│ (mit Projekt-Index + Regel-Index + Rollen-Index + Workflow-Index)
├── Werkbank/
│ ├── Regeln/ # Meta-Regeln: was getriggert wird
│ │ ├── werkbank.md # Dispatcht Regeln, Rollen und Workflows
│ │ └── ...
│ ├── Rollen/ # Denkschulen
│ │ ├── Sparringpartner/
│ │ │ └── SYSTEM.md
│ │ └── Verkaufspsychologe/
│ │ └── SYSTEM.md
│ └── Workflows/ # Definierte Abläufe
│ ├── FORMAT.md # Die Grammatik aller Workflows
│ ├── meeting-nachbereitung.md
│ └── angebot-vorbereiten.md
└── [Projektname]/
└── KONTEXT.md
Was da steht, ist ein System. Der Agent kennt jetzt nicht nur, wer Du bist und nach welchen Regeln er spielt. Er weiß auch, welche Abläufe er beherrscht und wie er sie ausführt.
Die mächtige Erkenntnis: Du hast jetzt zwei neue Sätze, die alles können.
"Leg einen Workflow an: [Name]" — und der Sparringpartner startet ein Interview, baut den Workflow, aktualisiert den Index.
"Führe [Workflow-Name] aus" — und der Agent arbeitet einen komplexen Ablauf ab, legt dir das Ergebnis am Halt vor, und archiviert erst nach deiner Freigabe.
Ein Wort zur Pflege
Workflows akkumulieren. Das ist gewollt. Gleichzeitig veralten sie. Eine Kundenprozedur ändert sich. Eine Rolle wird hinzugefügt, weil ein Schritt jetzt anders denken soll. Ein Workflow wurde einmal übernommen, ist aber jetzt obsolet.
Das ist normal. Und ab einer gewissen Menge (sagen wir: zehn, zwanzig Workflows) lohnt sich eine Wartung. Starte eine Konversation und sag: "Schau Dir alle meine Workflows an. Welche sind noch relevant? Gibt es Überschneidungen? Welche könnten kombiniert werden?" Der Agent liest die Dateien, gibt Dir einen Überblick. Du entscheidest. Das sollte alle paar Wochen passieren — keine zeitaufwändige Sache, aber klar.
Selten wirst du einen Workflow löschen. Aber immer wieder aktualisieren — einen Schritt schärfen, eine Rolle an einem Schritt anpassen, einen Halt verschieben. Das ist wie eine gute Prozedurdokumentation: Sie wird lebend gepflegt, nicht einmal geschrieben und dann vergessen.
Und wenn er von allein laufen soll?
Du hast jetzt Workflows, die du von Hand auslöst. Satz, Enter, Ergebnis. Das funktioniert.
Aber manche Workflows haben einen zeitlichen Auslöser. "Jeden Freitag das Controlling-Sheet aktualisieren." "Jeden Abend die offenen Posten prüfen." Die laufen immer gleich — und du willst sie nicht jeden Freitag von Hand anstoßen.
Dafür gibt es einen zeitgesteuerten Auslöser — einen Wecker, der deinen Workflow zu einer festen Zeit anstößt. Der Wecker enthält genau eine Anweisung: "Führe den Workflow X aus." Die gesamte Logik lebt im Workflow, nicht im Wecker.
Aber: Erst wenn der Workflow von Hand läuft und das Ergebnis stimmt. Automatik über einem kaputten Ablauf multipliziert nur den Schaden.
Die Reihenfolge ist nicht verhandelbar: Bauen. Von Hand auslösen. Verifizieren. Erst dann automatisieren. Dein Sparringpartner hilft dir dabei, wenn du soweit bist. Für jetzt reicht es zu wissen: Die Möglichkeit existiert.
Der Anschluss: Konnektoren
Mit Regeln, Rollen und Workflows ist Deine Werkbank jetzt vollständig handlungsfähig. Sie hat Persönlichkeit, Grenzen und die Fähigkeit, repetitive Arbeit selbstständig zu erledigen. Das ist mächtig.
Aber bislang lebt sie auf einer Insel. Sie kennt Dein System — aber die Außenwelt? Deinen Kalender, Deinen Posteingang, Deine Notizen-App, die CRM-Daten bei Deinen Kunden?
Das ist der vierte Teil der Werkbank: Der Anschluss. Im nächsten Tutorial verkabelst Du Deine Workflows mit der Welt. Die Meeting-Nachbereitung schreibt dann nicht nur eine Markdown-Datei, sondern trägt die nächsten Schritte in Deinen Kalender ein. Dein Angebot landet nicht als Draft auf der Festplatte, sondern als fertige E-Mail im Entwurfsordner. Workflows werden handlungsmächtig.
Die Werkbank bleibt offline und privat. Aber sie bekommt Fenster zur Welt.
Stay Mindful
Jakob 🙏
