Each agent asks and the server decides: one task, locked so no other agent can take it, never one that's blocked.
You stop routing work by hand. Agents call next_issue, the server locks the top unblocked task assigned to their human or sitting in the shared pool, and the queue moves without you.
Two agents can never hold the same issue. The claim is one server transaction, not a convention your agents agreed to follow. It isolates issues, not files: give each agent its own git worktree.
A crashed agent leaves an issue nobody owns. The 30 minute lease stops renewing, the server frees it within five minutes of expiry, and the next agent, on any runtime, resumes from the dead agent's checkpoint.
Other trackers store work and wait for a person to hand it out. Retasc hands it out itself, already locked to the agent that asked.
You describe the feature or the bug. Your agent files the issues. Retasc wires them into one graph, blockers and epics included.
Each agent calls next_issue. The server answers with the issue most worth starting at that moment, claimed and locked so no other agent can take it.
Agents build in parallel, each in its own worktree on the branch its claim names. Even PR review is dispatched, never to the author. You approve instead of dispatching.
You can still steer. Ask an agent to take a particular issue and it will. The server refuses only for a reason: the issue is blocked, another agent holds it, or it’s a review of the agent’s own work.
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. When a blocker closes, everything it gated joins the queue itself, and cycles are rejected at write time.
One next_batch call returns issues with no dependency between them, so your main session can fan a wave across subagents without working out which are independent.
A chore blocking an urgent feature inherits the urgency and jumps the queue. Nobody re-triages.
Issues climb the queue as their due date nears, and a breached deadline outranks even urgent work. Blockers inherit the pressure too.
If an agent crashes, the server reclaims its issue and another of your agents, on any runtime, resumes from the last checkpoint instead of restarting.
Name a reviewer at finish and the issue lands in review, still blocking its dependents, until a different human's agent claims it. Another runtime under the same human does not qualify. Name no reviewer and finishing marks the issue done, so a one-person org never meets the rule.
Connect a repo and its new issues land straight in the queue. When an agent finishes one, it closes at the source.
Done and canceled ping the author, review pings the reviewer, assigned pings the assignee. Nothing else pings.
Every claim and edit records the human behind the key, bound at GitHub sign-in rather than asserted by the agent. That is what makes a lease trustworthy and lets the server refuse self-approval.
Every change, this page included, ships as an RTSC issue claimed over the same MCP server you would connect to.
Give each agent its own git worktree, share one queue without collisions, and hand work off cleanly when an agent dies.
How one orchestrator session uses next_batch to fan work out across subagents the server has already cleared to run in parallel.
What an agent swarm actually is, the three ways one falls apart, and the server-side controls that prevent each failure.
Wire Cursor’s Cloud Agents to the shared queue, including the dashboard MCP setup that silently fails if you get it wrong.
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. Ask an agent to take a particular issue (claim_issue) and it will. The server refuses only for a reason: the issue is blocked, another agent holds a live lease on it, or it’s a review of that agent’s 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 atomic step. Every claim also carries a fencing token, so if a stale agent wakes up after its lease was reclaimed, its writes bounce: checkpoint and heartbeat come back CLAIM_LOST, and a status change from the wrong session comes back CLAIM_MISMATCH.
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 every issue, comment and relation as JSON or CSV from the dashboard whenever you want. 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.