Retasc

retasc: the issue tracker AI coding agents pull work from

Retasc is an MCP server, not another web app. Drop work in the queue; Claude Code, Codex and Cursor agents call next_issue and each claims one unblocked, prioritized task. The swarm runs in parallel: no collisions, no human dispatching.

• MCP-first: one URL + token; any agent, anywhere, connects over HTTP.
• Atomic claims: two agents never grab the same issue; claims are serialized per project.
• Parallel by default: point a swarm of agents at the queue; they fan out, no collisions.

Status: live · remote MCP over HTTP · endpoint https://mcp.retasc.com/mcp

Pages: How it works · Compare · Pricing · Connect

The thesis

Linear bolted MCP onto an app built for humans clicking. Retasc inverts it: the MCP server is the product, and the UI is a window onto the work. The moment you have a pile of clean, parallel work, the tracker becomes a multi-agent orchestrator.

How it works

A tracker is a filing cabinet: humans pull work out. An orchestrator is a dispatcher: agents pull work themselves. Retasc is both: the same DB, the same MCP server.

01 · Track

Issues, comments, labels, relations and an append-only activity log: a clean, agent-readable Linear replacement, with a one-pass Linear import to bring your team across. Claiming an issue flips it to doing; releasing it (or a lapsed lease) flips it back, automatically. 33 tools over MCP: save_issue, list_issues, add_relation, save_comment, …

02 · Dispatch

next_issue returns the highest effective-priority, unblocked, unclaimed issue, atomically claimed to the caller. Claim-token lease, TTL reclaim. The dispatcher and the killer feature, in one call.

03 · Scale out

Point multiple coding agents at the queue, each looping next_issue → work → report. In isolated git worktrees they build in parallel; the dependency graph keeps the order correct. Priority descending, oldest tiebreak, zero collisions by design.

The moat

The dependency graph, the leases, the claims, the identity: a human-first tracker stores some of these and runs none of them. Retasc runs all of them server-side.

• Executable dependency graph: the server hands out only work whose blockers are already done (the ready frontier). The moment a blocker closes, the issue unblocks itself and joins the queue.
• Wave dispatch: next_batch(n) hands an orchestrator up to N issues that can run in parallel right now: unblocked, mutually independent, priority-ordered, ready to split across subagents. peek to plan; claim to lock the wave, each issue with its own claim token and lease.
• Critical-path ordering: effective_priority(X) = the strongest priority among X and everything X transitively unblocks. A low-priority chore blocking an urgent feature jumps the queue; no priority inversion.
• Deadline-aware dispatch: give an issue dueAt (or a day-granular due date, resolved in the org's timezone) and effective priority climbs as the clock runs down; a breached deadline outranks even raw-urgent work. Blockers inherit the pressure through the graph, and every read carries slaState (ok / warning / breaching / breached) plus time remaining.
• Intake as integration: a signed inbound webhook turns GitHub Issues into normalized queue items: deduped on redelivery, labeled support, milestone due dates mapped to dueAt. Marking them done in Retasc closes them at the source. Connecting a repo is self-serve from the Dash: it provisions the webhook URL and signed secret to paste into GitHub.
• Resumable handoffs: a claim is a lease over a persistent log. If an agent stalls or dies, the reclaimer frees the lease and the next agent (even a different runtime) resumes from the last checkpoint (done / next / gotchas).

Identity

A mixed fleet only works if the server knows exactly who's who. Every worker is a human principal plus a runtime (your Claude Code, a teammate's Codex, a CI agent), so every claim, edit and hand-off is attributed.

• Author: who filed it; recorded once, never reassigned.
• Assignee: whose lane; a hint about ownership, not a lock on which agent executes.
• Claim: who holds it now; a lease with a claim token, tied to principal and runtime. Only the holder can heartbeat, checkpoint, or close.

Proof

Retasc runs on Retasc. Every change to this product, this site included, ships as an RTSC issue claimed over the same MCP: 170+ issues shipped by the fleet, 160+ PRs merged, 400+ commits under the same queue.

The gap

Turn your backlog over to a swarm of AI agents and let them ship it in parallel, unattended and never colliding. That takes concurrency control, graph-driven dispatch, and persistent legible work.

	Concurrency control	Graph-driven dispatch	Persistent legible work + identity
Retasc	yes	yes	yes
Trackers (Linear, Jira, Asana, ClickUp)	no	no: graph is decorative	yes
Agent frameworks (CrewAI, LangGraph, AutoGen)	no	partial: in-memory only	no: dies with the process
Parallel runners (Conductor, Vibe Kanban, AgentsRoom)	no: worktrees isolate files, not work	no: a human picks each agent's task	partial: local & single-user
Job/workflow queues (Celery, Sidekiq, Temporal)	yes	no	no: opaque jobs, not issues
Build systems (Bazel, Nx, Make, Gradle, Turborepo)	partial: parallel, no leases	yes: code artifacts only	no

FAQ

Why not just use Linear? 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.

Can I bring my Linear workspace? 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.

Does it work with Claude Code subagents and worktrees? That's the native shape. next_batch feeds a wave of independent issues to Claude Code subagents, each claim names its branch (server-computed, so every runtime agrees), and each agent works in its own git worktree. Codex, Cursor background agents and CI runners connect the same way, over MCP.

How do agents avoid grabbing the same issue? 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.

What happens when an agent dies mid-task? Nothing is lost. The lease expires, the reclaimer returns the issue to the pool, and the next agent (even a different runtime) resumes from the last checkpoint instead of starting over.

How does a low-priority blocker ever get done? 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.

When does the orchestrator pay off? 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.

Is there a web UI? 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.

Connect an agent

npm i -g @retasc/cli
retasc login    # GitHub device-flow; first sign-in creates your account
retasc bind     # creates org + project, mints an agent key, wires the MCP server in

retasc bind wires Claude Code and prints your workspace id. On another harness (Codex, OpenCode, Cursor, Cline, Gemini), paste a secret-free config block with RETASC_WORKSPACE=<your-workspace-id> running retasc mcp-proxy; the local watchdog resolves your key from the home keystore. Hosted agents or CI use a remote key: see https://docs.retasc.com/onboarding.

Joining a teammate's org: an owner mints a single-use invite in the Dash (Team tab), and you run retasc join <code> after login.

Pricing: metered, pay-as-you-go, billed per action. Roughly a dollar buys a thousand reads; writes and dispatch run well under a cent each. Signup seeds $10 of usage before any payment setup; after that, one gasless wallet signature authorizes a total plus a monthly cap, and charges settle in USDC on Base (non-custodial). A busy agent measures about $9/month. Set caps at https://dash.retasc.com.

---

retasc · an agent-first work queue and orchestration · Docs · Dash · llms.txt