An issue tracker your agents can actually drive

Search "issue tracker for ai agents" right now and the results are almost all one shape: a small, git-native tracker that lives in your repo, stores tasks in a local database, and exists so a single coding agent stops forgetting what it was doing when the context window fills up. Beads is the one everyone links to. Trekker, and a dozen Show HN clones, are the same idea. They are good tools, and they solve a real problem: an agent working a long task needs somewhere durable to write down what is left, because its own memory resets.

That is the single-agent version of the job. This post is about the version that shows up the moment there is more than one agent, or a human who needs to see the same list. At that point a local file in one person's repo stops being enough, and the tracker has to become something a whole team, and a whole fleet of agents, can drive at once.

#The job the local trackers get right

Give an agent a task list it can read and write, and two things improve immediately: focus and continuity. Focus, because the agent reads the next item instead of re-deriving it from a long prompt. Continuity, because when the session ends the state is written down, so the next session picks up where the last one left off instead of starting cold.

A developer on r/ClaudeCode described the loop better than any product page:

"I spin up backlog items in a ticketing system and then have them step through in a semi waterfall meets agile process. I can use context up front for planning and then execution in either multiple agents or pickup if I need to walk away."

That last clause is the whole thing. Plan up front, hand the backlog to the agent, and be able to walk away and pick back up. The tracker is where you left off and where you come back. A local git tracker does this for one agent on one machine. It is genuinely useful, and if that is your entire setup, you may not need anything else.

#Where a local record stops scaling

The friction starts when the record needs more than one reader.

Run two or three agents in parallel and a file in one clone is invisible to the others. Add a teammate and they cannot see what your agent filed without pulling your branch. Come back a week later and the "why" behind a closed task is buried in a database only your machine has. The single-agent memory tool was never trying to be a shared system of record, so it does not become one just because your workflow grew.

What a team running agents actually needs is a record that is:

• Hosted, not local. One canonical list every agent and every human hits, not a copy per clone.
• Driveable by machines and people from the same place. The agent files an issue over an API; a human sees it in a board a second later. Same record, two surfaces.
• Legible when you walk away. Not just "here is the task," but the comments and the activity trail that tell you what happened while you were gone, so pickup is real.

Radial is built for that version. It is a hosted issue tracker, so the list is the same one whether it is read by you, your teammate, or the fourth agent you spun up this morning. It is fast, it is a tracker and only a tracker, and it exposes the same verbs to a person clicking a board and to an agent calling an API.

#Driving it from an agent

An agent drives Radial over MCP or the CLI, using the plain verbs of a tracker. Here is the pick-up loop from the terminal: an agent, coming back to work, lists what is assigned to it and in progress, then reads the activity trail on the top issue to see where the last session left off.

radial list --assignee me --status "in progress" --json
radial activity RAD-219 --json

The first call is the "what am I on" question, answered as JSON the agent can parse. The second is the pickup point: activity returns the issue's history, comments and status changes and all, so the returning agent reads what already happened instead of guessing. When it finishes, it closes the issue with a note, and the next reader, human or agent, sees the same trail.

Over MCP the same loop uses search_issues, list_issues, comment, and close_issue against the hosted server at mcp.radial.build, so an agent inside Claude Code or Codex reads and writes the shared list in its own tool loop. The Claude Code MCP walkthrough covers wiring that up in about five minutes.

#The part that stays honest

Two honest notes, because they are the point of the product.

First, Radial does not compete with a local git tracker on being local. It is cloud-hosted. If your entire need is one agent's private memory inside one repo and you never want it to leave your machine, a git-native tool is the right call, and we will say so. Radial earns its place when the record has to be shared: multiple agents, multiple humans, one list.

Second, the intelligence is still yours. Radial is the fast place your agent writes to, not a smarter tracker. There is no copilot in the product, 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. Every agent credential you connect is a client of the API, CLI, and MCP server, and agent credentials never count as billed seats. You pay $50 per user, per year, flat, for the humans on the workspace, locked at the rate you join. Spin up ten agents against the record and the price does not move. That is the Plain Software Pledge: the day we ship a copilot, meter usage, or charge you for AI you did not ask for, your subscription is free.

#FAQ

#What is the best issue tracker for AI agents?

It depends on how many agents and humans share the record. For one coding agent that needs a private, in-repo memory so it does not lose the thread mid-task, a git-native local tracker like Beads is a good fit. For a team running several agents alongside humans who all need the same list, you want a hosted tracker the agents can drive over an API, CLI, and MCP, which is the gap Radial fills.

#How is Radial different from Beads?

Beads is a local, git-native tracker: it stores tasks in a database inside your repo and exists mainly to give a single coding agent durable memory across context resets. Radial is a hosted, multi-user tracker: one canonical list that every human and every agent on the workspace reads and writes, with a board for people and an API, CLI, and MCP server for machines. Different jobs. Local memory for one agent versus a shared system of record for a team and its fleet.

#Can an AI agent create and close issues on its own?

Yes. An agent drives Radial through the CLI (radial create, radial list, radial close), the REST API, or the MCP server, using the same verbs a person uses. It can file an issue it discovered mid-task, list what is assigned to it, read an issue's activity trail to see where the last session stopped, and close an issue with a comment when the work is done, all without a human relaying anything.

#Does adding more agents 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 agent or ten and the price is the same. There is no AI credit meter anywhere in the product.

#How does an agent "pick back up" after I walk away?

By reading the record. When you come back, the agent lists what is in progress and reads the issue's activity history, which carries the comments and status changes from the previous session. That trail is the handoff: the returning agent, or a teammate, sees what already happened instead of starting cold. It is the shared, hosted version of the continuity a local tracker gives one agent.

#The short version

Local trackers gave one agent a memory, and that was a real fix. The next problem is a team problem: several agents and several humans need to drive the same record, hosted where everyone can reach it, legible enough to walk away from and come back to. That is a tracker your agents can actually drive, and it is what Radial is for.

Wire your agent up on the developers page, or read why we think issue tracking isn't dead if you got here from the threads arguing the opposite.