Running agents in parallel? They need one shared record to coordinate around

Parallel agents are multiple AI agents working at the same time on different parts of one job. Instead of a single agent grinding through a task list in order, an orchestrator splits the work, launches several agents at once, and stitches the results back together. Claude Code runs subagents this way. Cursor spins up parallel sessions. Codex fans out across worktrees. The pitch is always speed: five agents finish in the time one would take on a single slice.

Launching them is the easy part. Every guide shows you how to kick off five agents. Almost none of them tell you the truth about running more than one, which is that the moment two agents work at once, your problem stops being the model and becomes coordination. The agents need to divide the work without both grabbing the same task, and they need to report back to a place the other agents and the human can see. That is a shared-state problem, and the piece of shared state they contend over most is the task list itself.

#The bottleneck moves from the model to the record

Run one agent and you can be sloppy. It reads a task, does the work, writes the result, and there is exactly one reader and one writer, so nothing collides. Point it at a Markdown file in the repo, at GitHub Issues under a poll loop, at a scratch file in its own worktree. It all works, because there is no one else to conflict with.

Add a second agent and every one of those shortcuts breaks. A file inside one agent's git worktree is invisible to the agent running in the worktree next to it, so they cannot see each other's claims. GitHub's issue API turns into a rate limit the moment several agents poll it at once. A developer on r/github hit exactly this after wiring their own agents straight into GitHub:

"The polling problem bites hard once you have more than one agent checking issue state at the same time."

Their fix was to stop letting the agents touch GitHub directly and put a single fast API in front of the whole issue lifecycle, so each agent read and wrote shared state instead of hammering a remote per check. That is the right instinct, and it is the whole shape of the problem. Parallel agents do not need a smarter model to coordinate. They need one record that is fast to read, safe to write concurrently, and identical for every agent and every human looking at it.

#What "coordinate around a record" actually means

Coordination between parallel agents comes down to three moves against a shared list, and all three are tracker operations.

1. Claim. An agent picks up a task and marks it taken, so a sibling agent does not start the same one. In tracker terms that is a status move and an assignment: pull the next open issue, set it to in progress, own it.
2. Report. An agent finishes and writes the outcome where the others can see it: close the issue, link the branch or PR it opened, and file the next task it discovered mid-run so it is not lost when the session ends.
3. Read the board. The orchestrator, and the human, look at one list to know what is done, what is in flight, and what is still open, without asking each agent individually.

None of that is model work. It is reads and writes against a system of record. If that record is a file in one clone, the claims are invisible. If it is a remote API under poll pressure, the reports are slow and rate-limited. The coordination layer everyone reinvents for parallel agents is just a fast, shared issue tracker with an API, which is the thing most setups leave undefined until it breaks.

#The record Radial is

Radial is a hosted issue tracker built to be that shared record. It is not the orchestrator. It does not launch your agents, split the task, run the worktrees, or merge the branches back together. You bring the agents and whatever fans them out; Radial holds the one list they all read from and write to, fast enough to poll hard and safe for several writers at once.

Each agent gets its own scoped key, so you can give the worker agents full access and hand a read-only key to anything that just needs to watch the board:

radial list -a me --status "in progress" --json

That returns every issue currently claimed and in flight, as JSON, so an orchestrator can see at a glance what its agents are working before it hands out the next slice. The worker agents drive the same tracker over the CLI, the REST API, or the MCP server at mcp.radial.build: an agent calls search_issues to pull its next task, move_issue to claim it, and close_issue to report the result, and with Git integrations connected, the branch and PR it opened link straight back to the issue. Every one of those calls hits the same canonical list, so two agents never silently duplicate work and the human reviewing later sees one legible history instead of five private ones.

Because every agent credential is a client of that API rather than a billed seat, the number of agents you run in parallel has nothing to do with the bill. Five agents or fifty, the record is the same and so is the price.

#Where the line is

One honest boundary, because it is the whole product. Radial is the shared record, not the orchestration and not the intelligence. It does not decompose your task, launch the agents, manage their worktrees, resolve merge conflicts, or synthesize their outputs. There is no copilot inside the tracker, no AI summaries, no auto-triage, because your agents already do the thinking and you already pay for them once.

That is also why parallelism never costs more here. You pay $50 per user, per year, flat, billed annually, for the humans on the workspace, locked at the rate you join. Agent keys are clients, not seats. Run one agent against the record or ten in parallel and the number does not move. The Plain Software Pledge is the binding version: the day Radial ships a copilot, meters your usage, or charges you for AI you did not ask for, your subscription is free.

#FAQ

#What are parallel agents?

Parallel agents are multiple AI agents running at the same time, each working a different slice of one larger job, coordinated by an orchestrator that splits the task up front and combines the results at the end. Instead of a single agent working a backlog in sequence, several run concurrently, which is faster but introduces a coordination problem: the agents have to divide the work without colliding and report back somewhere shared. Claude Code subagents, Cursor's parallel sessions, and Codex worktree fan-outs are common examples.

#Why do parallel agents need a shared record?

Because the moment more than one agent works at once, they contend over shared state, and the state they contend over most is the task list. Each agent has to claim a task so a sibling does not grab the same one, and report its result where the others can see it. A file in one agent's worktree is invisible to the others, and a remote issue API under poll load becomes a rate limit. A single fast record that every agent reads from and writes to is what keeps them from duplicating work or losing outcomes.

#How do I stop two agents from working the same task?

Give them one shared list and make claiming a task an explicit write against it: an agent pulls the next open issue, moves it to in progress, and assigns itself before starting work, so another agent querying the same list sees it is already taken. This only works if the record is shared and fast, not a per-worktree file. With Radial, agents claim and report over the CLI, REST, or MCP against one canonical list, so a move_issue call is visible to every other agent immediately.

#Does running more agents in parallel cost more on Radial?

No. Agent credentials are clients of the API, not billed seats. You pay $50 per user, per year, for the humans on the workspace, locked at the rate you join, and the number of agents you run against the record does not change that. One agent or fifty in parallel, the price is the same, and there is no AI credit meter anywhere in the product.

#Does Radial orchestrate the agents?

No. Radial is the shared record, not the orchestrator. It does not split your task, launch the agents, manage their worktrees, or merge their branches. It holds the one list the agents claim tasks from and file results to, fast to read and safe for several writers at once. You bring your own orchestration and run it wherever you already do; Radial is the place the parallel work coordinates around.

#The short version

Launching parallel agents is easy. Keeping them from stepping on each other is the real work, and it is a shared-state problem, not a model problem. The state they fight over is the task list: each agent has to claim its work and report its result somewhere every other agent and human can see, fast and without collisions. Radial is that record, not the orchestrator. Give each agent a scoped key, point them at one list, and let them claim and report against the same place your team already watches.

Wire your agents up on the developers page, or read the tracker your agents can actually drive for the full BYO-agent picture.