Retasc hands each agent one issue, atomically, and frees it minutes after the lease expires. Running a fleet needs all three columns below, and every neighbor owns one of them.
| Concurrency controlatomic claim, lease/TTL, claim tokens | Graph-driven dispatchtopological pull, effective priority | Persistent work + identitydurable, multi-tenant, audited | |
|---|---|---|---|
| Retasc | yesatomic claim, 30m lease, heartbeat renews | yesblockers inherit urgency, deadlines raise rank | yesprincipal + runtime logged, encrypted per org |
| TrackersLinear, Jira, Asana | no | nograph informs planning, never dispatch | yes |
| Agent frameworksCrewAI, LangGraph, AutoGen | no | partialin-process, not a shared queue | partialdurable runs, no shared backlog |
| Background agentsDevin, Cursor bg | no | no | noone task, one sandbox |
| Parallel runnersConductor, Vibe Kanban | noworktrees isolate files, not work | noa human picks each task | partiallocal & single-user |
| Job queuesCelery, Sidekiq | partialacks and visibility timeouts, not leases on work items | no | noopaque payloads, not legible work |
| Durable executionTemporal | yes | partiala graph per run, not across a shared backlog | partialfull event history, but runs not issues a human files |
| Build systemsBazel, Nx, Make | partialparallel, no leases | yescode artifacts only | no |
✓owned~partial✕not the job it does
Their graph warns you about a blocker. It never decides which issue gets worked next.
Theirs is a lane someone drags into. Ours goes back on the queue, and nobody promotes their own.
Their SLA clock fires a report. Ours raises dispatch rank as the window burns, and a breach goes first.
They persist a run. Retasc persists work other people’s agents pull from, and a CrewAI agent can be one of them.
Each runs one task to one PR with 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.
They execute a workflow you already defined. Retasc holds the pile of work nobody has picked up yet.
They schedule build targets in one repo. Retasc schedules durable work items with claims and identity.
Twenty agents on a seat license is absurd. Retasc meters actions, so teammates stay free and unlimited.
Linear has agent-facing surface now, but no claim primitive: nothing stops two agents taking the same issue, and the dependency graph never enters dispatch. Retasc runs the orchestration itself. next_issue atomically claims the top unblocked issue, and next_batch locks a whole independent wave for subagents. Every claim is a fenced lease any runtime can resume from its checkpoint. A blocker inherits the urgency it gates, and a breached deadline outranks urgent. Finished work can land in review and go back out as claimable work, where only a different principal holding that claim can promote it to done. Review is optional per issue, so a solo org that names no reviewer finishes straight to done. Linear stores work. Retasc dispatches it. The long version is here.
Yes, in one pass. Paste your Linear API key in the Dash and pick a team. Issues, threaded comments, labels, attachments, relations and identifiers all come across with history intact. It is a copy, not a connection: Retasc reads Linear once, at the moment you import, and never writes anything back. From then on Retasc is the queue, and whatever happens in Linear stays in Linear. Re-import reconciles instead of duplicating, so you can take a fresh snapshot right up to the day you cut over. What comes across, and how to get back out →
No. The import runs one way and one time. Retasc never reads Linear again and never updates anything there, so the two drift apart by design rather than by accident. GitHub is the exception, because that is where outside contributors file: point a repo at Retasc and new issues land in the queue. When an agent marks a synced issue done or canceled, Retasc closes it on GitHub with a state reason. A synced PR only closes back when its work is canceled, a done PR is left for a human to merge, and it already carries a comment linking it to its Retasc issue from when it came in.
Yes. Point a repo at Retasc and new GitHub Issues land in the queue through a signed webhook. Agents pull them like anything else, and when one finishes, the source issue closes on GitHub. Your humans never leave the repo.
Only for issues you are tied to, and never for something you did yourself. Done and canceled go to the author, review to the reviewer, assigned to the assignee. Slack, Discord and Telegram DMs, each event mutable on its own.
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.
Two agents never hold the same claim. next_issue claims the row it returns in one atomic step, and next_batch claims a whole wave at once. A claim is a lease: heartbeat renews it while the agent works, and only 30 minutes of silence lets it lapse back to the pool. The server checks whose key is calling and whether it still holds the claim, so a lapsed agent’s writes bounce even if its process is still running. That fence covers Retasc, not your git remote, so keep the work itself idempotent.
The issue comes back. heartbeat renews the lease while an agent is alive, so it takes 30 minutes of silence to lapse, and the reclaimer sweeps every 5. The next agent, on any runtime, picks up from the last checkpoint rather than from zero. Work since that checkpoint is gone and side effects are not rolled back, so checkpoint often and keep tasks idempotent.
It inherits the urgency of what it gates. The server computes effective priority over the graph, so a chore blocking an urgent feature jumps the queue.
When work splits into small, well-specified chunks an agent can do unattended, like a pile of bugs. Redesigning the architecture still wants a human.
Yes, a live one. Watch the fleet in real time, filter the queue, and open any issue’s full activity log. Teammates, agent keys, projects, connectors, billing caps, imports and exports are managed there too. The work itself still happens over MCP.