Ich habe gerade ein OKR erstellt, ohne Tability überhaupt zu öffnen.
So ist es passiert. Wir migrieren gerade unsere gesamte Oberfläche zu shadcn/ui (das wird richtig gut, wenn es fertig ist). Die Spezifikation liegt in Confluence: Modals, Panels, Seiten, komplexe Komponenten, etwa 240 Dinge, die migriert werden müssen, alle als Checkboxen erfasst. Nützlich für das Team, das die Arbeit macht. Nutzlos, um den Fortschritt auf OKR-Ebene zu verfolgen.
Also habe ich Claude gebeten, die Confluence-Seite zu lesen, zusammenzufassen, was noch übrig ist, und ein neues KR zu unserem Q2-Plan hinzuzufügen, um den Migrationsfortschritt zu verfolgen.
Hat es getan. In weniger als einer Minute.
Das ist keine Geschichte im Stil von „wow, KI ist schnell". Das ist der Anfang von etwas Interessanterem – die Art, wie OKRs tatsächlich verwaltet werden, steht vor einem Wandel.
Die 3 Aufgaben, die gerade zu 1 Prompt verschmolzen sind
Ein Ziel wie dieses einzurichten, erforderte früher drei separate Aufgaben, meist verteilt auf drei verschiedene Personen.
Jemand liest die Spezifikation. Diese Person geht die Confluence-Seite durch, zählt die Komponenten, stellt fest, was erledigt ist und was nicht, und macht daraus eine Zahl.
Jemand schreibt das OKR. Diese Person übersetzt die Arbeit in ein messbares Ergebnis, wählt ein Ziel, benennt einen Verantwortlichen, schreibt die Beschreibung. Wenn du schon mal vor der leeren Seite gesessen hast und versucht hast, ein KR zu formulieren, weißt du, wie lange das dauern kann. (Wir haben einen ganzen Leitfaden geschrieben, wie man das in unter 30 Minuten schafft, und das ist für die meisten Teams immer noch der schwierigste Teil des Zyklus.)
Jemand hält es aktuell. Jede Woche prüft diese Person die Spezifikation, zählt erneut, schreibt ein Check-in, postet irgendwo ein Status-Update. Oft ist genau das die Stelle, an der OKR-Einführungen leise sterben.
Drei Aufgaben. Drei Kontextwechsel. Drei Stellen, an denen der Schwung erlischt.
Was ich stattdessen gemacht habe: ein einziger Prompt. Claude hat die Confluence-Seite über Rovo gelesen, unsere bestehende Planstruktur über das Tability MCP abgerufen, das KR vorgeschlagen und es erstellt, nachdem ich die Details bestätigt hatte. Die Confluence-Spezifikation bleibt die Quelle der Wahrheit für das Team. Das Tability-KR ist das verdichtete Signal für die Führungsebene. Beide bleiben synchron, ohne dass jemand etwas kopieren und einfügen muss.
Warum das wichtiger ist, als es klingt
Reibung ist der Feind jeder OKR-Einführung.
Menschen aktualisieren ihre Ziele nicht, wenn sie dafür erst durch Jira, Linear, Notion, Sentry, Amplitude und drei Slack-Threads wühlen müssen, um herauszufinden, was diese Woche tatsächlich passiert ist. Bis du die Daten zusammengetragen hast, hast du eine Stunde verloren – und die Lust, ein durchdachtes Check-in zu schreiben.
Also schreibst du „läuft gut" und machst weiter. Oder du überspringst das Check-in ganz. Und sechs Wochen später fühlen sich deine OKRs losgelöst von der eigentlichen Arbeit an, weil niemand die Verbindung erzählt hat.
Agentische OKRs drehen das um. Der Agent übernimmt das Sammeln. Du übernimmst das Denken.
In unserem Fall ist Confluence die Datenquelle, aber dasselbe Muster funktioniert für alles. Sentry für Fehleranzahlen. Amplitude für Nutzungskennzahlen. Stripe für Umsatz. GitHub für ausgelieferte PRs. Dem KR ist egal, woher die Zahl kommt. Sie muss nur jede Woche zuverlässig auftauchen.
Der nächste Schritt: ein Teammitglied, kein Tool
Das KR zu erstellen war Schritt eins. Schritt zwei ist, es selbsttragend zu machen.
Dafür werden wir ein Tability-Agenten-Teammitglied aufsetzen: ein KI-Teammitglied, das im Workspace lebt, das KR besitzt und nach einem Zeitplan über Claude Cowork läuft.
Jeden Montagmorgen, vor dem Standup, wird es:
- Die Confluence-Seite lesen
- Fertige Komponenten zählen
- Mit der letzten Woche vergleichen
- Ein Check-in mit der neuen Zahl und einer kurzen Notiz dazu posten, was ausgeliefert wurde
Keine Menschen im Loop für das Sammeln der Daten und das Check-in. Wir werden den Fortschritt weiterhin in unserem wöchentlichen Meeting besprechen und Kontext hinzufügen, falls etwas aus dem Ruder läuft, aber wir müssen niemanden mehr aus seinem Flow reißen, nur um den Fortschritt dieser Migration zu verfolgen.
Das macht den Unterschied zwischen „KI im Workflow" und „KI, die den Workflow übernimmt". Die meisten KI-Funktionen heute sind Autovervollständigung für Menschen. Agentische OKRs bedeuten: Menschen prüfen, was der Agent bereits getan hat. Wir arbeiten schon eine Weile auf dieses Muster hin: unser Churn-Prevention-Agent funktioniert genauso, und wir haben eine private Beta für Kunden am Laufen, die diesen Ansatz ausprobieren möchten.
Wohin das führt
In einem Jahr, glaube ich, wird der Großteil der Teams, die OKRs gut umsetzen, mindestens einen Agenten pro Objective haben. Keinen Chatbot. Eher ein Teammitglied mit Stellenbeschreibung, Zeitplan und Zugriff auf die Systeme, in denen die Arbeit passiert. Der menschliche Owner gibt die Richtung vor und trifft die Entscheidungen. Der Agent hält den Rhythmus.
Wir bauen Tability für genau diese Welt. Das MCP ist der Weg, wie Claude – oder jedes andere Modell – mit deinen Zielen spricht. Agenten sind der Weg, wie diese Ziele zwischen den Check-ins lebendig bleiben.
Wenn du das selbst ausprobieren willst: Das Tability MCP ist live und funktioniert schon heute mit Claude. Verbinde es, richte es auf deinen Plan aus und bitte es, dir beim Schreiben deines nächsten KR zu helfen. Du wirst den Unterschied in etwa fünf Minuten spüren.
Und wenn du über agentische OKRs ernsthafter nachdenkst, würde ich mich gerne mit dir austauschen. Schreib mir an [email protected] oder finde mich auf LinkedIn.
.jpg)
