You are already running a multi-agent system

It is Tuesday. You have one session open and a list that will not fit in the day. The agent is grinding through a rename that touches thirty-odd files, and you are half watching it while you write the ticket for the thing you will do next. This is the good version of the job. The agent is fast, the work is real, and you are the one deciding what happens, in what order, with what left for tomorrow.

You do not think of this as an architecture. It is just how the work goes: you, one agent, one thing at a time. Nobody drew it on a whiteboard and nobody chose it. It arrived the day you started letting an agent write the code, and it has held up well enough that you have never had a reason to look straight at it.

It is an architecture, though. It has properties, and the properties are about to start costing you.

The architecture nobody chose

Single agent development has a simple shape. You hold the plan. The agent holds the context. Work moves through one line, one item at a time, and you stand at both ends of it, choosing what goes in and checking what comes out.

That shape has real advantages, which is why it is the default. Nothing collides, because nothing runs in parallel. There is exactly one version of what is happening and it lives in your head. Every change gets a human look before it lands.

It also has a ceiling, and the ceiling is not where people expect. Your agent is not the slow part. A repository at any moment holds several pieces of work that never touch each other: a migration, a flaky test, a copy change on a marketing page, an API client that needs regenerating. Those things are independent. In a single session they happen one after another anyway, because there is one worker and one line. A better model compresses each item. It does not change how many can be in flight.

Underneath that sits a quieter cost, and it is the one that compounds. Something has to decide what happens next, and that something is you. You choose the next item. You carry what is half finished from one session into the next. You remember that the migration is blocked on a decision somebody owes you. None of that looks like work, and all of it is.

Then there is what the session knows. An agent spends its first minutes working out what is true: reading files, running the suite, finding that a fixture is stale and the helper it wanted was deleted in March. That understanding is real, and it evaporates when the session closes. The code survives. The reasoning does not, and the next session pays to rediscover it in both time and tokens.

And when the agent does finish, nothing moves until a person looks. On a good day that is minutes.

Two sessions is a different system

Nobody sits with that for long. The escape hatch is obvious and everybody finds it: open another session. A second tab, a terminal agent running beside the one in the editor, or a colleague who opened their own this morning without mentioning it.

That is the moment the system changes category, and the reason is not the tooling. Two properties do it.

The first is independent context. Each session holds its own picture of the codebase, formed at a different moment, and neither one can see what the other is doing to it. They can pass each other a note, but they do not share the working memory the decision would need.

The second is shared mutable state. They both write to the same repository, the same branches, the same backlog, the same deploy. Whatever one does lands in the world the other is still reading.

Independent workers writing to shared mutable state is the textbook setup for a race. That condition is what defines the system, not the label on the tool. Two windows of the same agent that you opened by hand are in it exactly as much as two agents from different vendors, and the branch cannot tell any of them apart.

Some tools have started coordinating sessions you explicitly group together. Claude Code's Agent Teams, for one, hands a lead's spawned teammates a shared list they claim from, with a lock so two of them do not take the same task. That is a real mechanism, and a bounded one. It lives on one machine, it covers one vendor's sessions that you deliberately made into a team, and the team ends when that session ends. It does nothing for the second tab you opened without ceremony, the colleague running their own agent, or the mix of vendors most teams actually use. Those are the ones still writing to the same branch with no idea the others exist.

Here is the part almost nobody says out loud. People wait to take coordination seriously until they think of themselves as a multi-agent shop, as if there were a line to cross, some headcount of agents at which the problems switch on and you go and buy something for it. There is no line. The problems are a property of two independent workers and one shared repository, and you had both the first time you opened a second window.

So the honest version is uncomfortable and a relief at the same time. You are not deciding whether to become this. You already are, and you have been since some afternoon months ago when one session was not keeping up and a second one obviously helped.

And it did help. That is the part to hold onto. Opening the second session was the right call. The first one had a ceiling and you found the way around it, the way everyone does, and nothing about that was a mistake. What changed is only where one thing has to live. When the work happened in one place, the deciding, who takes what and in what order, happened in your head, and that was enough. Once it happens in several places at once, the deciding has to move somewhere all of them can see, or it stops happening at all.

What it costs a business

For one person the second session is at least a decision. On a team it is closer to the weather. Four developers each working with an agent is four independent contexts writing into one repository, and none of those four people chose to build a parallel system. It assembled itself out of individually sensible decisions, which is why nobody owns fixing it.

Picture a Thursday. One developer asks their agent to fix a webhook that retries too aggressively. Another, two desks away, has had an agent working through the same module since Tuesday and has not mentioned it, because there was nothing worth mentioning yet. Both agents read the file. Both are correct about what they find. Both open a branch and a pull request, and git does its job: either the second one lands on a conflict somebody burns an hour untangling, or the two fixes are close enough to merge and one of them was simply wasted. Nothing was lost, and nothing was gained either. The company paid two developers to fix one webhook, and nothing, at any point, told either of them the other had already started.

