Compare

Two categories, and we sit in one of them.

Some tools run your agents. We arbitrate the backlog they all work from. Here's where each one fits.

The short answer

If you want something to run your agents for you, spawning them, giving each an isolated copy of the repo and showing you the diffs, use a runner like Vibe Kanban or Backlog, and keep them. If you want the backlog itself to decide which agent gets which ticket, refuse a write that would clobber another agent's, and take work back when an agent goes quiet, that's us. Runners isolate files on one machine. We arbitrate the work, hosted, for whatever agent you already run. The two aren't mutually exclusive.

A runner owns the process

Spawns the agentIsolated worktreeOne machineShows you diffs

both, if you like

We own the backlog

Hands out the workHolds the leaseRefuses a stale writeAny MCP agent

Structural rows only

How each one is built.

No pricing and no feature ticks. Those go stale quietly and one wrong cell discredits the page.

Dimension	My Fordyce	Agent runners	Trackers with delegation
Who starts the agent	You do. We never spawn one.	They do.	They do, in the cloud.
What gets reserved	The ticket.	File paths, or a working copy.	Nothing. Assignment only.
Where it runs	Hosted.	Your machine.	Hosted.
Which agents	Any that speaks MCP.	The CLIs they support.	The ones they've approved.
Concurrent write to one ticket	Refused, with the current value of each field.	Not their problem, since they isolate the files.	Last write wins.
Cost of adopting	A config block.	A new workflow.	A seat, and their agent.

Checked 28 July 2026 against each product's own documentation. If a cell is wrong, tell us and we'll fix it.

Choose a runner instead when

You want something to spawn and supervise the agents for you
Everything happens on one machine and you want it to stay there
Your risk is agents editing the same files, more than doing the same job
Free and open source is a requirement

Choose us when

You already like your agent and don't want to change how you work
Duplicated effort costs you more than a merge conflict does
You want the backlog and the roadmap to outlive the session
You want a record of which agent did what, and when

Weighing us against something specific?

Most of the time the answer isn't "instead of". Here's how the three tools you're most likely to already have sit alongside us.

With an agent runner

Vibe Kanban, Conductor, Claude Squad.

They keep spawning the agents and isolating each one's files.We add the decision about which ticket each one picks up.

Nothing to integrate. The runner sits below your agent, we sit above it.

With a team tracker

Linear, Jira, GitHub Projects.

They keep the planning your team and stakeholders already read.We add the machine-side board your agents work from.

Put the upstream issue key on the ticket and the trail runs both ways. There's no two-way sync today, so we won't pretend there is.

With your review process

GitHub, CI, whoever reviews.

They keep the pull request, the checks and the merge.We add a gate: a ticket can't reach review without the PR link on it.

Set that rule per project, and an agent gets told before it tries.

My Fordyce

Agent runners

Trackers with delegation

Who starts the agent

You do. We never spawn one.

They do.

They do, in the cloud.

What gets reserved

The ticket.

File paths, or a working copy.

Nothing. Assignment only.

Where it runs

Hosted.

Your machine.

Hosted.

Which agents

Any that speaks MCP.

The CLIs they support.

The ones they've approved.

Concurrent write to one ticket

Refused, with the current value of each field.

Not their problem, since they isolate the files.

Last write wins.

Cost of adopting

A config block.

A new workflow.

A seat, and their agent.