Agenten mit eigener Identität, Tokens und Ticket-Claims

Spedy betreibt keine Agenten. Euer Team bringt seine eigenen mit – Claude Code, Codex, Cursor oder einen selbst gebauten Loop. Was bisher fehlte, war die andere Seite: eine Identität, an der diese Arbeit hängt, und Regeln, die sie einrahmen. Genau das ist jetzt da.

Ein Agent ist ein eigener User

Einstellungen → Agenten → Neuer Agent. Was dabei entsteht, ist ein Mitglied eurer Organisation mit drei Unterschieden zu einem Menschen:

• Kein Login. Kein Passwort, kein Social-Login, keine Zwei-Faktor-Einrichtung, keine Einladung. Nur Access-Tokens.
• Kein Seat. Agenten zählen nicht in eure abgerechneten Plätze und nicht ins User-Limit eures Plans.
• Keine E-Mail. Agenten bekommen nie Mail. Was ein Loop wissen muss, holt er sich über MCP am Ticket ab – oder ein Webhook weckt ihn.

Alles andere funktioniert wie bei jedem Mitglied: zuweisbar, kommentierend, zeiterfassend – und überall als Agent gekennzeichnet. Jeder Agent gehört einer menschlichen Person, die seine Einstellungen und Tokens verwalten darf, auch ohne Admin-Recht.

Agenten-User brauchen Pro. MCP selbst gibt es weiterhin auf jedem Plan.

Tokens, die nur das dürfen, was sie sollen

Ein Token ist kein Generalschlüssel. Beim Erzeugen schneidet ihr es zu:

Die Durchsetzung ist fail-closed: Ein auf zwei Projekte beschränktes Token erreicht kein drittes, auch wenn der Agent dort Mitglied ist. Wird etwas abgelehnt, sagt die Antwort warum – PAT_READ_ONLY, PAT_DENY_DELETE oder PAT_BOARD_NOT_ALLOWED – damit euer Loop ein Scope-Problem von einem Rechteproblem unterscheiden kann.

Eine Ausnahme haben wir bewusst eingebaut: Den eigenen Claim darf ein Loop auch mit „Nicht löschen" zurückgeben. Er muss sein Ticket immer freigeben können. Nur der Claim eines fremden Akteurs bleibt gesperrt.

Claims: ein Ticket, ein Loop

tickets_claim nimmt einen exklusiven, ablaufenden Anspruch auf genau ein Ticket. Von zwei Loops, die im selben Moment zugreifen, gewinnt einer; der andere bekommt einen klaren Konflikt mit Halter und Ablaufzeit und zieht weiter.

Wichtig ist das Ablaufen. Der Claim endet nach 30 Minuten, per tickets_heartbeat verlängerbar bis maximal vier Stunden. Ein Loop, der mitten im Lauf stirbt, blockiert das Ticket also nicht bis Montag – Spedy räumt den abgelaufenen Claim weg und hinterlässt eine Notiz.

Gefunden wird die Arbeit über drei Filter, die es an tickets_list, tickets_search, im Issues-Hub und auf GET /issues gibt: claimable (was frei ist), assignedToMe (was euch jemand bewusst übergeben hat) und claimedBy: "me" (was ihr schon haltet). Mensch und Loop sehen dieselbe Warteschlange.

Eine Rückmeldung, ein Aufruf

tickets_report beendet den Lauf: Es schreibt einen Kommentar in fester Struktur, verknüpft den Pull Request, stoppt den Timer, gibt den Claim frei – und verschiebt den Status, sofern er das darf.

Es bricht nie halb ausgeführt ab. Der Kommentar wird zuerst geschrieben; alles danach ist best effort, und was nicht ging, kommt mit Begründung in issues[] zurück. Fehlt die Berechtigung für den Statuswechsel, steht dort PERMISSION_DENIED – der Text des Agenten geht trotzdem nie verloren.

Richtlinien: was ein Agent nicht allein darf

Einstellungen → Agenten → Agenten-Richtlinien gilt für alle Agenten der Organisation. Menschen sind nicht betroffen.

• Statuswechsel mit Freigabe. Standard: DONE. Der Wechsel findet nicht statt, stattdessen entsteht ein Vorschlag im gewohnten Banner. Über die REST-API antwortet Spedy dabei mit AGENT_APPROVAL_REQUIRED – es gibt keine zweite Tür.
• Agenten-PRs sichtbar machen. Pull Requests, deren Autor zur Git-Identität eines Agenten passt, werden mit „Review nötig" markiert. Informativ – für echte Blockaden ist der Branch-Schutz eures Providers zuständig.
• Zeit als Entwurf. Was ein Agent erfasst, landet mit Status PENDING, skaliert mit dem Zeitfaktor, und ein Mensch gibt es frei. Dazu ein Wochenlimit pro Agent. Auch das hängt am Akteur, nicht am Transportweg: über REST gilt es genauso.

Wiki schreiben, und zwei Benachrichtigungen

Zwei neue MCP-Tools schreiben ins Wiki: wiki_pages_create und wiki_pages_update. Damit legt ein Agent Gelerntes dort ab, wo das Team es wiederfindet, statt es in einem Ticket-Kommentar zu vergraben. Beide brauchen wiki:edit und Editor-Rechte im jeweiligen Bereich – dieselben zwei Bedingungen wie bei einem Menschen.

Und damit niemand ein Dashboard beobachten muss, melden sich zwei Dinge von selbst bei der verantwortlichen Person und beim Besitzer des Agenten:

• TICKET_CLAIM_EXPIRED – ein Claim ist unfreigegeben abgelaufen. Passiert das ständig, stirbt euer Loop ständig.
• AGENT_RUN_REPORTED – ein Lauf meldet blocked oder needs_review, also genau die Ergebnisse, die nach einem Menschen fragen. done bleibt bewusst still.

Was dabei herauskommt, steht danach in der Agenten-Übersicht und im Lieferweg jedes Tickets.

Loslegen

Die Feature-Seite zu Agenten zeigt das Modell im Überblick. Wie ihr einen Agenten anlegt und sein Token zuschneidet, steht in den Agenten-Einstellungen; das Protokoll dahinter in den Agent Loops. Und wer lieber Code liest: Der Referenz-Loop zeigt den kompletten Ablauf in rund 200 Zeilen.

Die Maschine schlägt vor, arbeitet und meldet zurück. Die Entscheidung, was davon fertig ist, bleibt bei euch.