ChatGPT hat jetzt dein Projektboard im Blick: Was eventgesteuerte Agenten als Nächstes brauchen

Im DevDay-Rückblick von OpenAI vom 29. September wurde das Beispiel auf den Punkt gebracht: „Sie können ChatGPT anweisen, ein Projektboard nach neuen Aufgaben zu überwachen. Sobald eine eintrifft, kann ChatGPT die verlinkten Dokumente lesen und einen Plan entwerfen – selbst wenn Sie gerade abwesend sind.“ Dahinter steckt die Unterstützung von ChatGPT für die vorgeschlagene MCP-Events-Spezifikation in allen Tarifen, die zusammen mit zwei Team-Funktionen eingeführt wurde: Team-Tasks, die nach Zeitplan oder ereignisgesteuert laufen, und @ChatGPT in Slack und Teams.

Für ein Team, das bereits Coding-Agents einsetzt, verändert ein von Agenten überwachtes Board die Bedeutung einer neuen Aufgabe grundlegend. Früher wartete eine Aufgabe auf einen Menschen. Jetzt kann sie einen Agenten aktivieren – oder gleich mehrere. Wenn zwei Personen ChatGPT bitten, dasselbe Board zu überwachen, und dem Board selbst bereits ein Agent für neue Aufgaben zugewiesen ist, kann eine einzige neue Aufgabe drei verschiedene Planentwürfe an drei verschiedenen Stellen erzeugen – und niemand hat festgelegt, welcher davon eigentlich gilt.

TL;DR

MCP Events bietet ChatGPT eine saubere, signierte Möglichkeit, über Änderungen in einer angebundenen App benachrichtigt zu werden, während Team-Tasks in ChatGPT zeitgesteuerte und ereignisbasierte Abläufe in die Business- und Enterprise-Tarife bringen. Einen Agenten durch ein Ereignis zu starten, ist dabei der einfache Teil – und OpenAI hat diesen sorgfältig gelöst. Die eigentliche Herausforderung ist das, was das Ereignis auf dem Board bewirkt: Wer ist für die daraus resultierende Arbeit verantwortlich? Wo landet der Planentwurf? Wie wird er überprüft? Und wie verhindert man, dass zwei Agenten auf dasselbe Ereignis reagieren? Halten Sie das als Routing-Regel fest: ein Ereignistyp, ein Verantwortlicher, Entwürfe, die direkt zum Task zurückgeführt werden, und eine Person, die das Ergebnis abnimmt, bevor etwas als erledigt gilt.

Was auf dem DevDay vorgestellt wurde

MCP Events ist eine vorgeschlagene Erweiterung des Model Context Protocol, mit der ein MCP-Server ChatGPT benachrichtigen kann, wenn in einer angebundenen App etwas passiert, sodass ein Plugin als Reaktion eine Automatisierung anstoßen kann. Der MCP-Events-Leitfaden von OpenAI beschreibt die Serverseite: Der Server signalisiert die Unterstützung von Events und implementiert drei Methoden: events/list, events/subscribe und events/unsubscribe. ChatGPT unterstützt ausschließlich die Webhook-Zustellung – signiert via Standard Webhooks HMAC, nach einer HTTPS-Verifizierungs-Challenge, mit jeweils einem Event pro Anfrage von bis zu 256 KiB. Wenn ein Event eintrifft, heißt es im Leitfaden: „ChatGPT empfängt das Ereignis im abonnierten Chat und folgt den Anweisungen des Nutzers zur Reaktion darauf.“

Die Details sind dort durchdacht, wo es darauf ankommt: Der Server muss jedem Event eine eindeutige ID zuweisen, die auch bei Wiederholungsversuchen unverändert bleibt. Abonnements müssen idempotent sein: Ihre Identität leitet sich aus dem Principal, der Callback-URL, dem Event-Namen und den Argumenten ab. Ein erneutes Abonnieren aktualisiert daher die bestehende Subscription, anstatt ein Duplikat zu erstellen. Zudem muss der Server private und lokale Callback-Adressen blockieren und darf Weiterleitungen nicht folgen.

Zusammen machen diese Neuerungen ChatGPT zu einem Ort, an dem Arbeit auch außerhalb einer direkten Unterhaltung angestoßen werden kann. Das ist ein echter Fortschritt – und für viele wiederkehrende Aufgaben wird das bereits genügen.

