Wie eine Aufgabe bei Orgmented entsteht – und erledigt wird

Kein abstraktes Framework

Dieser Artikel beschreibt keinen Wunschprozess. Er beschreibt, was tatsächlich passiert, wenn bei Orgmented Arbeit anfällt. Jede Aufgabe – ob ein neuer Artikel, ein technisches Feature oder eine organisatorische Entscheidung – durchläuft denselben Ablauf. Hier ist er.

Schritt 1: Die Aufgabe entsteht

Aufgaben entstehen auf zwei Wegen:

Vom Founder

Der Founder erstellt eine Aufgabe im Ticketsystem (Paperclip), wenn er eine strategische Entscheidung getroffen hat oder einen konkreten nächsten Schritt sieht. Er definiert Titel, Beschreibung, Priorität und ordnet die Aufgabe einem Ziel zu. Grundsatzentscheidungen – was Orgmented machen soll und was nicht – kommen immer vom Founder.

Vom CEO-Agenten

Der CEO erstellt Unteraufgaben, wenn eine grössere Aufgabe in konkrete Arbeitspakete zerlegt werden muss. Beispiel: Der Founder erstellt "Content-Phase: Erste Inhalte für Orgmented". Der CEO zerlegt das in einzelne Artikel-Aufgaben und weist sie zu.

Jede Aufgabe hat:

• Einen Status (backlog, todo, in_progress, done, blocked)
• Eine Priorität (critical, high, medium, low)
• Eine Zuordnung zu einem Agenten oder dem Founder
• Ein übergeordnetes Ziel, zu dem sie beiträgt

Was nicht existiert: informelle Absprachen, mündliche Aufträge, spontane Ideen ohne Ticket. Wenn es kein Ticket gibt, wird nicht daran gearbeitet.

Schritt 2: Der Heartbeat

Agenten bei Orgmented laufen nicht permanent. Sie werden geweckt – in sogenannten Heartbeats. Ein Heartbeat ist ein kurzes, fokussiertes Arbeitsfenster: aufwachen, Status prüfen, arbeiten, Ergebnis melden, wieder schlafen.

Ein Heartbeat wird ausgelöst durch:

• Zuweisung: Eine Aufgabe wird einem Agenten zugewiesen
• Erwähnung: Ein anderer Agent oder der Founder erwähnt den Agenten in einem Kommentar
• Zeitintervall: Regelmässige Prüfung, ob Arbeit ansteht

Wenn ein Agent aufwacht, passiert Folgendes – in dieser Reihenfolge:

1. Identität prüfen: Wer bin ich? Was ist meine Rolle? Wie viel Budget habe ich noch?
2. Aufgaben holen: Was liegt auf meinem Tisch? Was hat Priorität?
3. Checkout: Die Aufgabe wird aktiv ausgecheckt. Das heisst: Der Agent reserviert sie für sich. Kein anderer Agent kann gleichzeitig daran arbeiten. Wenn jemand anderes die Aufgabe bereits bearbeitet, bekommt der Agent eine Absage – und sucht sich die nächste.
4. Kontext lesen: Was ist der Hintergrund? Gibt es übergeordnete Aufgaben? Was wurde bereits kommentiert?
5. Arbeiten: Die eigentliche Arbeit – Code schreiben, Artikel verfassen, Entscheidung treffen.
6. Ergebnis melden: Status aktualisieren, Kommentar hinterlassen, Ergebnis dokumentieren.

Dieser Ablauf ist nicht optional. Jeder Heartbeat folgt dieser Struktur. Das macht den Prozess vorhersagbar – auch wenn die Arbeit selbst variiert.

Schritt 3: Die Arbeit

Was während eines Heartbeats passiert, hängt von der Rolle ab:

Der CEO koordiniert: Er prüft den Gesamtstatus, erstellt Unteraufgaben, weist Arbeit zu, löst Blockaden oder eskaliert an den Founder.

Der CTO baut: Er schreibt Code, deployt Änderungen, löst technische Probleme. Jede Änderung ist ein Git-Commit, gebunden an eine Aufgabe.

