How to assign issues to AI coding agents (and actually track the work)

Most teams adopting AI coding agents start the same way: someone opens Cursor or Claude Code, pastes in a ticket, waits for a diff, and copies the result back into a pull request. It works for one developer on one task. It falls apart the moment you want the rest of the team to know what the agent is doing, which issue it is working on, or whether its branch ever became a PR.

The underlying problem is that the agent has no identity in your tracker. It is a process on someone’s laptop, not an assignee. Hiveship is built around the opposite assumption: an agent is a first-class assignee, the same as a human teammate. This post walks through what that actually requires.

An agent needs an identity, not a seat

In a human-only tracker, the assignee field maps to a user account. To assign work to an agent, that field has to accept a non-human principal. In Hiveship every issue carries a delegateType — human or agent — so the same issue, board, and workflow handle both interchangeably. You assign “ENG-142” to an agent exactly the way you assign it to a person, and the board renders the agent assignee with its own avatar and a live activity indicator instead of trying to pretend it is a user.

Crucially, agents are not billed as seats. Hiveship’s pricing is a flat per-workspace fee with no per-agent charge on any plan — so adding a second or third agent doesn’t change your bill. (See the pricing page for the current plan limits; the Free plan includes one agent so you can try delegation before paying anything.)

Scoped tokens, so an agent can do exactly what you allow

Giving an autonomous process write access to your issue tracker is a security decision, not a convenience one. Hiveship issues each agent a bearer token of the form hsa_<agentId>_<secret>, and every token carries a capability tier:

• Read — the agent can fetch issue context, comments, and project state, but cannot change anything.
• Session — the agent can write to an issue it has an active working session on, and nothing else.
• Workspace — broader write access across the workspace, for trusted orchestration agents.

The API enforces this on every route: a workspace-scoped endpoint without an explicit agent-scope declaration fails closed, so an under-privileged token gets a clean 403 rather than silently succeeding. The practical effect is that you can hand a coding agent a Session token and know it can comment on and update the one issue it is working, but cannot wander into billing or delete a project.

The activity trail is the whole point

When a human picks up a ticket, the team infers progress from commits, comments, and PR status. An agent should leave the same trail — otherwise “the agent is working on it” is indistinguishable from “the agent crashed twenty minutes ago.” Hiveship records agent activity as a stream on the issue: what the agent read, what it changed, the diffs it produced, and the PR it opened. Those events stream to the board in real time over SSE, so a teammate watching the issue sees the agent move from “reading the codebase” to “opened PR #88” without refreshing.

This is also what makes agents reviewable. A diff attached to an issue, with the PR linked through the native GitHub integration, gives a human reviewer everything they need to approve or reject the work in the same place they manage everything else.

Wiring up a coding agent

The connection itself is deliberately boring. You register an agent in the workspace, generate a token at the tier you want, and point your coding tool at Hiveship through the MCP server — the same protocol Claude Code, Cursor, and Codex already speak. From there the agent can pull the issue it has been assigned, post progress, and attach its output. The full setup walkthrough lives in the agent setup docs. The packaged MCP server is free on every plan; even on Free you can register an agent, assign it issues, and follow its activity stream with a scoped token.

Once that is in place, the workflow inverts. Instead of a developer babysitting a chat window and shuttling context back and forth, you triage issues onto agents from the board, and the agents report back into the board. The humans stay in the tool they already use to run the team; the agents become teammates inside it rather than a side channel.

Where to start

If you already run an issue tracker, the smallest useful experiment is to register one agent, give it a Session-scoped token, and route a single well-specified bug fix to it. Watch the activity stream, review the diff, merge the PR. You will learn more about whether agent delegation fits your team from that one loop than from any amount of planning.

Hiveship is free to start with one agent included. See how the agent-first board works, or read the agents documentation for the full model.