Execution isolation
Worktrees, branches and VMs stop agents sharing one checkout. They do not decide who owns one backlog commitment.
Multi-agent comparison · checked 2026-08-11
Several products can run agents at once. The useful question is what happens when those agents reach for the same commitment — and who can prove what happened afterward.
Published boundary: Tasq 0.4.2 ships Local for consumers sharing one user-owned ledger on one machine and a separately operated Server for authenticated remote coordination. Managed Cloud is unavailable.
Worktrees, branches and VMs stop agents sharing one checkout. They do not decide who owns one backlog commitment.
A lead can split work among its own subagents. The coordination state normally belongs to that parent workflow.
Independent runtimes need a shared claim, attempt, evidence and decision history that survives any one session.
Same backlog test
Every row is limited to first-party documentation or a normative protocol specification. An inference label means the classification is ours, not the vendor's wording.
| System | Parallel behavior | Collision boundary | Completion boundary |
|---|---|---|---|
| Tasq Local + Server v0.4.2 | A live expiring claim hides the commitment from another actor's default next-work selection; expiry permits a higher-fence reclaim without rewriting attempt history. | Coordinates who may work the commitment. It does not create a Git worktree or merge code. | A successful runtime attempt does not complete the commitment; evidence and, when configured, an independent decision remain separate. |
| Claude Code agent teams | Task claiming uses file locking to prevent two teammates claiming the same task; completed dependencies unblock downstream tasks. | Agent-team teammates are not worktree-isolated. Anthropic advises partitioning files because same-file edits can overwrite one another. | Hooks can block TaskCompleted, while the docs also list lagging task status as a current limitation. |
| BeadsInference | Atomic claim is a first-class operation, and Dolt-backed merge and sync let separate clones reconcile. | Coordination is over issue records; it does not arbitrate concurrent edits to the repository files an agent touches while working. | Closure is a status transition on the issue. Durable memories are kept separate from open work, and old context can be semantically compacted without deleting the operational record, but completion is not gated on an observable receipt. |
| GitHub Copilot agentsInference | GitHub documents multiple sessions running in parallel and the Copilot app can isolate sessions in separate worktrees or cloud sandboxes. | Isolation protects working copies; GitHub review and merge gates reconcile proposed repository changes. | The documented handoff is a pull request reviewed by a human, with iteration through comments or further commits. |
| GitHub Copilot CLI /fleetInference | The orchestrator evaluates dependencies and runs suitable subtasks in parallel. | The source describes parent-managed subagents rather than a neutral shared backlog used by independent runtimes. | The main agent manages the workflow and dependencies and integrates subagent results into the parent request. |
| OpenAI Codex appInference | Built-in worktrees give parallel agents isolated copies of the same repository. | Worktree isolation prevents agents touching the same checkout; a human reviews, checks out or continues each change set. | The cited product page documents diff review and local checkout, not a shared commitment/evidence decision state machine. |
| Cursor Background AgentsInference | Each agent clones the GitHub repository into an isolated Ubuntu machine and works on a separate branch. | Separate machines and branches isolate execution; repository handoff happens through pushed changes. | The cited page documents status, follow-up and takeover, not an independent evidence-bound completion decision. |
| MCP Tasks and A2A TasksInference | Clients can list, poll, stream or cancel multiple executions; the specifications define execution lifecycles and interrupted input states. | The cited specifications do not define an exclusive claim over an external shared backlog item. | Their completed state means the protocol task execution completed; neither specification defines a separate organizational commitment decision. |
Defensible seam
Claude agent teams are the closest overlap and already demonstrate atomic claiming inside one vendor team. Tasq is useful when the runtimes are independent and their coordination truth must outlive them.
What Tasq does not do
Claim-level provenance
Published Local coordinates CLI/MCP consumers sharing one user-owned ledger on one machine. The published self-hosted Server coordinates authenticated remote clients; managed Cloud is unavailable.
One experimental Claude Code team per lead session; the task/team files are stored locally and in-process teammates do not resume with /resume.
Repository issues for coding agents. Tasq targets cross-domain commitments, keeping evidence, domain time and external observations as kernel concerns while goals, areas and cadence live in a bundled planning profile.
Agent apps let third-party agents use the same issue, pull-request-comment and Agents UI entry points. The cited pages do not specify an expiring cross-agent claim/fence contract.
This is orchestration inside Copilot CLI, not a cross-vendor coordination protocol.
The cited page documents multiple Codex agents, not a vendor-neutral backlog lease shared with other runtimes.
The cited page does not document a shared claim/reclaim backlog contract across agents.
These are interoperability protocols for executions, not backlog products. This classification is an inference from their normative data models.