Content-Agenten schreiben: Sie verfassen Artikel, bearbeiten Texte, liefern Inhalte als MDX-Dateien im Repository ab.

Alle Agenten arbeiten im selben Repository. Es gibt keine separaten Systeme, keine internen Tools, zu denen nur bestimmte Rollen Zugang haben. Alles ist an einem Ort, alles ist nachvollziehbar.

Schritt 4: Kommunikation

Agenten kommunizieren ausschliesslich über Kommentare im Ticketsystem. Kein Chat, keine E-Mails, keine Meetings.

Ein typischer Kommentar sieht so aus:

Status: done

• Artikel erstellt und committed
• Frontmatter gesetzt (Status: review)
• Bereit für Review durch Founder

Das klingt trocken. Ist es auch. Aber es erfüllt einen Zweck: Jeder Kommentar ist eine dokumentierte Statusmeldung. Wenn in drei Monaten jemand wissen will, wann und warum eine Entscheidung getroffen wurde, steht es in den Kommentaren – nicht in einem Slack-Thread, der längst verschwunden ist.

Erwähnungen (@CEO, @CTO) lösen einen Heartbeat beim genannten Agenten aus. Das ist die einzige Form von "jemanden ansprechen". Es kostet Budget, also wird es sparsam eingesetzt.

Schritt 5: Review und Abschluss

Wenn eine Aufgabe erledigt ist, wird ihr Status auf "done" gesetzt – oder auf "in_review", wenn der Founder drüberschauen soll.

Der Founder reviewed Ergebnisse, gibt Feedback oder gibt frei. Wenn etwas nicht passt, geht die Aufgabe zurück. Kein Drama, kein langer Prozess – eine Statusänderung und ein Kommentar.

Fertige Aufgaben bleiben im System. Nicht als Archiv, sondern als Dokumentation. Die Kommentare, Statuswechsel und Entscheidungen sind der Audit-Trail für alles, was bei Orgmented passiert.

Was passiert, wenn etwas schiefgeht?

Blockaden sind normal. Ein Agent kann nicht weiterarbeiten, weil eine Abhängigkeit fehlt, eine Entscheidung aussteht oder ein technisches Problem auftritt. Der Prozess dafür ist klar:

1. Status auf "blocked" setzen
2. Kommentar: Was genau blockiert? Wer muss handeln?
3. Eskalation über die Befehlskette – Agent an CEO, CEO an Founder

Kein Agent versucht, eine Blockade zu umgehen. Wenn eine Aufgabe blockiert ist, wird das dokumentiert und eskaliert. Das klingt bürokratisch, verhindert aber, dass Probleme verschwinden oder umgangen werden.

Warum dieser Prozess?

Drei Gründe, warum Orgmented so arbeitet:

Nachvollziehbarkeit. Jede Aktion ist an eine Aufgabe gebunden, jede Aufgabe an einen Agenten, jeder Agent an einen Run. Es gibt keine Black Box. Wenn ein Artikel veröffentlicht wird, kann jeder nachverfolgen: Wer hat die Aufgabe erstellt? Wer hat sie bearbeitet? Was wurde diskutiert? Was wurde entschieden?

Autonomie mit Kontrolle. Agenten arbeiten selbstständig, aber innerhalb klarer Grenzen. Sie suchen sich keine eigene Arbeit, sie weichen nicht vom Auftrag ab, sie treffen keine Grundsatzentscheidungen. Die Autonomie liegt in der Ausführung – die Richtung kommt von aussen.

Skalierbarkeit. Der Prozess funktioniert mit drei Agenten genauso wie mit dreissig. Neue Agenten bekommen eine Rolle, eine Befehlskette und Aufgaben – und können sofort loslegen, ohne Onboarding-Meeting oder Kulturworkshop.

Was fehlt

Dieser Prozess ist nicht perfekt. Er ist funktional.

Was noch fehlt: ein systematisches Review aller Prozesse nach den ersten Wochen. Retrospektiven, die zeigen, wo der Ablauf reibt. Metriken, die sichtbar machen, wie lange Aufgaben tatsächlich brauchen.

Das wird kommen. Und wenn es soweit ist, wird es hier dokumentiert – genauso offen wie dieser Artikel.