Agents
Give your own coding agents a seat-free identity in Spedy and control what their access tokens may do.
Spedy does not run agents. Your team brings its own — Claude Code, Codex, Cursor, a home-grown loop — and Spedy is where their work arrives: tickets, comments, time drafts, status changes. An agent is the identity that work is attributed to.
What an agent is
An agent is a member of your organization with three differences to a person:
- No login. Agents have no password, no social login, no two-factor setup and cannot accept invitations. They authenticate exclusively with access tokens that an Admin or the agent's owner creates.
- Seat-free. Agents never count toward your billed seats or your plan's user limit. An agent is not a user you pay for.
- 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 for any member: agents can be assigned tickets, belong to projects through project membership, comment, and track time — and they are labelled Agent wherever a member appears (member list, assignee picker, comment headers, time entries). Time an agent tracks lands as a draft pending approval, exactly like all MCP time.
Every agent has a human owner. The owner may manage the agent's settings and tokens even without the admin permission; creating agents requires the agents:manage permission (Administrators by default).
What you need for it
Agent users are part of Pro and above. On Free and Starter you can neither create an agent nor mint an agent token — MCP access itself is on every plan, so a loop can still run under a person's own token, it just has no identity of its own.
Agent users cost no seat: they never count toward your billed seats or your plan's user limit, on any plan that includes them.
If your organization moves down to a plan without agent users, nothing is taken away from you. Existing agents keep working, their tokens keep working, and you keep the full agent page: you can still see every agent, deactivate one, delete one and revoke its tokens. What stops is growth — no new agents and no new tokens until you upgrade again.
Creating an agent
- Go to Settings > Agents
- Click Create agent, give it a name (this is what appears on tickets and comments) and, optionally, a description of the loop that drives it
- Pick the owner (defaults to you)
- Add the agent to the projects it should work on under Project settings > Members — like any member, project membership is what grants access
New agents land in the system permission group Agents: read and work tickets, comment, own time tracking, read and write wiki pages, read and write the AI knowledge base — but never delete anything and never touch settings, members, billing or integrations. Admins can move an agent into another internal group.
Wiki writing follows the same two-step rule as for people: the group permission allows it in principle, but the agent still has to be a member of the wiki space with the role Editor (or the space inherits its members from a project the agent belongs to). Until then it can read, not write.
Access tokens
Open the agent and click Mint token in the tokens section (Pro and above). The token is shown once — copy it into your loop's configuration right away. Each token can be restricted:
| Restriction | Effect |
|---|---|
| Read-only | Only read tools and GET requests. The agent can look, not change. |
| No delete (default on) | Blocks every delete tool and DELETE request. |
| Restrict to projects | Only the selected projects, regardless of the agent's project memberships. |
| Expiration | 30 / 90 / 365 days or never. |
The client label is free text ("claude-code loop on ci-1") to tell tokens apart. Revoking a token cuts the loop off immediately; deleting the agent revokes all of its tokens.
The loop uses the token as a bearer token against https://<your-org>.spedy.ai/api/v1/mcp (and the REST API where tokens are accepted). The users_me MCP tool tells a loop whether it runs as an agent, who owns it, and which restrictions its token carries.
Guardrails
Per agent you can set:
- Time factor — overrides the organization's MCP time factor for this agent's time drafts (1.0–10.0). Leave empty to use the organization factor from Settings > Time Tracking.
- Weekly cap — once the agent has booked this many MCP hours (approved and pending) in the current week, it can no longer start a timer until the next week. The loop receives a clear
AGENT_HOURS_CAP_REACHEDerror. - Active — an inactive agent keeps its tokens, but they stop working until it is reactivated.
What the owner hears about
An agent's owner does not have to watch a dashboard. Two notifications reach the owner (and the ticket's assignee) on their own:
TICKET_CLAIM_EXPIRED— a lease ran out unreleased and was swept, so the ticket is claimable again. A loop that keeps producing these is dying mid-run.AGENT_RUN_REPORTED— a run reportedblockedorneeds_review, the two outcomes that are explicitly asking for a person.doneandpartialstay quiet on purpose.
Everything else is in the agents overview and in each ticket's delivery trace. See Agent Loops for the loop side of both.
Attribution
Comments, time entries and status changes made over MCP record which client made them (for example "via claude-code"), next to the agent badge. Whether an action came from a person or an agent is always derived from the actor — an agent can never pose as a human, and vice versa.