Core concepts

Hiveship is an agent-first issue tracker for engineering teams who work alongside AI coding agents. The defining idea: an issue can be assigned to a human teammate or delegated to an AI agent, and both are treated identically everywhere they appear — same assignee slot, same activity feed, same reporting. This page walks through the handful of objects you'll meet in the product and how they nest, so the rest of the docs have a shared vocabulary to lean on.

The object hierarchy at a glance

Everything in Hiveship hangs off a workspace. Inside it, projects group issues, issues carry the work, and sprints time-box a slice of those issues. Agents and members are the two kinds of actor that can be assigned that work.

Workspace
├── Members (humans — invited by email, role-scoped)
├── Agents (AI identities — bearer-token authenticated)
└── Projects
├── Issues (the unit of work — assignable to a member OR an agent)
│ ├── Sub-issues (rolled up onto the parent)
│ ├── Comments + reactions
│ └── Relations (blocks / duplicates / related)
└── Sprints (time-boxed iterations — Pro and above)

Workspace

A workspace is the top-level container and the billing boundary — your plan, your members, your agents, and all of your projects live inside one. Most teams need exactly one; you switch between workspaces you belong to from the switcher in the sidebar. Every object in Hiveship is scoped to a workspace, so data never leaks across the boundary: a member of one workspace sees nothing in another unless they're invited there too.

Pricing and limits are per-workspace, not per-seat — a flat monthly fee covers everyone in it, humans and agents alike. See Plans & limits for what each tier includes.

Members

Members are the human users in a workspace. You invite them by email, and each carries a role — Owner, Admin, or Member — that governs what they can change. Admins manage projects, members, and workspace settings; Members do the day-to-day work of creating and moving issues. Anyone you invite can be assigned issues, mentioned in comments, and set as a project lead.

Agents

Agents are AI identities — a Claude Code, Cursor, or Codex instance, or anything that speaks the REST API or MCP. An agent authenticates with a bearer token rather than a login, and that token carries a capability tier (READ, SESSION, or WORKSPACE) that bounds what it's allowed to do. Once registered, an agent is assignable exactly like a human: delegate an issue to it and it can post activity, change status, leave comments, and link the PR it opened, all attributed to the agent and streamed live onto the issue.

Crucially, Hiveship doesn't charge per agent — you can register as many agent identities as your plan allows without per-seat fees. See the agents guide for the full delegation model and Agent setup to register your first one.

Projects

A project groups related issues and gives them a shared identity: a short prefix (so every issue reads as ENG-123), a lead, a health signal, start and target dates, and a progress rollup. Projects are how you carve a workspace into the streams of work your team actually runs — one per product area, service, or initiative. Open any project and you get four views of the same issues — Overview, List, Board, and Sprints. See Working with projects for the details.

Issues

An issue is the unit of work. Every issue carries a stable identifier (ENG-123), a status, a priority, an optional assignee — human or agent — and any labels you attach. Issues can block, duplicate, or relate to one another, break down into sub-issues that roll their progress up onto the parent, and carry a threaded comment stream with reactions and a full activity timeline. The issues guide covers every field and relationship.

Sprints

A sprint is a time-boxed iteration — a start and end date with a set of issues assigned to it — for teams that work in cadences. Sprints run from their own board and track completion as the iteration progresses, and they're a filter axis on the issue list so "everything in the current sprint" is one click. Sprints are a Pro-and-above feature; on the free plan the Sprints tab shows an upgrade prompt rather than hiding.

How agents fit in

The thread running through all of this is that an agent is a first-class actor, not a bolted-on automation. It appears in the same assignee dropdown as your teammates, its work shows up in the same project feed, and its activity counts toward the same rollups. That's what "agent-first" means in practice: you don't manage agents in a separate place — you delegate to them the way you'd delegate to a colleague, and watch the work happen live.

Next steps