OKRs, wenn der Nutzer ein KI-Agent ist: Warum Key Results bei Menschen bleiben

Immer mehr Produkte werden nicht nur von Menschen genutzt, sondern von KI-Agenten. Ein Reiseassistent bucht Flüge über eine Schnittstelle, ein Einkaufsagent vergleicht Shops, ein Agent im Unternehmen legt Termine an oder beantwortet Anfragen. Für Produktteams stellt sich damit eine neue Frage: Wie schreibt man OKRs, wenn der „Nutzer“ eine Maschine ist?

Diese Frage war die häufigste in einem Webinar, das Jeff Gothelf und Josh Seiden im September 2026 gehalten haben. Gothelf hat seine Antwort danach in einem Blogbeitrag ausgeführt. Sie ist kurz und überzeugend, deshalb stelle ich sie hier vor.

Das Problem: Agenten haben Verhalten, aber kein Interesse

Gothelf und Seiden definieren ein Outcome in ihrem Buch „Who Does What By How Much?“ als messbare Veränderung im Verhalten von Menschen, die Wert schafft. Ein Key Result beschreibt also, wer sich wie anders verhält und um wie viel.

Auch ein Agent verhält sich. Er ruft Schnittstellen auf, stellt Anfragen, bricht ab oder schließt Vorgänge ab. Und dieses Verhalten lässt sich sehr leicht messen. Genau deshalb ist die Versuchung groß, den Agenten an die Stelle des Kunden zu setzen. Gothelf hält dagegen: „An agent has behavior. It has no stake.“ Ein Agent hat Verhalten, aber kein eigenes Interesse. Er hat keine Bedürfnisse, kein Budget und nichts zu verlieren. Deshalb kann er nicht derjenige sein, für den ein Outcome Wert schafft.

Der Agent als Bote

Gothelf beschreibt den Agenten als Boten, als „courier“, der zwischen zwei Menschen sitzt:

• Der Mensch, der den Agenten einsetzt. Er beauftragt den Agenten und trägt die Verantwortung für das, was dieser in seinem Namen tut.
• Der Mensch, der das Ergebnis bekommt. Er muss mit der Arbeit des Agenten weiterarbeiten: sie annehmen, nachbessern oder verwerfen.

Die Key Results gehören an diese beiden Enden. Die Leistung des Agenten selbst, also Aufrufe, Antwortzeiten oder Fehlerquoten, ist eine Systemkennzahl. Sie gehört auf ein Dashboard, aber nicht in ein Key Result.

Die Methode: Key Results eine Ebene höher schreiben

Gothelf braucht dafür kein neues Modell. Seine Anleitung hat drei Schritte:

1. Nimm jedes bestehende Key Result.
2. Verschiebe es vom Agenten zu einem der beiden Menschen an den Enden.
3. Frag bei jedem Key Result: Wessen Verhalten sagt es voraus? Kannst du eine Person benennen, ist es ein Outcome. Ist die einzige Antwort der Agent, ist es eine Systemkennzahl.

Das Beispiel: Ein Buchungsdienst für Reiseagenten

Gothelf zeigt die Methode an einem Unternehmen, das seine Buchungsschnittstelle für autonome Reiseassistenten öffnet.

Vorher, aus Sicht des Agenten:

• Objective: Die Standard-Buchungsplattform für autonome Reiseagenten werden.
• KR 1: Die von Agenten ausgelösten Aufrufe der Schnittstelle steigen von 1,2 auf 5 Millionen pro Monat.
• KR 2: Die mittlere Antwortzeit sinkt von 900 auf 200 Millisekunden.
• KR 3: Der Anteil erfolgreicher Anfragen steigt von 92 auf 99 Prozent.

Nachher, aus Sicht der Menschen:

• Objective: Reisende bekommen über ihren Assistenten Reisen gebucht, die sie auch wirklich antreten.
• KR 1: Der Anteil der vom Agenten gebuchten Reisepläne, die Reisende ohne Änderung übernehmen, steigt von 48 auf 70 Prozent.
• KR 2: Der Anteil der vom Agenten gebuchten Reisen, die unser Support nachbessern muss, sinkt von 22 auf 8 Prozent.
• KR 3: Der Anteil der Reisenden, die die automatische Buchung eingeschaltet lassen, nachdem der Assistent zum ersten Mal einen Fehler gemacht hat, steigt von 30 auf 55 Prozent.

