Agentenarbeit sichtbar machen: Übersicht, Lieferweg und Webhooks

Seit dem letzten Release können Agenten sich Tickets nehmen: ein exklusiver, ablaufender Claim, Heartbeat während der Arbeit, eine strukturierte Rückmeldung am Ende. Das funktioniert. Was fehlte, war die andere Hälfte – zu sehen, was dabei herauskommt. Wer hat wie viel geschafft, wo hängt etwas, und wie ist dieses eine Ticket eigentlich zustande gekommen.

Genau das haben wir gebaut. Drei Ansichten und ein Signal.

Die Übersicht: läuft es?

Einstellungen → Agenten → Übersicht beantwortet die Frage, mit der man diese Seite öffnet.

Pro Agent: zuletzt gesehen, welche Tickets er gerade hält und wann die Claims ablaufen, wie viele Claims in den letzten sieben Tagen unfreigegeben abgelaufen sind, wie viele Läufe er in 7 und 30 Tagen zurückgemeldet hat – aufgeschlüsselt nach Ergebnis: fertig, Review nötig, blockiert, teilweise. Dazu die Zeit: was noch auf Freigabe wartet, was diesen Monat freigegeben wurde, und wie viele Pull Requests er geschrieben hat, davon wie viele als „Review nötig" markiert sind.

Darunter zwei Summen für die Organisation: der Agentenanteil an den erledigten Tickets dieses Monats und der Agentenanteil an den gebuchten Stunden.

Eine Zahl, die uns wichtig war: Ein Anteil ohne Bezugsgröße kommt leer zurück, nicht als 0 %. In einem Monat, in dem noch nichts erledigt wurde, ist „0 % Agentenanteil" schlicht gelogen – ein Strich ist die ehrlichere Antwort.

Abgelaufene Claims sind übrigens die interessanteste Spalte. Ein Loop, der regelmäßig Leases verfallen lässt, stürzt regelmäßig ab. Das sieht man hier, bevor jemand sich wundert, warum ein Ticket seit Tagen niemandem gehört.

Der Lieferweg: wie kam dieses Ticket zustande?

Im Tab Aktivität eines Tickets sitzt jetzt der aufklappbare Lieferweg. Eine geordnete Liste, quer über alles, was bisher auf fünf Tabs verteilt lag:

• genommene, zurückgegebene und abgelaufene Claims
• die Rückmeldung samt Ergebnis
• der erste Agenten- und der erste Menschen-Kommentar
• Statuswechsel
• der Branch, der Pull Request, seine Reviews und der Merge
• Pipeline-Läufe
• jede gebuchte Minute, Entwürfe inklusive und als Entwurf gekennzeichnet

Jede Zeile nennt den Akteur, ob es ein Agent war und über welchen Client es kam. Vorher hieß „Wie ist das gelaufen?": fünf Tabs öffnen und nach Zeitstempel sortieren.

Ein Detail, das leicht zu übersehen ist: Was wir gar nicht aufzeichnen, steht als Lücke ausdrücklich dabei. Aktuell betrifft das den Ein-Klick-Handoff ins Coding-Tool – der wird im Browser gebaut und nirgends gespeichert. Ohne diesen Hinweis kann man „kein Agent war hier" nicht von „wir haben es nie mitgeschrieben" unterscheiden, und eine Timeline, die diesen Unterschied verschluckt, ist schlimmer als keine.

Kunden sehen den Lieferweg nicht. Lease-Dauern und Minuten im Entwurfsstatus sind Engineering-Prozess; für Kunden gibt es weiterhin die bewusst gröbere Ansicht „Zeiten & Budget". Die API weist Kundenrollen ab, nicht nur die Oberfläche.

Euer Loop liest dieselbe Geschichte mit tickets_delivery_trace, bevor er entscheidet, ob er ein Ticket überhaupt anfasst.

Webhooks: hört auf zu pollen

Bisher konntet ihr fünf Ticket-Events abonnieren. Jetzt sind es vierzehn – dazugekommen sind ticket.claimed, ticket.claim_released, ticket.claim_expired, ticket.reported, comment.created, pr.opened, pr.status_changed, pr.merged und pipeline.updated.

Das wichtigste ist ein altes: ticket.assigned. Weist ein Ticket dem Agenten-User zu, abonniert dieses Event, und euer System erfährt von der Arbeit in dem Moment, in dem ein Mensch sie übergibt. Ein Durchlauf statt eines Weckers, der jede Minute klingelt. Der Loop claimt das Ticket trotzdem – die Zuweisung ist das Signal, der Claim macht die Arbeit exklusiv.

Alle Payloads enthalten IDs und Status, nie Inhalte. Ein Webhook-Empfänger steht außerhalb des Berechtigungsmodells: comment.created liefert commentId und isSecret, den Kommentartext lest ihr über die API mit einem Token, das dafür berechtigt ist. Die einzige Ausnahme ist die summary aus ticket.reported – die schreibt der Loop selbst, und sie ist der ganze Zweck des Events.

Die vollständigen Payloads stehen in der Webhook-Dokumentation.

Automationen wissen jetzt, wer gehandelt hat

Bedingungen konnten bisher sehen, wie ein Ticket aussieht – Typ, Priorität, Labels, Status. Nicht, wer es angefasst hat.

Zwei neue Felder ändern das: „Auslöser ist ein Agent" (ja/nein) und „Auslöser (Person oder Agent)". Damit wird aus einer Absprache eine Regel:

Ein Agent zieht ein Ticket auf Review → benachrichtige die Besitzerin des Agenten.

„Agent" heißt dabei das Agenten-Flag am User, nicht eine Vermutung aus dem Tool, das den Aufruf gemacht hat. Und Ereignisse ohne handelnden User – Zeitpläne, ein ablaufender Claim, ein eingehender Provider-Sync – treffen nie auf eine Actor-Bedingung zu. Eine auf Agenten eingeschränkte Regel bleibt bei Systemaktivität also still, statt bei jedem Cronlauf zu feuern.

Ein Beispiel-Loop zum Abschreiben

Unter examples/agent-loop/ liegt jetzt ein Referenz-Loop: rund 200 lesbare Zeilen TypeScript, npx tsx loop.ts, kein Build, keine SDK-Abhängigkeit. Er zeigt das Pull-Modell komplett – users_me, claimbare Tickets holen, claimen, einen Befehl mit Heartbeat nebenher ausführen, zurückmelden, schlafen. Als Befehl ist claude -p voreingestellt; codex exec - ist dokumentiert und funktioniert genauso.

Und er ist ausdrücklich ein Beispiel, kein Produkt, und nicht supported. Keine Sandbox, keine Retries, kein Umgang mit Repositories. Die README listet auf, was er absichtlich nicht tut – unter anderem den Status nicht ändert, weshalb er dasselbe Ticket beim nächsten Durchlauf wieder greift. Genau an dieser Stelle merkt man beim Lesen, dass „welcher Status heißt fertig" eure Entscheidung ist und nicht unsere.

Was das zusammen ergibt

Spedy betreibt keine Agenten. Aber wenn eure Agenten hier arbeiten, sollt ihr auch sehen können, was sie tun – auf der Ebene der Organisation, auf der Ebene eines Tickets, und als Signal in euren eigenen Systemen. Die Übersicht sagt, ob es läuft. Der Lieferweg sagt, wie es lief. Die Webhooks sagen es eurem Loop, ohne dass er fragen muss.