How to split work between multiple AI coding agents
Two or more AI coding sessions on one codebase is now normal — several people on a team, or one person across a laptop and a desktop. The hard part is not starting the sessions. It is that each one only knows its own window, so they re-decide the same things and re-write the same code. There are four real approaches and they are not interchangeable.
What are the actual options?
One session, many turns. Simplest, and the context stays whole. It queues everything behind one agent and one allowance.
Subagents inside one session. Good for fan-out over a task you can describe up front — review these twelve files, try these four approaches. Bounded by one machine and one subscription, and the parent holds the context.
A hosted orchestration framework. Runs the models for you, so you pay per token on top of the subscriptions you already have, and your code goes to somebody else’s machine.
A wire between the sessions you already run. Each agent stays on its own computer and its own subscription; what moves between them is the project context and the task ownership. That is what Joxo is.
What actually needs to be shared between agents?
Less than people assume, and not the things they usually try to share. Not prompts and not transcripts — those are long, private, and mostly irrelevant to somebody else. What another agent needs is four things: decisions (what we settled on and why), handoffs (what is done, where the branch is, what is next), blockers (what is stuck and what would unstick it), and who owns which task. All four are short. They are also exactly what a human teammate would need, which is why writing them down is worth doing whether or not a tool reads them.
Why is task ownership the part that breaks first?
Because two agents picking up the same task is silent until it is expensive. Nothing errors; both do good work; you find out when the branches meet. Ownership has to be decided somewhere both agents can see, atomically, or it is not decided at all — a note in a file loses the race. Joxo claims a task against the server with a lease, so the second claim is refused immediately and the agent goes and picks something else, which is the behaviour you want at the moment it happens rather than an hour later.
What about usage limits?
This is the failure mode nobody plans for and everybody hits. When one session runs out of allowance, the work it was doing stops being possible on that machine — and the context needed to continue it lives in that session. Moving the task to a machine that still has room requires the context to already be somewhere else. So the handoff and the limit are the same problem: if you have solved sharing context, you have solved surviving the limit, and if you have not, you lose the thread.
Does splitting work across agents actually make things faster?
Sometimes, and it is worth being honest about when. It helps when the work genuinely divides — separate surfaces, separate files, separate concerns — and when each part is big enough that coordinating costs less than doing it. It does not help when the task is one tightly-coupled change, when the parts need constant agreement, or when the bottleneck is you reviewing the output rather than an agent producing it. Two agents on one refactor is usually slower than one, and no amount of shared context fixes that.
What does Joxo not do?
It does not run models or sell inference — every agent runs on your own machine on your own subscription, so it cannot make an agent that is out of allowance keep working; it can only move the task to one that is not. It does not sync code: git does that, and Joxo deliberately does not touch your worktree. Context sharing publishes the updates you or your agents choose to send; it does not automatically upload repositories or transcripts. Optional folder access must be enabled separately. And it is not an autonomous swarm: it moves context and task ownership between sessions a person started.
Which approach should I pick?
One session if you are one person on one machine — genuinely, you do not need any of this, and adding a tool buys you nothing. Subagents if the fan-out is describable up front and one machine’s allowance covers it. A hosted framework if you want somebody else to run the models and you are willing to pay per token and send your code out. A wire between sessions — Joxo — when the agents are on different computers, belong to different people or different subscriptions, and need to agree on one codebase without duplicating each other.
Joxo is the wrong tool for the first three cases. It is also the wrong tool if what you want is an agent that runs without you, or if your bottleneck is reviewing output rather than producing it.
Joxo Pro is per person: every collaborator pays on their own account, and a project owner’s subscription never covers anybody else. Pricing says what it costs and what state each piece is in; set-up is one prompt per agent.