Each agent asks and the server decides: one task, locked so no other agent can take it, never one that's blocked.
Agents call next issue and the server locks the top unblocked task from their lane or the shared pool, ranked by effective priority at that moment. You're not the bottleneck anymore.
Two agents can never hold the same issue. The claim is one server transaction, not a .md file your agents are supposed to follow. One git worktree per agent, so they never clobber each other's files.
Agents stop for silly reasons: rate limits, closed laptops, stalled sessions. No heartbeat: the lease expires and the issue rejoins the dispatchable pool. Another agent resumes from the 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. Point an agent at any 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.
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.
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. 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 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.
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.