Several agents at once: isolation is the easy half
Dennis Zaiser, technical founder
One coding agent at work feels productive, so three at once should feel three times as productive. The first step is easy: give each agent its own working copy so they don't overwrite each other's files. Git worktrees or separate clones take minutes to set up. Then the harder problems arrive: two agents changing the same module, a merge that quietly undoes a fix, a coordination chat that costs more than the work, and one person trying to review all of it.
Isolation solves the file problem
A worktree gives each agent a checkout of its own on a branch of its own. Agents don't see each other's half-finished edits, and each runs the test suite against its own changes. For the problem of agents trampling each other's files, that is the whole answer, and it is why isolation is the easy half.
Watch what sits outside the repository: a local database the tests write to, a port the dev server binds, a cache directory. Two agents in separate checkouts can still collide on any of these. Give each its own, or let only one at a time use it.
Sharing one checkout is worse. Git's index is shared, so a change one agent staged can be swept into another agent's commit. If agents must share a checkout, each commits by explicit path and never stages what it didn't write.
Choosing what may run together
The hard half starts before any agent does. Two tasks that touch the same area will conflict however well their copies are isolated, and the conflict surfaces at merge time, after both agents have spent their effort. The cheapest conflict is the one you never schedule.
That takes a map of dependencies: which items are blocked, which wait on others, which are ready. Run only ready work: nothing blocked, nothing waiting on an item it depends on. Keep items small, since a short branch merges cleanly and a long one drifts from the main line while it works.
A quick way to find conflicts before they happen is to ask each item, before it starts, which areas it will change. Two items that name the same module, the same schema or the same shared component run one after the other. It is a crude test, and it catches most of what a merge would.
And cap how much runs at once by how much you can review, not by how many agents your machine can host. Five finished branches waiting on one person move slower than two that get reviewed today.
Merging is where parallel work meets
Each branch passes its checks alone. Together they may not: one agent renames a function that another agent's change still calls, and both pass in isolation. The fix is to make serial the one step that has to be serial. Land one change at a time: bring it up to date with the main line, run the checks again, merge, and only then bring the next one up to date.
Work that must touch the same file gets the same treatment, earlier. One change lands its part first, alone; the other builds on top of it. Ordering two changes costs minutes. Untangling a three-way conflict that an agent resolved by guessing can cost an afternoon.
Coordination costs more than it looks
Once several agents run, it is natural to let them talk: ask each other, report, confirm. Every message wakes the receiving session for a turn that re-reads its whole context, which in a long session can be hundreds of thousands of tokens, and every reply wakes another. Spend grows with the number of sessions, times the messages they exchange, times the context each one re-reads. In practice that is quadratic, and acknowledgements and status updates carry no information a shared record doesn't already hold.
What works is one-way messaging. One coordinator briefs a session, unblocks it, gives it a go or stops it. Sessions don't reply, acknowledge or message each other. They write their progress to a handoff file or to shared state the coordinator reads, and send it a single line only when they need something or have stopped.
Shared state beats chat. An agent that claims an item, holds it while it works and releases it when done tells every other agent what is taken, without a single message.
One person, many agents
The real limit is the person. Questions, approvals and review all land on one desk, and switching between five terminals to find out which agent is waiting is where the time goes.
Batch the questions. Let agents settle technical questions themselves and bring you only the ones only you can weigh. Route everything waiting on you to one place, and let each agent keep working on whatever doesn't depend on your answer. Then clear that place in one sitting, rather than in twenty interruptions.
Review is the other half of that desk. Each change should arrive with what was asked, what was done and what the checks said, so that reviewing it means judging the change, not reconstructing the task. A change you can't review in a few minutes is a sign the item was too large to run in parallel in the first place.
Where ctxflows fits
The Engine page covers the parallel half. The engine runs Claude Code, Codex, Cursor, Gemini CLI or Grok on your machine or server, each run in an isolated working copy. It picks up only ready work, in the order your roadmap sets, and only as much at once as you allow. Each change is delivered your way: a branch to review, or landed one change at a time with your checks.
Boards hold the blockers and links that decide what is ready. Datasets hold the state agents share: an agent reads it, writes it and holds what it is working on, so claiming an item needs no chat. Runs & actions shows every run, and everything waiting on you, in one inbox. The Engine page also describes sessions and your coordinator: one coordinator agent that watches the engine and every run, and is the one agent you talk to.
The working copies stay on your machine. Your code never enters ctxflows.