Der Trigger ist die leichte Hälfte

Spielt man das Beispiel aus dem Rückblick in einem echten Team durch: Eine neue Aufgabe erscheint auf dem Board. ChatGPT liest die verlinkten Dokumente und entwirft einen Plan. Daraufhin stellen sich vier Fragen – und keine davon dreht sich um das Übertragungsprotokoll.

Wer ist für die resultierende Arbeit zuständig? Ein Planentwurf ist noch keine Zuweisung. Jemand muss die Verantwortung für die beschriebene Aufgabe übernehmen – und in den meisten Teams wird diese Verantwortlichkeit auf dem Board festgehalten: durch einen Namen am Task und einen Status, der sich weiterbewegt. Ein guter Entwurf ändert für sich allein genommen weder das eine noch das andere.

Wo landet der Plan? Das Ereignis trifft in dem Chat ein, der das Abonnement eingerichtet hat, und der Plan landet dort, wohin die Anweisungen dieser Person ihn leiten: als Antwort im Chat oder als Rückmeldung direkt auf dem Board, falls das Plugin dies unterstützt und die Anweisungen es verlangen. Das Team muss wissen, welcher Weg gewählt wird – andernfalls verharrt der Task auf dem Board im Status „Neu“, während ein einwandfreier Plan an einem Ort wartet, den niemand sonst einsehen kann.

Wie wird der Plan überprüft? Ein Plan ist eine Entscheidung über den Projektumfang (Scope). Jemand anderes als der Verfasser sollte ihn prüfen, bevor die Implementierung beginnt – und zwar an einer Stelle, die für die nächste Person leicht auffindbar ist.

Wer reagiert auf das Ereignis? Idempotenz verhindert lediglich, dass ein einzelnes Abonnement sich selbst dupliziert. Sie koordiniert jedoch nicht zwei verschiedene Personen: Da der Principal Teil der Identität des Abonnements ist, existiert für jede Person eine eigenständige Subscription. Weist man auf dem Board zusätzlich noch einen Agenten zu, kann derselbe Task mehrfach geplant werden. Eine Deduplizierung auf Webhook-Ebene löst nicht die Zuständigkeitsfrage auf der Arbeitsebene.

Diese Fragen betreffen das Management. Sie existierten schon vor dem Aufkommen von Agenten – etwa wenn drei Personen versehentlich dasselbe Ticket bearbeiteten –, und sie kehren nun mit noch größerer Dringlichkeit zurück, da der Bearbeiter niemals schläft. Zur Überprüfung unbeaufsichtigter Arbeit siehe Coding-Agents in Abwesenheit.

Das Routing gehört direkt aufs Board

Auf einem Board, auf dem Agenten als Assignees fungieren, wird aus „nach neuen Aufgaben Ausschau halten“ im Grunde „den Task zuweisen“. In Sharkly startet ein einem Agenten zugewiesener Task einen Run, sobald er das Backlog verlässt und Computer sowie Runtime bereitstehen. Der Zuweisungs-Slot für die Ausführung fasst genau einen Agenten oder eine Crew, und Sharkly fasst anstehende Änderungen zusammen, sodass rasch aufeinanderfolgende Kommentare keine doppelten Ausführungen für denselben Agenten und Task auslösen. Zuständigkeit ist hier ein Datenfeld, keine bloße Konvention.

Für Ereignisse, die Arbeit ohne explizite Zuweisung anstoßen sollen, sind Sharkly Automations das boardseitige Gegenstück. Eine Automation besteht aus einer einzigen Regel: Anweisungen, ein Agent oder eine Crew, ein oder mehrere Trigger sowie ein Ausführungsverlauf, mit dem Status „Active“ oder „Paused“. Als Trigger dienen ein Zeitplan (Cron mit Zeitzone), das Verschieben eines Tasks in einen bestimmten Status, ein Kommentar mit einer bestimmten Phrase oder ein Webhook eines externen Dienstes – ergänzt durch „Run now“ zu Testzwecken. Jeder Run startet direkt und speichert seine Historie in der Automation; daher sollten die Anweisungen festlegen, wo das Ergebnis dokumentiert wird. Da der Abgleich von Status und Kommentaren derzeit organisationsweit erfolgt, empfiehlt die Automations-Dokumentation Anweisungen, die den auslösenden Task vor der Ausführung verifizieren.

