Your background agent needs somewhere to pick up the task and file the result

A background agent is an autonomous coding agent that works a task on its own, off your machine, and hands back finished work. You give it a prompt or a ticket, it clones the repo in its own sandbox, writes the code, runs the tests, and surfaces a pull request for you to review. Cursor, Devin, OpenAI's Codex cloud, Ona, and a growing pile of open-source runners all do a version of this. The pitch is the same everywhere: kick it off, walk away, come back to a diff.

Almost everything written about background agents is about the middle of that loop, the part where the agent runs. This post is about the two ends, because that is where the actual friction is. A background agent is defined by two touch-points that have nothing to do with the model: it picks up a task, and it files the result. Both of those are reads and writes against a record. If that record is slow, private to one machine, or invisible to the other agents you are running, the fancy autonomous middle does not help you.

#The loop is: pick up a task, do the work, file the result

Strip a background agent down and the shape is boring, which is the point.

1. Pick up. The agent needs to know what to work on. Somebody, or some other agent, put a task somewhere: an issue in a backlog, a ticket, a line in a queue. The agent reads it.
2. Do the work. This is the part the vendors compete on: the sandbox, the toolchain, the model, the test loop. It is genuinely hard and genuinely theirs.
3. File the result. The agent finished. Now what? It closes the task, links the branch or PR it opened, and often files the next task it discovered while working. If it does not write that back somewhere durable, the run evaporates the moment the session ends.

Steps 1 and 3 are tracker operations. The agent is reading its queue and writing its outcome. That is a system-of-record job, and it is the job most "background agent" setups leave undefined, which is why people end up wiring the agent straight into GitHub's API and then discovering it does not scale.

#Where it breaks: one agent is fine, several is not

Run a single background agent against a single repo and you can get away with almost anything. Point it at GitHub Issues, let it poll, let it comment. It works because there is one reader and one writer.

The moment you run more than one, the record becomes the bottleneck. A developer on r/github described exactly this after building their own layer:

"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 issue lifecycle, so the agents read and write local state instead of hammering a remote API each. That instinct is right. When several agents are picking up tasks and filing results at once, they need one shared record that is fast to read, safe to write concurrently, and the same list for every agent and every human. A file in one clone is invisible to the other runners. A GitHub issue is a network round-trip and a rate limit away.

#The record Radial is

Radial is a hosted issue tracker built to be the two ends of that loop. It is not the runner. It does not spin up a sandbox, launch your agent, or fire a webhook to trigger one. It is the fast, shared place the task lives before the agent picks it up and the place the result lands after. You bring the agent; Radial holds the record.

Here is the file-the-task side, from a human or a script queuing work for a background agent to grab:

radial create "Fix the flaky login test" -t ENG -p high --json

That returns the created issue as JSON, including its key (ENG-142) and URL, so whatever queued it can hand the agent an exact task id. On the other end, when the background agent finishes, it drives the same tracker over the CLI, the REST API, or the MCP server: it reads its queue, closes the issue it just finished, and with Radial's Git integrations connected, the branch and pull request it opened link straight back to that issue. If it found a second bug on the way, it files that as a new issue before it exits, so the next agent, or the next you, picks it up instead of losing it.

The point is that both ends are the same record, reachable the same way whether a person clicks a board or an agent calls search_issues and close_issue over MCP against mcp.radial.build. One canonical list. Fast reads for the pickup, safe concurrent writes for the filing, legible history for the human who reviews the PR later. That is the tracker your agents can actually drive, aimed specifically at the delegate-and-return loop.

#Where the line is

One honest note, because it is the whole product. Radial is the record, not the intelligence and not the orchestration. It does not run your agent, host it, schedule it, or emit an event to kick one off. There is no copilot inside the tracker, no AI summaries, no auto-triage, and no AI credit meter, because your agent already does the thinking and you already pay for it once.

That is also why more agents never cost more. Every agent credential is a client of the API, CLI, or MCP server, not a billed seat. You pay $50 per user, per year, flat, billed annually, for the humans on the workspace, locked at the rate you join. Run one background agent against the record or ten in parallel and the price 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 background agents?

Background agents are autonomous coding agents that pick up a task and work it on their own, off your local machine, usually in an isolated cloud sandbox with your repo and toolchain. You hand one a prompt or a ticket, it clones the repo, writes and tests the code, and returns finished work like a pull request for you to review, without tying up your editor. Cursor, Devin, Codex cloud, and Ona are common examples.

#What are background agents good for?

They are good for well-scoped, verifiable tasks you can describe once and check later: fixing a flagged bug, adding test coverage, a mechanical refactor, or clearing routine backlog items. The pattern shines when the work is defined enough that the agent can run without hand-holding and the result is a diff you review. It works best when each task lives as a clear record the agent reads from and files back to, so you are reviewing outcomes, not babysitting the run.

#Where should a background agent read its tasks from?

From a shared, hosted record that is fast to read and safe for multiple agents to write at once, not a file in one clone and not GitHub's issue API under polling load. A background agent's whole loop is read a task, do the work, write the result, so the record is load-bearing. Radial is built for that: the agent reads its queue and files results over the CLI, REST API, or MCP, and the same list is visible to every other agent and human on the workspace.

#Does running more background agents against Radial cost more?

No. Agent credentials are clients of the API, not billed seats. You pay $50 per user, per year, for the humans on the workspace, and that number is locked at the rate you join. Connect one background agent or run ten in parallel and the price is the same. There is no AI credit meter anywhere in the product.

#Does Radial run or trigger the agent?

No. Radial is the record, not the runner. It does not spin up sandboxes, launch or schedule your agent, or fire webhooks to trigger one. It holds the task the agent picks up and the result the agent files. You bring your own agent and run it wherever you already run it; Radial is the fast, shared place its work lives.

#The short version

A background agent's job has two ends that are not about the model at all: it picks up a task, and it files a result. Both are reads and writes against a record, and that record has to be hosted, fast, and shared the moment you run more than one agent. Radial is that record, not the runner. Bring your agent, point it at the list, and let it read its work and write its outcome to the same place your team already sees.

Wire your agent up on the developers page, or read the Claude Code MCP walkthrough to connect one in about five minutes.