Jedes der neuen Key Results misst etwas anderes. KR 1 zeigt, dass Reisende dem Ergebnis vertrauen. KR 2 zeigt, dass der interne Aufwand für Nacharbeit sinkt. KR 3 misst, ob Menschen sich weiter auf das Produkt verlassen, nachdem es einen Fehler gemacht hat. Gothelf hält das für den stärksten Beweis, dass Kunden an das Produkt glauben. Um dieses Key Result würde er am härtesten kämpfen.

Gothelf räumt offen ein, dass die zweite Version schwerer zu messen ist. Das ist Absicht. Die Zahlen aus der ersten Version wirken sauber und präzise, und genau diese Präzision ist die Falle.

Warum die Präzision eine Falle ist

Der Gedanke ist nicht neu, er bekommt durch Agenten nur eine neue Schärfe. Teams messen gern, was sich leicht messen lässt, und erklären es dann zum Ziel. Fünf Millionen Aufrufe im Monat können bedeuten, dass das Produkt beliebt ist. Sie können aber auch bedeuten, dass Agenten fünfmal nachfragen müssen, weil die Antworten unbrauchbar sind. Wer auf Aufrufe optimiert, belohnt im schlimmsten Fall genau das Falsche. Das ist Goodharts Gesetz in Reinform: Sobald eine Kennzahl zum Ziel wird, taugt sie nicht mehr als Kennzahl.

Systemkennzahlen sind deshalb nicht wertlos. Antwortzeit und Fehlerquote zeigen, ob die Technik funktioniert, und gehören täglich beobachtet. Sie sind nur eine schlechte Definition von Erfolg für ein Quartal. Den Unterschied zwischen Kennzahlen zum Beobachten und Zielen zum Verändern beschreibe ich im Artikel OKR, KPIs und Metriken.

Was das für das Marketing heißt

Die Frage betrifft nicht nur Produktteams. Auch im Marketing schieben sich Agenten zwischen Unternehmen und Kunden. KI-Systeme lesen Websites, fassen Angebote zusammen und empfehlen Produkte. Wer dafür optimiert, landet schnell bei Kennzahlen wie Erwähnungen in KI-Antworten oder Abrufen durch KI-Crawler. Wie diese Sichtbarkeit entsteht, beschreibe ich im Artikel zur Generative Engine Optimization.

Nach Gothelfs Logik sind auch das Systemkennzahlen. Das Key Result liegt bei den Menschen: Kommen Besucher, die über eine KI-Empfehlung kommen, häufiger zum Kauf? Fragen weniger Kunden beim Service nach, weil die Zusammenfassung der KI falsch war? Kaufen Kunden erneut, nachdem ein Agent für sie bestellt hat?

Die offene Frage: Wie misst man den Menschen am Ende?

Unter Gothelfs Beitrag fragt ein Leser, wie man das Verhalten der Person am Ende beobachten soll, wenn diese Person der Kunde des eigenen Kunden ist. Eine Antwort steht dort nicht. Aus meiner Sicht gibt es drei Wege, die man kombinieren kann:

• Signale, die zurückkommen: Stornierungen, Rückgaben, Reklamationen und Supportfälle landen oft wieder beim eigenen Unternehmen.
• Daten des Kunden: Mit Geschäftskunden lassen sich gemeinsame Kennzahlen vereinbaren, etwa wie viele Ergebnisse unverändert übernommen werden.
• Stichproben: Regelmäßige Gespräche mit einigen Endnutzern zeigen, ob die Zahlen die Wirklichkeit treffen.

Keiner dieser Wege ist so bequem wie ein Zähler für Schnittstellenaufrufe. Aber genau das ist Gothelfs Punkt.

Mein Fazit

Der Beitrag ist eine gute Erinnerung daran, worum es bei OKRs eigentlich geht. Technik ist nie das Ziel, sondern das Mittel. Ein Agent kann noch so schnell und fehlerfrei arbeiten: Wenn die Menschen an beiden Enden ihm nicht vertrauen, hat das Produkt nichts erreicht.

Für die Praxis nehme ich die Prüffrage mit: Wessen Verhalten sagt dieses Key Result voraus? Sie funktioniert nicht nur bei Agenten, sondern bei jedem Key Result, das verdächtig nach Aufgabenliste oder Technikkennzahl klingt. Wie gute Key Results grundsätzlich aussehen, zeige ich in den Artikeln Wie du effektive OKRs schreiben kannst und Der Lean Strategy Canvas. Was KI-Agenten sind und wo sie heute stehen, steht im Artikel Die drei Stufen der KI im Unternehmen.

Alle Artikel zum Thema findest du im Handbuch-Kapitel OKR.

Quelle: Jeff Gothelf: How to write an outcome-based OKR when your user is an AI agent