Hier ist die Event-zu-Task-Tabelle eines beispielhaften Space:

Und die dahinterstehende Regel, festgehalten an einem Ort, an dem das Team darüber diskutieren kann:

Routing rule: new work in the ENG Space

1. One event type, one owner. Each event maps to exactly one
   Automation or one Agent Assignee. Personal watchers (a chat
   subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
   the Backlog category. The "Draft plan" Automation runs the Planner
   Agent, which first checks the Task's Space and type and stops if
   the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
   change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
   Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
   into a Completed status.

Die Einordnung von „Needs plan“ in die Backlog-Kategorie ist das entscheidende Detail, das Schritt 5 absichert: Ein im Backlog zugewiesener Task wartet zunächst, sodass der Plan vor dem Start des Runs geprüft werden kann. Definieren Sie in den Anweisungen des Planners exakt, wohin der Plan geliefert werden soll, und testen Sie dies mit „Run now“, bevor Sie sich auf den Trigger verlassen. Wenn ein Agent mitten im Run eine Entscheidung benötigt, zeigt der Task den Status „Waiting for human reply“ an und landet in der Inbox der zuständigen Person – womit das Versprechen „selbst wenn Sie gerade abwesend sind“ wieder beim Menschen ankommt. Im Task wird aus einer Gruppenchat-Anfrage nachvollziehbare Arbeit, und das Gleiche gilt für ein GitHub-Issue, das einem Agenten zugewiesen wird.

Wo der Watcher von ChatGPT seinen Platz hat

Nutzen Sie ein MCP-Events-Abonnement, wenn eine einzelne Person eine Benachrichtigung und einen ersten Entwurf im eigenen Chat erhalten möchte: etwa für ein Board, das man verfolgt, aber nicht selbst verwaltet, den Tracker eines Partners oder eine Freitagszusammenfassung für den persönlichen Gebrauch. Setzen Sie auf Team-Tasks, wenn es sich um eine wiederkehrende Aufgabe wie ein Team-Update handelt, das direkt in ChatGPT angesiedelt ist und Ihr Team einen Business- oder Enterprise-Tarif nutzt – denn so verfeinern Teammitglieder gemeinsam einen zentralen Regelsatz, anstatt dass jeder eigene Anweisungen verfasst. Verwenden Sie eine boardseitige Regel, wenn das Ereignis Arbeit generiert, für die das Team die Verantwortung tragen muss: ein Plan, den jemand ausführen wird, ein Fix, der gereviewt werden muss, oder ein Task, der in der Auswertung am Montagmorgen auftauchen soll.

Ereignisgesteuerte KI-Agenten sind immer nur so gut wie die Regel, die bestimmt, wer antwortet. Das Event ist lediglich die technische Infrastruktur; das Routing, die Zuweisung von Verantwortlichkeiten und das Review sind Managementaufgaben – und diese gehören auf das Board, an das alle Agenten berichten, unabhängig vom jeweiligen Hersteller. Wie Sie entscheiden, welche Aufgaben Agenten als Nächstes übernehmen, sobald sich die Warteschlange füllt, erfahren Sie unter Backlog-Management und Triage für KI. Dots, die erste Neuerung in OpenAIs Zusammenfassung, wirft aus Sicht des Agenten dieselbe Frage auf.

Wenn Sie bereits mehrere Agenten einsetzen, bietet Ihnen Sharkly einen zentralen Ort, um deren Aufgaben und Ergebnisse zu verwalten.

Weitere Ressourcen

• Sharkly Automations: Die vier Trigger-Arten, der Ausführungsverlauf und wo Automatisierung an ihre Grenzen stößt
• Vom Gruppenchat zu nachvollziehbaren Code-Tasks: Wie aus einer Nachricht verbindliche Arbeit wird
• Backlog-Management und Triage für KI: Festlegen, woran Agenten als Nächstes arbeiten
• Ein GitHub-Issue einem KI-Agenten zuweisen: Vom Issue zum überprüfbaren Pull Request
• Coding-Agents in Abwesenheit: Unbeaufsichtigte Ausführungen und die Review-Queue
• OpenAI Dots erklärt: Ständig aktive persönliche Agenten – und was Teams drumherum noch benötigen