The first thing that Thursday costs you is visibility. Everything an agent does happens inside a session, and the board only hears about it if a person stops and files it afterwards. Filing is a separate errand and the errand loses to the next thing. So the tracker drifts from describing what is happening to describing what somebody remembered to write down, and the gap widens quietly, because nothing announces it. Whoever owns the roadmap is planning against the second version.

Which means the same work gets paid for twice. Branches and worktrees keep the two agents from clobbering each other's files, and that is worth having, but they decide nothing about who works on what. Two agents still pick up the same ticket because neither can see that the other started, and the duplication is only caught after both have spent the hours. Those hours never appear on any report, because both agents did in fact deliver something.

Which means, in the end, that delivery stops being forecastable. Planning assumes you can see what is in flight. When the board is a partial and lagging record, and an unknown share of the effort is going into work somebody else already did, every date built on it is a guess wearing a commitment. The estimates were not wrong. They described a system that no longer exists.

The obvious objection is that a team of three does not need any of this, because three people can just tell each other what they are working on. That is true, and it stays true right up until the afternoon somebody forgets. The failure is silent. No error, no alert, just two people who each believe the work is handled. A convention that depends on everyone remembering is not a mechanism, it is a run of good luck being described as a process.

The specific failure modes underneath all this are repeatable, and we wrote them up in Three agents are not three times faster: two agents taking the same ticket, finished work quietly erased, a doomed ticket retried all night, an agent that finished and left no record of what it learned. None of it is an intelligence problem. It is an ordinary concurrency problem, and concurrency problems have known solutions.

Where the deciding lives

So it moves out of your head and onto a board every session reads from. That is the whole shape of it: the deciding happens in one place they can all see, and it happens the same way every time. Part of that is on you, and it is the part a good team already does: a ticket an agent can pick up is one with a scope and an acceptance criterion, the same ticket a new hire could pick up, and a board built for agents can refuse to hand out work that has neither, so readiness stops depending on whether anyone felt like it that day. The rest is arbitration, and it works like this:

• Hand-out is atomic. Claiming a ticket is compare-and-set, so the second agent to ask gets a refusal naming the current holder rather than a duplicate copy of the work.

• Claims expire on their own. A 15-minute renewable lease with a heartbeat roughly every 3 minutes means an agent that dies mid ticket does not sit on it. Reclaim is lazy: the work comes back the moment any agent asks for work.

• Every attempt leaves a record. Who held it, what happened, what they learned, which branch it went to. That is the durable form of the context that otherwise dies with the session, and it is what lets the next agent read the last attempt instead of walking into the same wall.

All three assume a backlog that is hosted rather than local, so it is the same backlog from a second session and a second person, and they assume every write carries the version it was based on, so a stale one is refused and handed back the current values instead of landing on top of finished work. Leases also cap how much a single agent holds at once, a work-in-progress limit that enforces itself rather than one written on a wall, and because every attempt is recorded against the ticket, you can see what each agent did without anyone stopping to file a note.

This is also where agent orchestrators fit, alongside rather than instead. An orchestrator spawns and supervises agents on your machine, which is a real job and a useful one, and what it multiplies is the number of workers. What it does not do is decide, across every session and every person, which worker is allowed to have which piece of work.

That decision layer is what My Fordyce is: a backlog with its own MCP server rather than a wrapper over somebody else's tracker, which is what makes arbitration possible at all. It is 37 tools, 12 of them coordination, one URL and a key, $30 a month. If you want to see where it sits next to the trackers and orchestrators you may already have, the comparison is here, and the Model Context Protocol is the open standard underneath it, so any client that speaks MCP reaches the same backlog.

Common questions

Is running two Claude Code sessions a multi-agent system? Operationally, yes, and the useful part of that answer is what follows from it. Two sessions of the same tool hold separate context and write to the same repository, which is the condition that causes the trouble, so if you are running two you have already inherited the coordination problems rather than being on your way toward them. The useful question is where the deciding lives, and for two sessions on one repository that is a shared backlog they claim work from, before any orchestrator or worktree isolation. Two windows on one repository need arbitration more than they need supervision.

Can multiple developers use AI coding agents on the same codebase? Yes, and the practical question is what they share. A repository on its own is not enough, because it records what has happened rather than what is being attempted, so two agents can be halfway through the same work without either one being able to find that out. What makes it workable is a backlog both agents read from and claim against, so a piece of work is handed out once. My Fordyce arbitrates by agent identity: every agent passes a stable agent_id, claiming is atomic, and a ticket already held is refused to the next agent with a 409 rather than handed out twice. Everyone keeps whichever agent they already prefer.

Where that leaves you

None of this asks you to become a multi-agent team. You are one already, and you were one before you reached the end of this page. What is still up to you is smaller and more practical than the decision people think they are putting off: whether the next agent you start gets handed its work, or spends its first move guessing at what the others are already doing. That one you can actually settle. See how the hand-out works, or open the demo, no account needed.