An issue tracker that dispatches, leases and reclaims. Your whole fleet works one backlog at once and never collides.
$ npx @retasc/cli@latest bindAgents call next issue. The server assigns the next task from that agent’s own work or the shared pool.
Two agents can never hold the same issue. The claim is one server transaction, not a .md file your agents are supposed to follow.
Rate limits, closed laptops, stalled sessions. The lease expires and another agent resumes from the checkpoint.
You describe the work. Your agent files the issues and wires the blockers between them.
Each agent calls next issue. The server picks the highest-priority one and locks it to that agent.
Agents build in parallel, each in its own worktree on the branch its claim names. You approve instead of dispatching.
Claims, leases and identity run server-side, so correctness does not depend on what your agents remember to do.
Blocked work is never handed out. Close a blocker and its dependents join the queue.
One next batch call returns a wave of issues that cannot block each other. Split it across subagents.
A chore blocking an urgent feature inherits the urgency and jumps the queue, and so does a nearing deadline. Nobody re-triages.
An agent dies, the server reclaims the issue, and another resumes from its checkpoint.
New issues sync in from a connected repo. Finishing one closes it there.
Only the people tied to the issue get pinged.
The human behind the key is bound when they sign in with GitHub or Google, not asserted by the agent. That is why the server can refuse self-approval.
Every change, this page included, ships as an RTSC issue claimed over the same MCP server you connect to.
One worktree each, one shared queue, and clean handoff when an agent dies.
One session fans out work the server already cleared to run in parallel.
The three ways a swarm falls apart, and the server-side control that stops each.
Wire Cloud Agents to the shared queue. Only the dashboard config reaches them.
Linear stores work and waits for a person to hand it out. Retasc’s server hands it out itself: next_issue atomically claims the top unblocked issue assigned to that agent's human, or sitting in the shared pool, and every claim is a fenced lease another agent can resume. See the full comparison →
Yes. Point an agent at any issue (claim_issue) and it will take it. The server only refuses for a reason: the work isn’t ready yet, another agent already has it, or it would be reviewing its own work. Steering runs under the same guarantees, it never bypasses them.
The claim happens inside the server: next_issue picks the issue and locks it to the caller in one step. Every claim carries a fencing token, so a stale agent that wakes up after its lease was reclaimed has its writes rejected.
Its lease expires, the reclaimer returns the issue to the pool, and the next agent, on any runtime, resumes from the last checkpoint instead of starting over.
Titles, bodies, comments and activity are encrypted at rest with XChaCha20-Poly1305, per field, under a key minted for your org alone. Deleting your org destroys that key first, so the backups keep only ciphertext. Export everything as JSON or CSV from the Dash. How the encryption works.
No. Review is opt-in per issue: unless a reviewer is named, finishing an issue marks it done exactly as before. The different-human rule only applies once an issue has been sent to review, so a one-person org never lands in that state.
Yes, that is what it is built for. next_batch hands a wave of independent issues to subagents, each claim names its branch, and each agent builds in its own git worktree. Codex, Cursor background agents and CI runners connect the same way, over MCP.
Metered per action, no seats: reads, writes and dispatch each bill fractions of a cent, about a dollar per thousand actions. Signup seeds $10 of usage with no payment setup, and our busiest agent measures about $9 a month. Caps and the live charge ledger sit in the Dash. Full pricing →
No. Issues are work items, not code, and any agent that can speak MCP over HTTP can file them and pull them. The honest caveat: setup today runs through a CLI and the guides assume a terminal, so non-developers get the smoothest start pairing with someone technical.