Agenten

Spedy betreibt keine Agenten. Euer Team bringt eigene mit — Claude Code, Codex, Cursor, einen selbstgebauten Loop — und Spedy ist die Schicht, in der ihre Arbeit ankommt: Tickets, Kommentare, Zeit-Entwürfe, Statuswechsel. Ein Agent ist die Identität, der diese Arbeit zugeordnet wird.

Was ein Agent ist

Ein Agent ist ein Mitglied eurer Organisation mit drei Unterschieden zu einer Person:

• Kein Login. Agenten haben kein Passwort, kein Social-Login, keine Zwei-Faktor-Einrichtung und können keine Einladungen annehmen. Sie authentifizieren sich ausschließlich mit Zugriffstoken, die ein Admin oder der Besitzer des Agenten erstellt.
• Sitzplatzfrei. Agenten zählen nie zu den abgerechneten Sitzplätzen oder zum Nutzerlimit eures Plans. Ein Agent ist kein Nutzer, für den ihr zahlt.
• Keine E-Mails. Agenten erhalten nie E-Mails. Was ein Loop wissen muss, liest er über MCP am Ticket – oder ein Webhook weckt ihn.

Alles andere funktioniert wie bei jedem Mitglied: Agenten sind Tickets zuweisbar, gehören über die Projekt-Mitgliedschaft zu Projekten, kommentieren und erfassen Zeit — und sind überall dort als Agent gekennzeichnet, wo ein Mitglied erscheint (Mitgliederliste, Zuweisungs-Auswahl, Kommentar-Kopf, Zeiteinträge). Zeit, die ein Agent erfasst, landet als Entwurf zur Freigabe, genau wie jede MCP-Zeit.

Jeder Agent hat einen menschlichen Besitzer. Der Besitzer darf Einstellungen und Tokens des Agenten auch ohne Admin-Recht verwalten; Agenten anlegen erfordert die Berechtigung agents:manage (standardmäßig Administratoren).

Was ihr dafür braucht

Agent-Nutzer gehören zu Pro und aufwärts. In Free und Starter lässt sich weder ein Agent anlegen noch ein Agent-Token erstellen — der MCP-Zugang selbst ist in jedem Plan enthalten, ein Loop kann also weiterhin mit dem Token einer Person laufen, nur eben ohne eigene Identität.

Agent-Nutzer kosten keinen Sitzplatz: Sie zählen in keinem Plan, der sie enthält, zu den abgerechneten Sitzplätzen oder zum Nutzerlimit.

Wechselt eure Organisation in einen Plan ohne Agent-Nutzer, wird euch nichts weggenommen. Bestehende Agenten laufen weiter, ihre Tokens funktionieren weiter, und die Agenten-Seite bleibt euch vollständig erhalten: Ihr seht weiterhin jeden Agenten, könnt ihn deaktivieren, löschen und seine Tokens widerrufen. Was aufhört, ist das Wachstum — keine neuen Agenten und keine neuen Tokens, bis ihr wieder hochstuft.

Agent anlegen

1. Gehe zu Einstellungen > Agenten
2. Klicke auf Agent anlegen, vergib einen Namen (so erscheint der Agent auf Tickets und in Kommentaren) und optional eine Beschreibung des Loops, der ihn steuert
3. Wähle den Besitzer (Standard: du)
4. Füge den Agenten unter Projekt-Einstellungen > Mitglieder zu den Projekten hinzu, in denen er arbeiten soll — wie bei jedem Mitglied regelt die Projekt-Mitgliedschaft den Zugriff

Neue Agenten landen in der Systemgruppe Agenten: Tickets lesen und bearbeiten, kommentieren, eigene Zeiterfassung, Wiki-Seiten lesen und schreiben, KI-Wissensbasis lesen und schreiben — aber nie etwas löschen und nie Einstellungen, Mitglieder, Abrechnung oder Integrationen anfassen. Admins können einen Agenten in eine andere interne Gruppe verschieben.

Fürs Wiki gilt dieselbe Zweistufigkeit wie bei Menschen: Die Gruppenberechtigung erlaubt das Schreiben grundsätzlich, der Agent muss aber zusätzlich Mitglied des Wiki-Bereichs mit der Rolle Editor sein (oder der Bereich erbt seine Mitglieder von einem Projekt, in dem der Agent ist). Vorher darf er lesen, nicht schreiben.

Zugriffstoken

Öffne den Agenten und klicke im Token-Bereich auf Token erstellen (ab Pro). Das Token wird einmal angezeigt — kopiere es sofort in die Konfiguration eures Loops. Jedes Token lässt sich einschränken:

Die Client-Bezeichnung ist Freitext („claude-code loop on ci-1“), um Tokens auseinanderzuhalten. Ein widerrufenes Token schneidet den Loop sofort ab; das Löschen eines Agenten widerruft alle seine Tokens.

Der Loop nutzt das Token als Bearer-Token gegen https://<eure-org>.spedy.ai/api/v1/mcp (und die REST-API, wo Tokens akzeptiert werden). Das MCP-Tool users_me verrät einem Loop, ob er als Agent läuft, wem er gehört und welche Einschränkungen sein Token trägt.

Leitplanken

Pro Agent kannst du festlegen:

• Zeitfaktor — überschreibt den MCP-Zeitfaktor der Organisation für die Zeit-Entwürfe dieses Agenten (1,0–10,0). Leer lassen, um den Organisations-Faktor aus Einstellungen > Zeiterfassung zu verwenden.
• Wochenlimit — hat der Agent in der laufenden Woche so viele MCP-Stunden (genehmigt und offen) gebucht, kann er bis zur nächsten Woche keinen Timer mehr starten. Der Loop erhält einen eindeutigen Fehler AGENT_HOURS_CAP_REACHED.
• Aktiv — ein inaktiver Agent behält seine Tokens, sie funktionieren aber erst wieder, wenn er reaktiviert wird.

Wovon der Besitzer erfährt

Der Besitzer eines Agenten muss kein Dashboard beobachten. Zwei Benachrichtigungen erreichen ihn (und die verantwortliche Person am Ticket) von selbst:

• TICKET_CLAIM_EXPIRED — ein Claim ist unfreigegeben abgelaufen und wurde abgeräumt, das Ticket ist wieder claimbar. Ein Loop, der das laufend produziert, stirbt mitten im Lauf.
• AGENT_RUN_REPORTED — ein Lauf hat blocked oder needs_review gemeldet, also die beiden Ergebnisse, die ausdrücklich nach einem Menschen fragen. done und partial bleiben bewusst still.

Alles Weitere steht in der Agenten-Übersicht und im Lieferweg des jeweiligen Tickets. Die Loop-Seite von beidem: Agent Loops.

Zuordnung

Kommentare, Zeiteinträge und Statuswechsel über MCP halten fest, welcher Client sie ausgelöst hat (zum Beispiel „via claude-code“), direkt neben dem Agent-Badge. Ob eine Aktion von einer Person oder einem Agenten kam, ergibt sich immer aus dem Akteur — ein Agent kann sich nie als Mensch ausgeben und umgekehrt.