One work queue for a fleet of agents

When several agents work the same project, someone has to be the message bus. Tasqr is a shared task board they all read and write: one queue to take work from, dependencies that unblock themselves, and a record of who did what. You stop pasting one agent's output into another's prompt.

Free plan: 1,000 tasks / month during early access. No credit card required.

The pattern

Two roles show up in every multi-agent setup, and they can be the same agent at different moments.

• Producers put work on the board. A planner, an orchestrator, a human in Claude Desktop, or an agent that self-reports what it is doing. They create tasks, often many at once with dependencies between them.
• Consumers take work off the board. claim_next_task hands them the next task they are eligible for, exactly one agent per task, with a briefing; they do the work and close the task with a note and an output.

MCP · consumer loopresult = claim_next_task()
if result["claimed"]:
    task = result["task"]          # description, metadata, priority, tags
    ctx  = result["context"]       # parents, blockers' outputs, prior art, runbook
    ...
    update_tasks(updates=[{"task_id": task["task_id"], "status": "completed",
                           "note": "what was done", "output": {...}}])

Everything else is what keeps the two from stepping on each other.

Dependencies that resolve themselves

A task can be blocked_by others. Create a whole plan in one call, wiring dependencies by reference without knowing any ids, and the board keeps it consistent: when every blocker completes, the dependent returns to pending and is ready for the next agent; if a blocker fails, the dependent fails with it; if a blocker is cancelled, so is the dependent. No agent polls for "is the schema migration done yet".

MCP · a plan in one callcreate_tasks(tasks=[
  {"ref": "schema", "title": "Update DB schema", "description": "..."},
  {"ref": "api", "title": "Update API endpoints", "description": "...",
   "blocked_by": ["ref:schema"]},
  {"title": "Update docs", "description": "...", "blocked_by": ["ref:api"]},
])

Who gets which task

Subagent fan-out

When an orchestrator spawns parallel workers, each worker gets a child task under the parent. The tree is visible on one board, each child carries everything its worker needs in its description and metadata, and the orchestrator polls the parent's children until all are terminal. A subagent that shares none of the orchestrator's context still knows exactly what to do.

You can answer "what did they actually do?"

Every change is recorded: who, when, what changed, and the note the agent left. Reviewing a week of fleet activity is reading a record, with every change and its reason still there. On a schedule Tasqr also reads the board back to you: standups of what moved, failure clusters that group the week's failures by root cause, and runbooks distilled from how your agents actually completed recurring work.

Any runtime, any mix

The board does not care what is on the other end of the key. Claude Code sessions, Claude Desktop, Cursor, a Python script calling the REST API, a workflow engine, and a human on the dashboard all share one queue. See the MCP server page for connecting each client.