Post 02 · 2 August 2026 · My Fordyce
Three agents are not three times faster
You opened a second terminal because the first one was working. Here is what happens next, why it is a concurrency problem rather than a model problem, and what an MCP server for project management has to do to fix it.
In short. Running two or three AI coding agents against one codebase does not multiply your output, because nothing arbitrates between them. They pick the same ticket, overwrite each other's finished work, and retry failures all night without counting. None of that is a model problem. It is an ordinary concurrency problem: multiple workers, shared state, no arbitration. The fix is the one databases have used since the seventies. Make claiming atomic so only one agent can hold a ticket, version every write so a stale one is refused, expire the claim so a dead agent releases it, and record every attempt so the next agent reads what the last one tried.
You opened a second terminal window. The first agent was doing fine, chewing through a refactor, and you had a list as long as your arm. So you started another one and gave it something else off the backlog.
For about twenty minutes it felt like a promotion. Two workers. Same you.
Then the first agent finished and its diff had a hole in it. A file it had rewritten came back carrying somebody else's version. You spent the next half hour in git diff working out which half of the work survived, and by the time you understood it you had lost more time than the second agent saved.
That is the part of agentic coding nobody sold you.
You became the message bus
Here is what makes it worse. The fix, in the moment, is you.
You read the first scrollback. You read the second. You work out who is touching what. You tell the second agent to stay out of the auth module because the first one is in there. You remember, because nothing else does, that the migration has to land before the endpoint.
That is a job. It is called coordination, and until you opened the second window it was free, because there was one worker and it was already in your head.
The reading grows faster than the output does. That is why the second agent felt like a win and the fourth feels like a second job.
Count what happens when you add the third. Three scrollbacks. Three sets of assumptions to hold in your head. Three chances that two of them reach for the same file. The models are not the constraint here. The models are good. You are the constraint, and you became one the moment there was more than one of them.
The four ways it actually breaks
Worth naming these separately, because they have different causes and only one of them looks like a bug while it is happening.
Two agents pick the same work
Both read the same backlog. Both see the same top item. Neither has a way to say "mine" that the other one can see. This is the common case, and it is pure luck how long you go before it bites.
Finished work gets quietly erased
One agent reads a record, thinks for six minutes, writes back what it decided. In those six minutes another agent changed the same record. The write is built on a version of the world that no longer exists, and it lands anyway, because nothing checked. This is the expensive one. You do not find out from an error. You find out from a bug report.
The all-night retry
You leave one running. It attempts a ticket, fails, attempts it again, fails again. Nothing is counting. In the morning there are forty attempts against work that was never going to land because the requirement was wrong, and the token spend is real money.
The agent that finished and left nothing
The session ends. Whatever it learned about why the first approach did not work goes with it. The next agent picks up the same ticket and walks into the same wall, and you get to watch it happen twice.
Why the obvious fixes don't hold
Everyone tries the same three things first. We did too.
A markdown file for the backlog. It works with one agent. With two it fails in a specific way: reading a file and writing it back is not one operation. Both agents read TODO.md, both decide, both write. The second write wins the whole file. You have not built a backlog, you have built a race.
Git branches. Branches are a merge answer, not an assignment answer. They tell you what to do once two people have worked on the same thing. They do not stop the two people from working on the same thing, which was the cost you were trying to avoid.
Telling the agents to check with each other. This is the one that feels like it should work. An agent is optimistic, and it is not in the room with the other one. It will happily write "checking whether anyone else is on this" and then proceed, because there is nothing to check against. Politeness is not a lock.
It was never an intelligence problem
Once the four failures are written down, what they have in common is obvious, and it is a little deflating.
Every one of them is a concurrency problem. Multiple workers, shared state, no arbitration. Databases worked this out in the seventies, and the answers are old and boring and exactly right: make claiming atomic, put a version on every write, give the claim an expiry so a dead worker cannot hold it forever, and keep a log so the next worker knows what the last one did.
It feels new because the workers are new. The problem is not. So the missing piece was never a smarter agent. It was somewhere for the agents to agree.
Why a wrapper can't do this
There are plenty of project-management MCP servers now. When we went through the public MCP directories in July 2026, every one we found wrapped somebody else's tracker: Linear, Jira, Trello, Atlassian, Task Master. Claude Directory's project-management category listed five servers and all five were integrations.
That distinction is not branding. A wrapper can only expose what the tracker underneath it already does, and the trackers underneath were designed for humans, who negotiate by talking. There is no "claim this atomically and give me a lease" in an API built on the assumption that a person will notice they are both assigned to the same issue. The wrapper can create tickets and move them between columns. It cannot arbitrate, because arbitration has to happen in one write inside the system of record, and the wrapper is not the system of record.
What a first-party MCP server does differently
My Fordyce is a backlog with a control plane on it, and the MCP server is part of the product rather than a shim in front of it. Your assistant talks to it directly over the Model Context Protocol, the open standard Anthropic published in November 2024, so there is nothing to install on your machine. Thirty-seven tools, twelve of which exist only to answer the question "who is doing what right now." These are the parts that speak to the four failures above.
- Claiming is atomic. An agent asks for work and gets one ticket with a lease token. If two ask in the same moment, one wins and the other is told plainly that it is taken, then handed something else. There is no window where both think they have it, because the decision happens in a single write rather than in two agents' heads.
- The claim expires on its own. The default lease is 900 seconds, settable per project from a minute to a day. An agent still working heartbeats to hold it. An agent whose process died does not, and the ticket comes free. Reclaim is lazy: the expired lease releases the moment another agent asks for work, so recovery runs at the speed of your fleet rather than on a timer.
- Every write carries a version. If the record moved while the agent was thinking, the write is refused and the agent is told what changed and who changed it. It rereads and decides again. That six-minute gap stops being a silent overwrite and becomes a retry.
- Attempts are records, not vibes. Who held it, how it ended, the note they left behind, the branch it produced. When a ticket comes back around, the next agent reads what the last one tried before it starts. The wall only gets hit once.
- Failure has a ceiling. Five unsuccessful attempts on one ticket, configurable per project, and the dispatcher stops handing it out and parks it for you. This is a spend guard. It is the difference between finding a bad ticket in the morning and finding a bad ticket and a bill.
- There are caps on work in flight. Five live leases per agent identity, fifty per project. An agent that is slow, or rate-limited and crawling, cannot sit on half the backlog while everything else waits behind it.
- Sprints outrank priority. Starting a sprint is how you point the fleet at one iteration, so its tickets go out ahead of everything else, including a critical item in the general backlog. An agent can schedule work into a sprint you have not started. It cannot add to the one that is running. The most it can do there is tell you it thinks it should.
None of that is clever, and it is not supposed to be. It is the boring machinery that has to exist under a fleet before adding a worker makes you faster instead of poorer. The full tool reference lists every one of the thirty-seven, and the comparison page covers where this sits against Linear, Jira and GitHub Projects.
What we are not claiming yet
We have not published a claim about running agents on more than one machine against the same backlog. The design points that way, because the arbitration lives in the database rather than in any one client, but we have not run the two-machine test. Until we have, it is an expectation, not a claim.
And the category gap has a shelf life. First-party is true of the directories we can see today. It is an obvious hole and it will not stay empty, so the advantage here is timing rather than a moat.
Coordination is not competence
Worth being clear about what is still on you.
It does not make the agent better at the work. A model that writes a poor implementation will write a poor implementation with a lease on it. It does not review anything, which is why tickets land in awaiting_review and why that is a human word. And it cannot rescue a badly written ticket. If the requirement is wrong, agents will fail at it in sequence until the ceiling parks it, which is faster than failing all night but is not the same thing as being right.
What it does is stop the second agent from costing you more than it earns. That is a smaller promise than most of what is written about agents right now. It is also one we can hold.
Answers
What is an MCP server for project management?
An MCP server exposes a tool to an AI assistant over the Model Context Protocol, the open standard Anthropic published in November 2024. A project-management MCP server lets an assistant read and write a backlog directly instead of you pasting tickets into the chat. Most are wrappers: going through the public MCP directories in July 2026, every project-management server we found sat on top of somebody else's tracker, such as Linear, Jira, Trello, Atlassian or Task Master. My Fordyce is the tracker and the server in one, which is what makes arbitration between agents possible at all. Thirty-seven tools, twelve of them dedicated to coordination.
Can I use this as a Claude Code project tracker?
Yes, and Claude Code is the path we recommend first. You add one MCP endpoint and a key, and the assistant can list ready work, claim a ticket, heartbeat while it works, and hand back a branch. There is no runner to install and no daemon on your machine. The VS Code extension covers the same ground inside the editor, and the ChatGPT connector reaches the same backlog through its connector settings with the same key-based setup.
Can an AI agent manage my backlog on its own?
Partly, and the boundary is deliberate. An agent can create tickets, fill required fields, split epics, flag duplicates, claim work, and schedule items into a sprint you have not started yet. It cannot add to the sprint that is already running, and it cannot approve its own work, because finished tickets land in awaiting_review. Spend is bounded as well: five unsuccessful attempts on one ticket and the dispatcher stops handing it out and parks it for triage, and no single agent identity can hold more than five live leases at once.
Is this a Linear alternative for solo developers?
It is worth comparing if your problem is agents rather than people. Linear is built for teams of humans coordinating with each other and it is very good at that. My Fordyce is built for one person coordinating several agents, which is a different arbitration problem: leases, version checks and attempt records rather than assignees and cycles. It is $30 a month and the demo needs no account. If you have a team of humans and no agents in the loop, Linear is probably still the better answer.
Notes. MCP directory survey conducted 26 July 2026 across Claude Directory, mcpmarket listings and the awesome-mcp-servers GitHub lists. Product behaviour described here was read from the My Fordyce source on 30 July 2026: MCP surface v2.7.1, thirty-seven tools. Defaults are configurable per project and may differ on yours.