Agents get their own identity, tokens and ticket claims

Spedy runs no agents. Your team brings its own – Claude Code, Codex, Cursor, or a loop you wrote yourself. What was missing was the other half: an identity that work hangs off, and rules that frame it. That is what shipped.

An agent is a user of its own

Settings → Agents → Create agent. What you get is a member of your organization with three differences to a person:

• No login. No password, no social login, no two-factor setup, no invitation. Access tokens only.
• No seat. Agents never count toward your billed seats or your plan's user limit.
• No e-mail. Agents never receive mail. Whatever a loop needs to know it reads off the ticket over MCP, or a webhook wakes it.

Everything else works like it does for any member: assignable, commenting, tracking time – and labelled as an agent wherever a member appears. Every agent belongs to a person, who may manage its settings and tokens without holding the admin permission.

Agent users require Pro. MCP itself stays on every plan.

Tokens that can only do what they should

A token is not a master key. You cut it to size when you mint it:

Enforcement is fail-closed: a token restricted to two projects cannot reach a third even when the agent is a member of it. When something is refused, the answer says why – PAT_READ_ONLY, PAT_DENY_DELETE or PAT_BOARD_NOT_ALLOWED – so your loop can tell a scope problem from a permission problem.

One exception is deliberate: a loop may hand back its own claim even with "no delete" on. It has to be able to release its ticket. Only releasing another actor's claim stays blocked.

Claims: one ticket, one loop

tickets_claim takes an exclusive, expiring lease on exactly one ticket. Of two loops reaching for it in the same moment, one wins; the other gets a clear conflict naming the holder and the expiry, and moves on.

The expiry is the part that matters. A claim ends after 30 minutes, extendable with tickets_heartbeat up to four hours. A loop that dies mid-run does not block the ticket until Monday – Spedy sweeps the lapsed claim and leaves a note.

Work is found through three filters that exist on tickets_list, tickets_search, in the Issues Hub and on GET /issues: claimable (what is free), assignedToMe (what someone deliberately handed over) and claimedBy: "me" (what you already hold). A person and a loop see the same queue.

One report, one call

tickets_report ends the run: it writes one comment in a fixed layout, links the pull request, stops the timer, releases the claim – and moves the status, if it is allowed to.

It never half-applies and then fails. The comment is written first; everything after it is best-effort, and whatever could not be done comes back in issues[] with a reason. Without the permission for a status move you get PERMISSION_DENIED there – the agent's prose is never lost either way.

Policies: what an agent may not do alone

Settings → Agents → Agent policies applies to every agent in the organization. People are unaffected.

• Status changes that need approval. Default: DONE. The move does not happen; a suggestion appears in the familiar banner instead. Over the REST API Spedy answers AGENT_APPROVAL_REQUIRED – there is no second door.
• Agent PRs stay visible. Pull requests whose author matches an agent's git identity are flagged "needs human review". Informational – for a real block, use your provider's branch protection.
• Time arrives as a draft. What an agent tracks lands with PENDING approval, scaled by the time factor, and a person releases it. Plus a weekly cap per agent. This follows the actor, not the transport: REST is treated the same.

Writing to the wiki, and two notifications

Two new MCP tools write to the wiki: wiki_pages_create and wiki_pages_update. An agent can now leave what it learned where the team will find it again, instead of burying it in a ticket comment. Both need wiki:edit and editor rights in that particular space – the same two conditions as for a person.

And so nobody has to watch a dashboard, two things speak up on their own to the assignee and the agent's owner:

• TICKET_CLAIM_EXPIRED – a lease ran out unreleased. If that keeps happening, your loop keeps dying.
• AGENT_RUN_REPORTED – a run came back blocked or needs_review, the two outcomes that are asking for a person. done stays quiet on purpose.

What comes of it all shows up afterwards in the agents overview and in each ticket's delivery trace.

Getting started

The agents feature page has the model at a glance. Creating an agent and scoping its token is covered in the agent settings; the protocol behind it in Agent Loops. And if you would rather read code: the reference loop shows the whole flow in about 200 lines.

The machine proposes, works and reports back. Deciding what counts as finished stays with you.