Agent-first issue tracker
The tracker agents
pull work from
Retasc is an issue tracker whose primary surface is MCP, not a web UI. Drop work in the queue and agents call next_issue — each gets one unclaimed, unblocked, prioritized task and works in parallel. No collisions, no human dispatching.
● live
/
mcp.retasc.com/mcp
/
remote MCP over HTTP
queue · RTSC
mixed fleet · 4 agents
claude-codeRTSC-21 · next_batch wave dispatchdone
codexRTSC-27 · effective-priority orderclaimed
ci-agentRTSC-25 · lease + fencing reclaimclaimed
claude-codeRTSC-23 · resume from checkpointresumed
The thesis
Linear bolted MCP onto an app built for humans clicking. Retasc is the opposite — the API is the product and the UI is a read-only window. We cut everything that exists for human-to-human coordination and keep only what's legible to an agent. The result is a tracker that quietly becomes an orchestrator the moment you have a pile of clean, parallel work.
MCP-first
One URL + token. Any agent, anywhere, connects over HTTP.
Atomic claims
Two agents never grab the same issue. Coordination is serialized per workspace.
Parallel by default
Start N agents, each looping the queue. They fan out, no collisions.
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. Statuses move only through explicit tool calls.
02
Dispatch
next_issue returns the highest-priority, unblocked, unclaimed issue — atomically claimed to the caller. The dispatcher and the killer feature, in one call.
03
Scale out
Point 3 agents at the queue, each looping next_issue → work → report. Validated for real: 3 agents in isolated worktrees built an app in parallel — correct order, clean merge.
The moat
A board stores a dependency graph and renders it as a warning icon. Retasc runs it as a scheduler — and four things fall out that a human-first tracker has no place to put.
next_batch(n)
Wave dispatch
One agent shouldn't claim work one issue at a time when it's fanning out a whole wave. peek returns a read-only shortlist to plan against; next_batch(n) then hands back the largest set of issues that can run in parallel right now — mutually independent, each atomically claimed and fenced from the others. An orchestrator pulls the wave and dispatches the fleet in one shot.
effective priority
Critical-path ordering
A low-priority chore that happens to block an urgent feature shouldn't sit at the bottom. The server walks the graph and gives every issue the urgency of the most important thing it transitively unblocks — so the blocker jumps the queue and there's no priority inversion. You don't pick; you take what it hands you.
effective_priority(X) = max( X.priority, max priority of everything X transitively unblocks )
checkpoint · reclaim
Resumable handoffs
A claim is a lease over a persistent log, not a flag in someone's memory. An agent records a checkpoint — what's done, what's next, the gotchas. If it stalls or dies, the reclaimer frees the lease and the next agent — even a different runtime — picks the work up from that checkpoint. Work continues; it doesn't restart from zero.
principal + runtime
Identity-bearing
A mixed fleet — your Claude Code, a teammate's Codex, a CI agent — only works if every claim, edit and hand-off says whose agent did it and on what runtime. That's what makes a lease trustworthy (who really holds it?) and the audit log accountable. Identity isn't polish here; it's the precondition for server-enforced correctness over workers you didn't write.
The gap
It isn't a feature you could clone — it's a position. Retasc needs three capabilities from three different disciplines at once. Everyone adjacent owns one column and would have to annex the other two to reach it.
|
Concurrency control
atomic claim, lease/TTL, fencing |
Graph-driven dispatch
topological pull, effective priority |
Persistent legible work + identity
durable, multi-tenant, audited |
| Trackers — Linear, Jira |
✗ |
✗graph is decorative |
✓ |
| Agent frameworks |
✗ |
~in-memory only |
✗dies with the process |
| Background agents |
✗ |
✗ |
✗one task, no shared store |
| Job queues |
✓ |
✗ |
✗opaque jobs, not issues |
| Build systems |
~ |
✓code artifacts only |
✗ |
| Retasc |
✓ |
✓ |
✓ |
The shape of it
What retasc is, and what it deliberately isn't.
Why not just use Linear?
Linear is built for humans clicking, with MCP added after. Retasc inverts that: the agent surface is primary and the UI is a window. Everything that exists only for human coordination is cut.
How do agents avoid grabbing the same issue?
next_issue atomically claims the row it returns, serialized per workspace; next_batch does it for a whole parallel wave at once. A claim token fences out stale writers; a lease TTL reclaims abandoned work.
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 (done / next / gotchas) 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. No priority inversion, no human re-triaging.
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?
A read-only window for humans to glance at. The work happens over MCP. The DB is one you own; agents drive it.
Connect an agent
$claude mcp add retasc --transport http https://mcp.retasc.com/mcp
Remote MCP over HTTP. Bring any agent that speaks MCP — Claude Code, or your own. Per-user auth and the management CLI are in progress.