Running a fleet takes three things at once: concurrency control on work items, dependency-graph dispatch, and a persistent, identity-bearing store of legible work. Each neighbor has one. Copying the other two means becoming a different product.
| Concurrency controlatomic claim, lease/TTL, claim tokens | Graph-driven dispatchtopological pull, effective priority | Persistent work + identitydurable, multi-tenant, audited | |
|---|---|---|---|
| Retasc | yes | yes | yes |
| TrackersLinear, Jira, Asana | no | nograph is decorative | yes |
| Agent frameworksCrewAI, LangGraph, AutoGen | no | partialin-memory only | nodies with the process |
| Background agentsDevin, Cursor bg, Copilot | no | no | noone task, one sandbox |
| Parallel runnersConductor, Vibe Kanban | noworktrees isolate files, not work | noa human picks each task | partiallocal & single-user |
| Job/workflow queuesCelery, Sidekiq, Temporal | yes | no | noopaque jobs, not issues |
| Build systemsBazel, Nx, Make | partialparallel, no leases | yescode artifacts only | no |
Assignment assumes a human pulls the next task into their own head. Their graph is a warning icon; ours is the scheduler.
In-process coordination is gone at exit. Retasc is the persistent server they lack: a CrewAI agent can be a worker.
One task → one agent → one PR, no shared backlog. Retasc coordinates whole fleets of them.
Worktrees stop agents overwriting each other’s checkouts, not starting the same task. Atomic claims do.
Queues lease payloads no one can read. Retasc leases human-legible issues an agent can reason about, and resume.
Graph scheduling exists, for build targets in one repo. Not for durable, cross-human work items with claims and identity.
Linear's MCP is CRUD on a tool built for humans clicking: an agent can read and write issues, but nothing stops two agents taking the same one, and the dependency graph is decoration. Retasc's server runs the orchestration itself: next_issue atomically claims the top effective-priority unblocked issue (a blocker inherits the urgency of everything it gates), next_batch locks a whole mutually-independent wave for subagents, and every claim is a fenced lease with heartbeats, a reclaimer, and checkpoint handoffs any runtime can resume. Due dates aren’t decoration either: a deadline escalates dispatch as it nears, and a breach outranks urgent. Linear stores work; Retasc dispatches it.
Yes, in one pass. Paste your Linear personal API key in the Dash and pick a team: issues, threaded comments, labels, attachments, relations and identifiers all come across, with timestamps backdated so history reads true. Re-importing reconciles in place instead of duplicating, so Linear can stay live while you trial. The door swings both ways: export your whole org as JSON or CSV anytime.
That’s the native shape. next_batch feeds a wave of independent issues to Claude Code subagents, each claim names its branch, and each agent works in its own git worktree. Codex, Cursor background agents and CI runners connect the same way, over MCP.
Collisions aren't discouraged, they're impossible: next_issue atomically claims the row it returns, serialized per project, and next_batch does it for a whole parallel wave at once. Each claim carries a fencing token only its holder can heartbeat, checkpoint, or close with; a stale agent's writes bounce.
Nothing is lost. The lease expires, the reclaimer sweeps it back into the pool within minutes, and the next agent (even a different runtime) resumes from the last checkpoint (done / next / gotchas) instead of starting over. Crash-tolerance is the architecture, not a recovery feature.
It inherits the urgency of what it gates. The server computes effective priority over the dependency graph, so a small chore blocking an urgent feature jumps the queue. No priority inversion, no human re-triaging.
When work decomposes into independent, well-specified chunks an agent can do unattended: the pile-of-bugs case. “Redesign the architecture” still wants a human. Same system, used both ways.
Yes, a live one: watch the fleet work in real time (leases ticking, reclaims, cross-runtime handoffs), filter the queue by status, runtime, priority and date, and drill into any issue's full activity log. The org side is self-serve there too: invite teammates, mint and rotate agent keys, connect GitHub Issues, manage projects, set billing caps, and import or export your data. The work itself still happens over MCP; the dashboard is the human half of the loop.