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 Aufgaben.
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.
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 transskribiert. Dann passiert etwas Kompliziertes: Das Transkript wird gelesen, eine Zusammenfassung geschrieben, nächste Schritte identifiziert, Events vielleicht im Kalender eingetragen, Erkenntnisse in ACTIONS.md 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.
Aufgaben sind der Mechanismus für echte Delegation. Eine Aufgabe ist ein definierter Ablauf — Trigger, SOP (Standard Operating Procedure), 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.
| Werkzeug | Frage | Fokus | |----------|-------|-------| | Regel | Wie soll der Agent sich verhalten? | Grenzen und Verbote | | Rolle | Wer führt das aus? | Denkschule und Persönlichkeit | | Aufgabe | Welcher Ablauf wiederholt sich? | Mehrstufige Abläufe, als SOP festgeschrieben |
Das Aufgabensystem bootstrappen
Wir folgen dem gleichen Muster wie in Tutorial 2 und 3. Ein Prompt, drei Dinge entstehen: ein Verzeichnis, eine Meta-Regel und ein Index in der KONTEXT.md.
Starte eine neue Konversation in Deinem Cowork-Projekt und gib das hier ein:
Ich möchte ein Aufgabensystem für meine Werkbank einrichten —
den Mechanismus, mit dem mein Agent definierte Abläufe selbstständig
ausführt.
Erstelle diese Struktur in meinem Arbeitsverzeichnis:
Werkbank/Regeln/aufgabensystem.md
Werkbank/Aufgaben/
Falls Werkbank/ schon existiert, leg Aufgaben/ als neuen Unterordner
daneben zu Regeln/ und Rollen/ an. Die aufgabensystem.md kommt zu
den Regeln — weil "Leg eine Aufgabe an" ein getriggertes Verhalten
ist, und das ist per Definition eine Regel. Genau das gleiche Muster
wie bei der rollensystem.md aus Tutorial 3.
Die aufgabensystem.md bekommt diesen Inhalt:
# Aufgabensystem
Aufgaben sind mehrstufige Abläufe mit einem definierten Ergebnis.
Jede Aufgabe lebt als eigene Markdown-Datei in Werkbank/Aufgaben/.
## Struktur einer Aufgabe
Werkbank/Aufgaben/[aufgabenname].md
Jede Aufgabe hat diese Felder:
- **Name:** Wie heißt diese Aufgabe?
- **Trigger:** Wann wird sie ausgelöst? (Schlüsselwörter, Kontexte, zeitliche Auslöser)
- **Rolle (optional):** Welche Rolle führt sie aus? (Nicht jede braucht eine)
- **SOP:** Die konkreten Schritte — was passiert in welcher Reihenfolge? (Nummeriert, präzise)
- **Ergebnis:** Was muss am Ende da sein? (Dateien, Updates, Ausgaben — konkret definiert)
- **Checkliste:** Alle Schritte als Häkchen-Liste zum Überprüfen
## Wenn der Nutzer sagt "Leg eine Aufgabe an"
1. Neues Interview mit dem Nutzer:
- **Was ist der Ablauf?** (Beschreibung in 2-3 Sätzen)
- **Wann wird sie getriggert?** (Kontexte, Worte, Ereignisse, zeitliche Muster)
- **Welche Schritte?** (Detailliert aufzählen, was der Agent nacheinander tun soll)
- **Und dann?** (Was ist das Ergebnis — welche Datei, welche Updates)
- **Braucht eine bestimmte Rolle?** (Optional: Wird eine Rolle aktiviert oder ist es ein generischer Ablauf?)
2. Neue Markdown-Datei in Werkbank/Aufgaben/ anlegen
(Dateiname: [aufgabenname-in-bindestrichen].md)
Aus den Antworten die Aufgabe schreiben (Name, Trigger, Rolle, SOP, Ergebnis, Checkliste).
3. Aufgaben-Index in KONTEXT.md aktualisieren
(Neuer Abschnitt "Aufgaben": Aufgabe | Trigger | Datei)
Alle drei Schritte sind Pflicht. Ohne Index-Update ist die Aufgabe nicht erkennbar.
Zweitens: Erstelle einen Abschnitt "Aufgaben" in meiner KONTEXT.md
mit diesem Inhalt:
## Aufgaben
Aufgaben leben in Werkbank/Aufgaben/. Wenn der Nutzer eine
bestehende Aufgabe triggert (durch Schlüsselwörter oder Kontext),
diese Tabelle prüfen und die Aufgabe ausführen.
Das Anlegen neuer Aufgaben läuft nicht über diese Tabelle,
sondern über aufgabensystem.md im Regelsystem — weil "Leg
eine Aufgabe an" ein getriggertes Verhalten ist und damit
eine Regel.
| Aufgabe | Trigger | Datei |
|---------|---------|-------|
(Die Tabelle füllt sich, wenn der Nutzer Aufgaben anlegt.)
Drittens: Trag die aufgabensystem.md als neue Zeile im bestehenden
**Regelsystem**-Abschnitt der KONTEXT.md ein, mit dem Trigger:
"Aufgabe anlegen", "neue Aufgabe", "Aufgabe erstellen", "Leg eine
Aufgabe an" und der Datei: Werkbank/Regeln/aufgabensystem.md.
Das ist die Maschine. Der Agent wird drei Dinge anlegen: Das Verzeichnis, die Meta-Regel, den Index. Danach — wirklich danach — kannst du echte Aufgaben bauen.
Beachte das Muster, das du schon aus Tutorial 3 kennst: Zwei Mechanismen, sauber getrennt. Das Anlegen einer neuen Aufgabe läuft über eine Regel (die aufgabensystem.md im Regelsystem). Das Ausführen einer bestehenden Aufgabe läuft über den Aufgaben-Index in der KONTEXT.md. Gleiches Muster wie bei Rollen. Erstellen und Ausführen sind zwei verschiedene Dinge, und das System spiegelt das wider.
Der Vorher-Zustand: Wiederholung
Bevor wir eine Aufgabe anlegen, schaust du dir an, warum du sie 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 eine Aufgabe: 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 die Aufgabe an.
Die erste Aufgabe: Meeting-Nachbereitung
Du sagst: "Leg eine Aufgabe an: Meeting-Nachbereitung."
Der Agent fragt zurück:
- "Was ist der Ablauf — was passiert von Anfang bis Ende?"
- "Wann wird diese Aufgabe ausgelöst — nach jedem Kundengespräch, nach Workshops, in bestimmten Kontexten?"
- "Welche konkreten Schritte — Schritt für Schritt bitte."
- "Und das Ergebnis — welche Dateien, welche Updates liegen am Ende vor?"
- "Braucht eine bestimmte Rolle — oder ist es einfach der Standard-Agent?"
Aus Deinen Antworten schreibt der Agent die Aufgaben-Datei. Die Struktur kennst du schon — das sind die Felder aus der aufgabensystem.md oben, jetzt mit Inhalt gefüllt:
# Meeting-Nachbereitung
**Trigger:** "Transkript vom Kundengespräch", "Nachbereitung",
oder Kontext: Agent hat ein Meeting transskribiert und es
soll verarbeitet werden.
**Rolle:** Keine (optional: Studio-Manager bei Jakob)
## SOP
1. Transkript durchlesen — Kontext erfassen, Tonalität verstehen
2. Zusammenfassung schreiben — Kernthemen, Erkenntnisse, offene Fragen
3. Nächste Schritte identifizieren — wer muss was tun bis wann
4. ACTIONS.md aktualisieren — falls neue Aufgaben entstanden sind
5. Nachbereitung-Datei speichern unter [Projektname]/nachbereitungen/YYYY-MM-DD-session.md
## Ergebnis
- Fertige Zusammenfassung mit Kernpunkten und nächsten Schritten
- ACTIONS.md aktualisiert (falls zutreffend)
- Nachbereitung archiviert im Projekt-Verzeichnis
## Checkliste
- [ ] Transkript gelesen
- [ ] Zusammenfassung geschrieben
- [ ] Nächste Schritte identifiziert
- [ ] ACTIONS.md aktualisiert
- [ ] Datei gespeichert
Der Agent erstellt das Verzeichnis, schreibt die Datei, aktualisiert den Aufgaben-Index in KONTEXT.md.
Das Wichtige: Keine Magie dabei. Nur die Prozedur, die Du bereits tausendmal erklärt hast — aufgeschrieben, lesbar, maschinell ausführbar.
Eins noch: Diese erste Aufgabe 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 die Aufgabe 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 Aufgaben-Index
- Liest die Aufgaben-Datei
- Sieht SOP und Ergebnis
- Arbeitet die SOP ab, Schritt für Schritt
- Deliveriert das Ergebnis
- 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 Aufgabe 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.
Die zweite Aufgabe: Aufgabe trifft Rolle
Eine Aufgabe kann eine Rolle aufrufen. Dort wird es richtig mächtig.
Nimm ein Angebot. Text allein reicht nicht — es braucht Rahmung, Überzeugung, Tonalität. Also baust du eine Aufgabe, die deinen Verkaufspsychologen (aus Tutorial 3) aktiviert und durch die Struktur führt: Problem → Aha-Moment → Lösung → Beweis → Call-to-Action.
Anlegen läuft wie oben: "Leg eine Aufgabe an: Angebot vorbereiten." Im Feld Rolle trägt der Agent "Verkaufspsychologe" ein, in der SOP steht als erster Schritt "Verkaufspsychologe laden".
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 die Aufgabe, aktiviert den Verkaufspsychologen (weil die Aufgabe ihn anfordert), arbeitet durch die SOP mit dieser Denkschule, liefert den Draft.
Regeln, Rollen und Aufgaben greifen jetzt zusammen. Die Aufgabe sagt, was passiert. Die Rolle sagt, wie es passiert. Die Regeln sagen, wo die Grenzen sind.
Was nicht zur Aufgabe wird
Nicht jeder Ablauf verdient eine Aufgabe. Einmalige Projekte brauchen keine. Kreative Arbeit ohne klare Schritte auch nicht. Und manche Prozesse wirst du dreimal durchlaufen und dann nie wieder — eine Aufgabe 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. Aufgaben sind für das, was wirklich wiederkehrt — nicht für jedes kleine Ritual.
Was Du jetzt hast
Die Verzeichnisstruktur Deiner Werkbank sieht jetzt so aus:
berger+partner/
├── KONTEXT.md
│ (mit Projekt-Index + Regel-Index + Rollen-Index + Aufgaben-Index)
├── Werkbank/
│ ├── Regeln/ # Meta-Regeln: was getriggert wird
│ │ ├── regelsystem.md
│ │ ├── rollensystem.md
│ │ ├── aufgabensystem.md # Regel zum Anlegen neuer Aufgaben
│ │ └── ...
│ ├── Rollen/ # Denkschulen
│ │ ├── Sparringspartner/
│ │ │ └── SYSTEM.md
│ │ └── Verkaufspsychologe/
│ │ └── SYSTEM.md
│ └── Aufgaben/ # Ausführbare Abläufe (SOPs)
│ ├── 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 eine Aufgabe an: [Name]" — und der Agent startet ein Interview, schreibt die Aufgabe, aktualisiert den Index.
"Führe [Aufgabenname] aus" — und der Agent arbeitet eine komplexe Prozedur ab, ohne dich eine einzige Frage zu stellen.
Ein Wort zur Pflege
Aufgaben akkumulieren. Das ist gewollt. Gleichzeitig veralten sie. Eine Kundenprozedur ändert sich. Eine Rolle wird hinzugefügt, weil der Agent jetzt anders denken soll. Eine Aufgabe wurde einmal übernommen, ist aber jetzt obsolet.
Das ist normal. Und ab einer gewissen Menge (sagen wir: zehn, zwanzig Aufgaben) lohnt sich eine Wartung. Starte eine Konversation und sag: "Schau Dir alle meine Aufgaben 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 zeitaufwendige Sache, aber klar.
Selten wirst du eine Aufgabe löschen. Aber immer wieder aktualisieren — einen neuen Schritt hinzufügen, eine Rolle anpassen, das Ergebnis präzisieren. Das ist wie eine gute Prozedurdokumentation: Sie wird lebend gepflegt, nicht einmal geschrieben und dann vergessen.
Der Anschluss: Konnektoren
Mit Regeln, Rollen und Aufgaben 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 Aufgaben 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. Aufgaben werden handlungsmächtig.
Die Werkbank bleibt offline und privat. Aber sie bekommt Fenster zur Welt.
Stay Mindful
Jakob 🙏
