DEV Community: Radial

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

Nico Acosta — Mon, 27 Jul 2026 13:17:51 +0000

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.

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.
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.
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.

Originally published on the Radial blog.

Why the results appear before the spinner would: how a tracker feels instant

Nico Acosta — Fri, 24 Jul 2026 13:16:51 +0000

There is a specific feeling you get from a fast tool: you type a filter, and the list is already right. You change a status, and it moves before you have finished letting go of the mouse. There was no spinner, because there was no moment to put one. The work happened where you were looking, and the network sorted itself out afterward.

That feeling is not a faster server. You cannot buy it with a bigger box, and you cannot A/B your way to it after the fact. It comes from one architectural decision made early: keep the working set close to the user, so the common actions do not wait on a round trip to feel done. This post is about how that works, and, just as importantly, where the honest limits are.

The default architecture makes you wait

Most web apps are built the obvious way. The source of truth lives on a server. The client is a thin renderer. Every meaningful action, filtering a list, editing a field, reordering a board, is a request: send it, wait, receive, re-render. Even when each request is fast, you are paying network latency on every interaction, all day.

We wrote about the extreme version of this in why Jira is so slow: a single ticket that fans out into a cascade of round trips before the page is usable. But you do not need 200 requests to feel the tax. One request per keystroke of filtering is enough. The problem is not the number, it is the shape: the client asks, the server answers, and you wait in between. As long as the data you are working with lives only on the server, the floor on "how fast can this feel" is set by the network, not by your code.

Keep the working set in the client

The fix is to stop treating the client as a thin renderer and start treating it as the place the working set lives.

When you open a Radial workspace, the issues you are looking at are loaded into a normalized in-memory store on the client (we use zustand; the pattern matters more than the library). From that point on, the interactions that used to be requests become local computations:

Filtering and sorting run as a predicate over the loaded slice. Narrowing by assignee, priority, or label does not call the server; it re-evaluates a function over data already in memory. That is why the list is right the instant you type.
Editing is optimistic. When you change a status, the store updates first and the UI reflects it immediately. The write to the database happens in the background, under row-level security. If it fails, the change rolls back and you get a toast. The common case, which is that it succeeds, never made you wait.
Realtime keeps the working set honest. When a teammate (or a teammate's agent) changes something, the update arrives over a realtime channel and reconciles into the same store, with the app's own echoes suppressed so your optimistic edit does not fight the confirmation of itself.

The through-line: the network is still there, but it moved off the critical path. You act on local state; the server catches up. The spinner has nowhere to live because the moment it would have filled is already over.

Where this is honest, and where it is not

It is easy to oversell this, so here is the line we hold.

Radial is not local-first software in the Ink & Switch sense: it is not offline-first, it does not use CRDTs, and your data is not primarily on your disk. It is a hosted, multi-tenant app backed by Postgres. What we do is narrower and more mundane: we keep the working set in the client and make the common actions optimistic, so the tool feels instant even though the source of truth is a server you are talking to.

Two consequences follow, and we would rather name them than imply they do not exist:

Global search is a server call, not a local scan. Typing into the ⌘K palette to find any issue in the workspace hits a database function, because the full corpus is not all in the client. It is fast, but it is a network request, not a local filter. The instant part is filtering and editing the slice you already have loaded, not searching everything you have never opened.
Staying small is what keeps it fast. This only works because the working set is small enough to live in the client. Radial is deliberately one thing, an issue tracker, with no 50-field forms and no dashboard suite fanning out behind every page. Speed here is a position you hold by saying no, the same discipline behind boring on purpose. Bolt on an everything-app and the working set stops fitting, and the trick stops working.

We also do not publish a latency figure as a measured benchmark, because the only honest claim is the design goal, not a marketing number. The goal is simply that the tool gets out of the way.

The same idea, from the terminal

The instant-feel is a property of the architecture, not of the web UI specifically, which is why the command line gets the same benefit. The CLI talks to the same fast surface, and every command takes --json, so you can pipe the working set straight into whatever you are already scripting:

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

That returns your in-progress issues as structured JSON in one call, no page to render, no spinner to watch. Your agent gets the same thing over MCP at mcp.radial.build, and the REST API at api.radial.build is plain JSON, not a GraphQL SDK you have to learn. The point is consistent across every surface: the tool should not make you wait, whether you are looking at a board, typing in a terminal, or driving it with an agent.

FAQ

What is local-first software?

Local-first software, as defined by Ink & Switch, is a set of principles where the primary copy of your data lives on your own device rather than a remote server, so the app works offline, stays fast, and keeps you in control of your data even without the cloud. It usually relies on conflict-free replicated data types (CRDTs) to merge changes across devices. Radial is not local-first in this strict sense: it is a hosted app that keeps your active working set in the client for speed, which is a different and narrower technique.

Does Radial work offline?

No. Radial keeps the issues you are working with in a client-side store so filtering and editing feel instant, but the source of truth is a hosted Postgres database and it needs a connection to sync. It is fast because the working set is local, not because it is offline-capable. If you need a fully offline, on-your-disk tracker, a true local-first or file-based tool is a better fit.

Why does filtering feel instant but search does not?

Because they work on different data. Filtering and sorting run over the slice of issues already loaded into the client, so they are local computations with no network in the loop. Global search across the whole workspace has to reach issues that are not loaded, so it calls a database function. One is a local predicate; the other is a fast server request. We would rather be precise about that than pretend everything is local.

How does optimistic editing avoid losing my changes?

Every optimistic mutation snapshots the previous state before applying the change to the client store. The database write then happens in the background under row-level security. If the write fails, the change rolls back to the snapshot and you get a toast, so you always know when something did not stick. Realtime updates from other users reconcile into the same store, with the app's own echoes suppressed so your edit is not double-applied.

Is a faster tracker actually worth switching for?

If your team touches issues dozens of times a day, the per-interaction wait is a focus tax you pay every day. The value is not a benchmark number; it is that the tool stops interrupting you. A tracker you forget you are using, because it never makes you wait, is the goal.

The short version

A tool feels instant when the working set lives in the client: filtering and sorting become local computations, editing is optimistic, and the network catches up in the background instead of blocking each action. That is the architecture behind Radial. It is not local-first software, and global search is still a server call, but the common actions do not wait, and that is where the feeling comes from.

See the one flat price on pricing, or wire the same fast surface into your terminal and your agent at /developers.

Originally published on the Radial blog.

GitHub stores the code, not the decision. Where the \"why\" should actually live.

Nico Acosta — Thu, 23 Jul 2026 13:16:05 +0000

An architecture decision record (ADR) is a short document that captures one architecturally significant decision: the context that forced the choice, the decision itself, and the consequences that follow. Michael Nygard proposed the format in 2011, and the convention that stuck is a numbered Markdown file in doc/adr/ in the repository, one page, written once and never edited. If the decision changes later, you do not rewrite the old record. You write a new one that supersedes it, so the log stays append-only and the history of your thinking stays readable.

That is the whole idea, and it is a good one. The rest of this post is about the part the format does not solve: most of the decisions that shape a codebase never become an ADR at all, and the reason is not laziness.

What goes in an ADR

The Nygard template has four sections, and nearly every variant since (MADR, the AWS and Microsoft prescriptive versions) is a reshuffle of the same bones.

Title. A short noun phrase naming the decision. "Use PostgreSQL for the primary datastore," not "Database discussion."

Status. Proposed, accepted, rejected, deprecated, or superseded. The status is what makes the log a log rather than a pile.

Context. The forces in play: the constraints, the requirements, the things that were true when you decided. This is the section people skimp on and the section future readers actually need. A decision without its context reads as arbitrary six months later.

Decision. What you chose, in active voice. "We will use PostgreSQL," not "PostgreSQL seems like it might be reasonable."

Consequences. What follows, good and bad. What this makes easy, what it makes hard, what you now have to live with, and what you ruled out to get here.

Keep it to a page. An ADR is a snapshot of a decision, not a design document, and the moment it grows sections it stops getting written.

When to write one

The rule of thumb from the AWS guidance and the Red Hat writeup agrees on the shape: write an ADR when the decision is architecturally significant, meaning it is expensive to reverse, it affects the structure of the system, or it constrains what the team can do later. Choosing Postgres over DynamoDB is an ADR. Choosing a variable name is not. Adopting an event-driven boundary between two services is an ADR. Bumping a patch version is not.

The useful test is the one Red Hat gives: an ADR is not a glorified changelog, and it does not replace good commit messages. If the answer to "why is this like this" is already visible in the diff, you do not need a record. You need one when the answer lives in a conversation that the diff cannot show, and when getting it wrong later will cost a rewrite.

The decisions that never make it to `doc/adr/`

Here is the honest gap, and it is worth naming precisely because ADRs are good, not because they are not.

The ADR format works well for the decisions you know are significant at the moment you make them. You recognize the fork, you convene the discussion, someone writes the file. But most architectural drift is not made of those. It is made of the smaller decisions that only look significant in retrospect: the retry semantics someone picked while fixing a flaky test, the approach that got ruled out in a pull request thread and never wrote itself down, the reason the third service does its own auth instead of using the shared middleware. Nobody stops mid-fix to open a numbered Markdown file for those. They are load-bearing anyway.

Those decisions do get made somewhere, and the somewhere is almost always the work: an issue, a comment thread, a pull request review, a session with a coding agent. Git stores the code that came out the other side. It does not store the four alternatives you rejected, the constraint that ruled out the obvious approach, or the argument that changed someone's mind. The commit is the artifact, not the reasoning.

This has gotten sharper with agents in the loop. When an agent plans an approach, rules out two others, and implements the third, all of that reasoning exists in a context window, and the context window compacts or ends. The code survives. The reasoning does not, unless something outside the model wrote it down.

Two records, one repository

The version that works in practice is not "ADRs or the tracker." It is both, doing different jobs.

Keep doc/adr/ for the big irreversible forks: the datastore, the service boundaries, the auth model. Those deserve a numbered, append-only, superseded-not-edited file that ships with the code and gets read on onboarding.

Then let the ordinary decisions land where the work already is, in the issue that produced them, at the moment they are made. The record is worth having only if writing it costs nothing, which means it has to happen in the same motion as the work, not as a separate ceremony afterward.

Radial is an issue tracker built so that motion is one command. It has a real CLI, a plain REST API, and an MCP server against the same issue lifecycle, so the same decision gets recorded whether you are in the terminal, in CI, or driving it with an agent. Every command takes --json.

# Record the decision on the issue that produced it, as it happens
radial comment RAD-482 -m "Chose optimistic locking over a row-level mutex. Ruled out the queue: adds a broker to a path that must stay synchronous. Revisit if write contention exceeds ~200/s."

# Link it to the issue that will actually have to live with it
radial link RAD-482 related RAD-611

# The constraint that ruled out the obvious approach is itself work: file it
radial create "Write ADR-014: locking strategy for the ledger writer" -t ENG -p high --json

That last command is the seam between the two records. The tracker catches the decision at the moment it is made, when the context is still in someone's head, and the ones that turn out to be architecturally significant graduate into a proper ADR in the repository. The ones that do not are still findable, still attached to the work, and still readable by the next person or the next agent.

Nothing about this is an AI feature. Radial does not read your code, summarize your diffs, or generate your ADRs. It is a fast issue tracker that people and agents can drive over CLI, REST, and MCP, and the durable record is what happens when decisions get filed the ordinary way. The intelligence stays in your agent, your model, your keys.

FAQ

What is an architecture decision record?

An architecture decision record (ADR) is a short document capturing one architecturally significant decision, along with its context, the decision itself, and its consequences. It is typically a numbered Markdown file stored in the code repository, often under doc/adr/, and it is written once rather than edited: if the decision changes, a new record supersedes the old one, keeping the log append-only.

What should an ADR contain?

The Nygard template, which most variants follow, has four sections: title (a short noun phrase naming the decision), status (proposed, accepted, rejected, deprecated, or superseded), context (the forces and constraints that made the decision necessary), decision (what you chose, in active voice), and consequences (what follows, including what you ruled out and what you now have to live with). Keep it to roughly one page.

When should you write an architecture decision record?

Write one when the decision is architecturally significant: expensive to reverse, structural, or constraining on what the team can do later. Choosing a datastore or a service boundary qualifies. Naming a variable does not. If the reason is already visible in the diff, a good commit message is enough. Write the ADR when the reasoning lives in a conversation the diff cannot show.

What tools are there for architecture decision records?

The common ones are Markdown-based and deliberately minimal: MADR provides a lean template, and adr-tools is a set of command-line tools that create, number, and supersede records in your repository. Both keep the records as plain files next to the code, which is the point of the format. For the smaller decisions that never reach a numbered file, an issue tracker with a comment thread does the job at the moment the decision is made.

Where should decisions live if not in an ADR?

In the work that produced them. Most decisions are not architecturally significant enough to justify a numbered file, but they still shape the system: the retry semantics, the ruled-out approach, the constraint nobody documented. Recording them on the issue keeps them attached to the work, findable later, and readable by the next person or agent. See agentic coding ships the 80% for the version of this argument that involves coding agents.

Do ADRs replace commit messages or a changelog?

No. An ADR is not a glorified changelog, and it does not replace good commit messages. A changelog records what changed; a commit message records what this change does; an ADR records why a significant structural choice was made and what it rules out. They answer different questions and the ADR is the most expensive of the three, which is why it should be reserved for decisions that are costly to reverse.

The short version

An ADR is a one-page, append-only record of a significant technical decision: context, decision, consequences, stored with the code. Use it for the forks that are expensive to reverse. But most of what shapes a codebase is decided in smaller moments, in an issue, a review, or an agent session, and Git stores what those produced, not why. Record those where the work already lives, and let the ones that turn out to matter graduate into a real ADR.

See the full CLI verbs and the API on the developers page, or read the manifesto for why the tracker stays a tracker.

Originally published on the Radial blog.

Agentic coding ships the 80%. Your tracker holds the other 20%.

Nico Acosta — Wed, 22 Jul 2026 13:17:18 +0000

Agentic coding is a way of building software where an autonomous AI agent takes a high-level instruction and plans, writes, tests, and revises the code with little step-by-step human input. Unlike an inline assistant that waits for you to type and then completes the line, an agent runs a loop: it decides what to do next, does it, checks the result, and corrects itself, until the task is done or it gets stuck. Claude Code, Codex, Cursor's agent mode, and Gemini's coding agent are all versions of the same idea.

That loop is genuinely fast, and it is why the term went from niche to everywhere in a year. It is also why a specific gap keeps showing up in the discussion: the agent reliably produces roughly the functional 80% of a working change, and the remaining 20%, the part that has to be right for the work to actually be done and remembered, does not live in the code the agent just wrote. This post is about where that 20% should go.

The 80% problem, stated plainly

If you search "agentic coding," one of the first questions Google surfaces is "what is the 80% problem in agentic coding?" The short version people have converged on: agents ship the working majority of a change quickly, and the hard, compounding remainder, the error handling, the security edges, the "why did we do it this way," the coordination between the change and everything else in flight, is where the debt accumulates when nobody captures it.

Notice that most of that remainder is not more code. It is context and decisions. Which approach was chosen and why. What was ruled out. What the agent noticed on its way through that nobody asked it to fix. Which of three parallel agents already touched this module. That information is real work product, and by default it lives in exactly one place: the context window of the session that produced it. When the window fills and compacts, or the session ends, it is gone. The code survives; the reasoning behind it does not.

So the 80% problem is not really "agents write sloppy code." It is that the fast part and the durable part have different homes, and agentic workflows are very good at producing the fast part and very bad at persisting the durable part.

Where the durable 20% should live

The cheapest durable unit for the 20% is an issue. Not a document, not a chat log, an issue: it has an owner, a status, a priority, and a comment thread, and it sits outside the model entirely, so it survives every context reset by construction. When an agent opens an issue for the work, comments on it as it makes decisions, and closes it with a note when the change lands, the reasoning stops being a casualty of the next auto-compact. The next session, or the next agent, reads the current state instead of reconstructing it from a summary that got squeezed out.

This is also the piece that lets more than one agent work at once without stepping on each other. A developer in a recent r/github thread described building the missing layer by hand: a single local API for the full issue lifecycle so that, in their words, "the agent never polls GitHub, it just checks local state and the sync layer handles the rest." That instinct is exactly right. The agents need one fast place to read and write the state of the work, separate from any one session's memory. The only question is whether you hand-roll it or point at one that already exists.

Radial is that record, built so agents can drive it directly. It is a fast issue tracker with a real CLI, a plain REST API, and an MCP server, all against the same issue lifecycle, so however your agent reaches it, it reads and writes the same state. Here is the loop an agentic coding session runs against it, using the CLI (every command takes --json, so the output pipes straight into the next step):

# The agent reads what's assigned to it, in progress, as structured JSON
radial list --assignee me --status "in progress" --json

# It makes the change, then closes the issue with a note the next session can read
radial close RAD-482 -m "Chose optimistic locking over a mutex; ruled out the queue approach, added in #611."

# It spotted a second problem on the way through, so it files that too
radial create "Token refresh retries on 401 instead of re-auth" -t ENG -p high -l bug -a me --json

Nothing in that loop is specific to one agent. The same three verbs run from a REST call in CI, from the MCP server a different agent is connected to, and from your own terminal, all against one shared record. The 80% (the code) ships however it ships; the 20% (the decisions, the follow-ups, the state) is now written down where it outlives the session.

Why this is a tracker, not an AI feature

There is a line here worth being precise about. Radial does not read your code, summarize your diffs, or try to be a smarter memory layer for your agent. It is a fast issue tracker that agents happen to be able to drive over CLI, REST, and MCP, and the durable record is a side effect of agents filing and updating issues the normal way, not an AI feature bolted on top. The intelligence stays in your agent, your model, your keys. Radial holds the record.

That is deliberate, and it is binding. There is no copilot in the product, no auto-summary, no AI triage, and no AI credit meter, because your agent already does the thinking and you already pay for it once. The Plain Software Pledge is the enforceable version: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

And because every agent credential is an API client, not a billed seat, running a fleet of coding agents against Radial costs nothing extra. The price is $50 per user, per year, flat, billed annually, for the humans on the workspace, locked at the rate you join. Ten agents writing to the same tracker is still just the humans. Agents ride free; that is the structure, not a promotion.

FAQ

What is agentic coding?

Agentic coding is a software development approach where an autonomous AI agent plans, writes, tests, and modifies code from a high-level instruction, with minimal human intervention. Instead of completing a line you are typing, the agent runs its own loop: it decides the next step, executes it, checks the outcome, and self-corrects until the task is done. Claude Code, Codex, and Cursor's agent mode are common examples.

What is the 80% problem in agentic coding?

It is the gap between the functional majority of a change that agents produce quickly (roughly 80%) and the durable remainder (the error handling, the security edges, the decisions, and the coordination) that compounds into debt when it is never captured. Much of that remainder is context and reasoning, not code, and it disappears when a session's context window compacts or ends unless it was written down somewhere outside the model.

How is agentic coding different from vibe coding?

Vibe coding is prompt-driven and exploratory: you describe what you want and iterate on the output by feel. Agentic coding is outcome-oriented and self-directed: the agent runs a plan-act-check loop toward a defined result and corrects itself along the way. In practice the two blur, but the agentic version produces more work product (decisions, follow-ups, state changes) that needs a durable home.

Where should an AI coding agent record its work?

In an issue tracker it can drive directly, so the record survives context resets and hands off cleanly to the next session or agent. An issue is a cheap durable unit: owner, status, priority, and a comment thread, all outside the model. Point your agent at Radial's CLI, REST API, or MCP server and it can read its queue, file issues, comment as it decides, and close them when done. See give Claude Code access to your issue tracker in 5 minutes for the MCP setup.

Does running multiple coding agents against Radial cost more?

No. Agent credentials are API clients, not billed seats. You pay $50 per user, per year, for the humans on the workspace, locked at the rate you join, and a fleet of agents writing to the same tracker adds nothing to that.

The short version

Agentic coding ships the functional 80% fast, and the durable 20%, the decisions, the follow-ups, and the coordination, is context, not code. By default that context dies with the session's memory. Give your agents one durable record they drive over CLI, REST, and MCP, and the reasoning behind the work outlives the window that produced it.

See the full tool list and the CLI verbs on the developers page, or read your Claude Code sub-agents keep losing the thread for the multi-agent version of the same argument.

Originally published on the Radial blog.

You don't want a git issue tracker. You want issues that live next to your code.

Nico Acosta — Tue, 21 Jul 2026 13:15:02 +0000

Every few months a developer works it out from first principles, usually in a thread on r/git or Hacker News. They don't actually want GitHub the product. They want a fast, local-feeling way to track the work, close to the code, without a heavy web app in the loop. So they reach for the obvious idea: keep issues as Markdown files in the repo, one file per issue, commit the .issues/ folder, done. Git is already the source of truth for the code. Why not the issues too?

The instinct is correct. Issues should live close to the code, move at the speed of the terminal, and never require a slow tab to update. What is wrong is the conclusion that you have to build it yourself. You end up maintaining a homegrown tracker: no search, no assignees that mean anything, no way for a teammate's agent to file a bug without a merge conflict. The idea is right; the DIY tax is the problem.

This is the case for a tracker that gives you the git-native feel without pretending your repo is a database.

Why developers keep reinventing the git issue tracker

The pull toward git-native issue tracking comes from real frustrations, and they are worth naming because a good tool has to answer all of them:

Context switching. Filing an issue means leaving the editor, waiting for a web app, typing into a form, and coming back. The Markdown-in-repo idea kills the round trip. You want that.
Ownership. Your code is in git; leaving is a git clone away. A cloud tracker that holds your issues hostage is a switching-cost trap. You want an exit.
Speed. A local file opens instantly. A tracker that takes two seconds to render a list is a tool you avoid, and a tool you avoid stops being the system of record.
Agents. More and more, the thing filing and closing issues is a coding agent, not a person. Agents want one fast interface to read and write issue state, not a browser to click through.

The homegrown .issues/ folder scores well on the first three and badly on everything else. It has no real search, no shared status model, no notion of who is assigned, and it turns every parallel edit into a merge conflict. The moment a second person, or a second agent, touches it, the seams show.

What actually solves it: the terminal, not the filesystem

The thing you were reaching for with a Markdown folder is not storage in the repo. It is a tracker you drive from where you already are: the terminal, your CI, your agent. Radial is built that way. Issues live in Radial, not in your .git directory, and we are honest about that, because pretending otherwise is how you end up with merge conflicts on your bug list. What you get instead is a first-class CLI, so the tracker feels as close as git:

# File an issue without leaving the terminal, and get its id back for scripting.
radial create "Flaky login test on CI" \
  --team ENG \
  --priority high \
  --label ci \
  --json | jq -r '.id'
# → ENG-142

That is the whole round trip the .issues/ folder was trying to buy you: no browser, no form, no waiting. And because every radial command takes --json, the tracker composes with the rest of your shell. Listing your open work is one line:

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

Search, close, import, export: same shape, same --json, all scriptable. You get the "issues at the speed of the terminal" feeling the Markdown idea promised, plus real search, real assignees, and a status model your whole team shares, without hand-rolling any of it. That composability is the point of a CLI-first design: a failing job can file its own issue from CI with the same radial create ... --json, and a cleanup script can search and close in the same shell.

The part the repo can't give you: linking to git

Here is where storing issues as files in your repo actively works against you. The reason you want issues near the code is so the two stay connected: this branch fixes that bug, this PR closes that issue, this commit is where it landed. A folder of Markdown files can't do that automatically. It just sits next to the code, inert.

Radial connects to your repo instead of living inside it. Connect GitHub, GitLab, or Bitbucket (including self-hosted GitHub Enterprise, self-managed GitLab, and Bitbucket Data Center), and Radial links branches, pull requests, and commits to the matching issue, and transitions the issue's status as the PR moves. Open a branch named for ENG-142, and the issue knows. Merge the PR, and the issue closes. The loop between "where the work is tracked" and "where the code lands" closes without a human copying an id between two tabs, which is exactly the loop the in-repo Markdown file could never actually close.

You keep your repo. Radial is not trying to replace GitHub as your code host. It graduates the issue part into something fast and scriptable, and wires it back to the code you already have.

Why this matters more once agents are filing the issues

The newest reason developers reach for a git-native tracker is that they are running coding agents, and they want the agent to read and write issue state without hammering a web API or clicking through a UI. Run more than one agent at once and the seams of a homegrown solution show immediately: two agents editing the same Markdown file is a merge conflict; two agents polling GitHub's API is a rate-limit problem.

A real tracker with a real API is the answer. Radial gives your agents one interface to the full issue lifecycle: the same CLI you use, plus a remote MCP server that lets Claude Code, Codex, or any MCP client create, search, comment on, and close issues directly. Point your agent at it and it files a bug the moment it notices a failing test, no browser and no shell script required. And every agent credential is a free client of the API. Agents ride free; the humans on the team are the seats, at one flat $50 per user, per year, billed annually. No per-agent charge, no AI credit meter anywhere in the product. That is the Plain Software Pledge in practice: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

FAQ

Does GitHub have an issue tracker?

Yes. GitHub Issues is a solid, lightweight tracker built into every repository, and for a lot of projects it is genuinely enough. The pull toward something else usually starts when a flat list of issues stops scaling: you want a shared status model across teams, faster navigation, a real CLI to script it from, and one interface your coding agents can drive. That is the point where a dedicated tracker earns its place. Radial connects back to your GitHub repo, so you keep GitHub as your code host and graduate only the issue-tracking part.

What is the best git issue tracker?

It depends on what "git" means to you. If you literally want issues stored as files inside your repository, git-native tools like git-bug embed a distributed bug tracker in git objects. If what you actually want is issues that feel close to the code, open instantly, script from the terminal, and link to your branches and PRs, then a fast tracker that integrates with git beats storing issues as files, because a folder of Markdown can't auto-link a PR to an issue or give a teammate's agent a conflict-free way to file a bug. Radial is built for that second definition.

How do I create an issue from the command line?

With Radial, run radial create "Title of the issue" --team ENG --priority high. Add --json and the command returns the created issue as an object so your script can read the identifier back out, for example ENG-142. Install the CLI with npm i -g radial.build or brew install BrainGridAI/radial/radial. Every other command (list, search, show, close, import, export) takes --json too, so the whole tracker composes with your shell and CI.

Can I keep my issues in my git repository?

Not in Radial, and that is deliberate. Issues in Radial live in Radial, not in your .git directory, because storing shared issue state as committed files turns every parallel edit and every agent action into a merge conflict. What you get instead is the thing you actually wanted from in-repo issues: terminal speed, a scriptable CLI, and tight git integration that links branches, PRs, and commits to issues automatically. Your data stays portable either way. One command exports the whole workspace to JSON or CSV, always available, so leaving is a radial export away.

The short version

The developer who wants to commit a .issues/ folder to their repo has the right instinct and the wrong implementation. Issues should live close to the code, move at terminal speed, and stay connected to your branches and PRs. You do not have to hand-roll that. Radial is the fast, scriptable tracker that gives you the git-native feel, links to GitHub, GitLab, and Bitbucket, and lets your agents drive it for free.

See the full CLI, API, and MCP surface on the developers page, or read how to give your coding agent access to the tracker over MCP.

Originally published on the Radial blog.

Your Claude Code sub-agents keep losing the thread. Give them one shared record.

Nico Acosta — Mon, 20 Jul 2026 13:18:08 +0000

Claude Code agents come in a few shapes, and it is worth being precise before we get to the part that breaks. There are sub-agents: specialized configurations you define in your .claude/ folder, each with its own instructions and tools, that the main session hands work to. There are agent teams: independent Claude Code sessions that coordinate through a shared task list and peer messaging, with one session acting as lead. And there is the plain case of running two terminals at once, each a full Claude Code session working the same repo.

All three are genuinely useful, and the setup guides for them are good. What none of the setup guides tell you is what happens on the second day, when the context window that held all the coordination fills up, compacts, and takes the plan with it. That is the problem this post is about, and it is not a prompting problem.

What actually breaks when you run more than one agent

A single Claude Code session holds its state in the context window. That works until it doesn't: the window fills, auto-compact runs, and the running summary of what got decided and why gets squeezed to make room. The next session starts cold. One of the highest-voted write-ups on this exact topic calls it "context amnesia," and the fix people reach for is almost always some external record the agents read from and write to, because in-context memory resets at the session boundary by design.

Now run a team. Sub-agent A refactors the auth module and moves on. Sub-agent B, spun up an hour later in a fresh session, has no idea A already did that, because the only place that knowledge lived was A's context window, which is gone. The coordination layer Claude Code ships, the shared task list, keeps the team in sync while the team is alive. It is not where the work goes to be remembered after the session ends. So the failure mode is not "the agents are dumb," it is "the agents have nowhere durable to file what they did."

A developer in a recent thread described building exactly the missing piece by hand: a local API for the full issue lifecycle so that "the agent never polls GitHub, it just checks local state and the sync layer handles the rest." That instinct is right. The agents need one fast place to read and write the state of the work, separate from any one session's memory. The question is whether you build it or point at one that exists.

The shared record, and where it should live

An issue is the cheapest durable unit of that record. It has an owner, a status, a priority, and a comment thread, and it survives every context reset because it lives outside the model entirely. When an agent files an issue as it works and comments on it as it makes decisions, the next agent, or the next session of the same agent, reads the current state instead of reconstructing it from a summary that got compacted away.

Radial is that record, wired so agents can drive it directly. It ships a real CLI, a plain REST API, and an MCP server, all against the same issue lifecycle, so whichever way your agents reach it, they read and write the same state. Point Claude Code's sub-agents at it once and the shared task list stops being the only coordination surface: the durable one is the tracker.

Here is a sub-agent reading its queue and filing what it finds, using the CLI (every command takes --json, so the output pipes straight into the next step):

# The agent reads what's assigned to it, in progress, as structured JSON
radial list --assignee me --status "in progress" --json

# It fixes the bug, closes the issue with a note the next session can read
radial close RAD-219 -m "Root cause: race in the token refresh. Fixed in #482."

# It found a second problem while in there, so it files that too
radial create "Auth retry loop on 401" -p high -l bug -a me --json

Nothing in that loop is Claude-specific. The same three verbs run from a REST call in CI, from the MCP server another agent is connected to, and from your own terminal, against one shared record. That is the point: the state of the work does not live in any single agent's head.

Why the record is the tracker and not a memory feature

There is a real distinction here, and it matters for honesty. Radial is not a memory layer, a context store, or a retrieval system for your agent. It does not persist your agent's context or try to be a smarter CLAUDE.md. It is a fast issue tracker that agents can drive over CLI, REST, and MCP, and the durable record is a side effect of agents filing and updating issues the normal way, not a feature bolted on top.

That line is deliberate. The intelligence stays in your agent, your model, your keys. Radial holds the record. There is no copilot in it, no AI summary, no auto-triage, and no AI credit meter, because your agent already does that part and you already pay for it once. The Plain Software Pledge is the binding version: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

And because every agent credential is a client of the API, not a billed seat, running a team of sub-agents against Radial costs nothing extra. The price is $50 per user, per year, flat, billed annually, for the humans. Agents ride free. That is not a promotion; it is the structure. A fleet of ten sub-agents all writing to the same tracker is still just the humans on the workspace.

FAQ

What are Claude Code agents?

There are two related things. Sub-agents are specialized configurations you define in your .claude/agents/ folder, each with its own system prompt and tool set, that the main Claude Code session delegates tasks to. Agent teams are independent Claude Code sessions that coordinate through a shared task list and peer messaging, with one acting as lead. Both let you split work across specialized or parallel workers instead of one monolithic session.

How do Claude Code agent teams stay in sync?

While the team is running, sessions coordinate through Claude Code's shared task list and direct messaging. That keeps them aligned in the moment. What it does not do is preserve the work after the sessions end, so for anything that needs to survive a context reset or hand off to a later session, you want an external record, an issue tracker the agents file into, that lives outside any one session's context window.

Why do my Claude Code agents forget what other agents did?

Because each session's knowledge lives in its context window, and windows fill up and compact. Once a summary gets squeezed out or a session ends, that knowledge is gone unless it was written somewhere durable. Two agents in separate sessions have no shared memory by default. The fix is a record outside the model: an issue with a status and a comment thread that any session can read the current state of.

Can Claude Code agents update an issue tracker automatically?

Yes, if the tracker exposes the right surface. Connect Radial's MCP server or hand your agents the CLI, and a sub-agent can search its queue, create issues, comment as it makes decisions, and close them when done, all in its own loop. See give Claude Code access to your issue tracker in 5 minutes for the MCP setup.

Does running a team of agents against Radial cost more?

No. Agent credentials are API clients, not billed seats. You pay $50 per user, per year, for the humans on the workspace, locked at the rate you join, and a team of ten sub-agents writing to the same tracker adds nothing to that.

The short version

Claude Code agents and agent teams are worth using, but the moment you run more than one, the coordination that lived in the context window becomes the thing you lose. Give the agents one durable record to file into, an issue tracker they drive over CLI, REST, and MCP, and the plan stops dying with the session.

See the full tool list and the CLI verbs on the developers page, or read an issue tracker your agents can actually drive for the system-of-record argument in full.

Originally published on the Radial blog.

Graduating from Trello: when a board needs to become a system

Nico Acosta — Sun, 19 Jul 2026 13:14:38 +0000

Most people who search "Trello alternative" are not unhappy with Trello. They outgrew it. The board that was perfect for ten cards and two people started creaking somewhere north of a few hundred, and the workarounds (a Power-Up here, a naming convention there, a label that secretly means "priority") stopped hiding the fact that a board is a board, not a system.

This guide is honest about that. If you want a lighter, prettier board, there is a good shortlist and you should pick from it. But if what you actually have is engineering work that has outgrown a stack of cards, the answer is not another board. It is a tracker: an opinionated issue lifecycle, fast search, and something your agents can drive from the terminal.

Why teams look for a Trello alternative

The reasons cluster, and the right alternative depends on which one is yours.

The board doesn't scale. Trello is a Kanban board first and everything else second. That is its strength at small scale and its ceiling at large scale. Once you have hundreds of cards across several lists, the flat board stops being a map and becomes a haystack. There is no real notion of an issue with a stable ID, a priority field that the tool understands, an estimate, or a sprint, so you rebuild all of that out of labels, custom fields, and Power-Ups, and the discipline erodes.

Everything is a Power-Up. Trello's model is a minimal core plus add-ons. Time tracking, reporting, dependencies, calendar views: each is a Power-Up you bolt on, and the free plan caps how many boards can carry them. What looked like simplicity turns into a pile of third-party extensions you now maintain, each with its own settings and its own bill.

You are tracking software work in it. This is the group the general listicles skip, and it is the one this piece is really about. A board is a fine place to track a launch checklist or an editorial calendar. It is a slow, lossy place to track engineering, because a card on a list is not an issue in a lifecycle.

If you want a better board: the honest shortlist

Radial is not a general-purpose board and will not pretend to be one. If what you want is a lighter or prettier version of what Trello does, pick from this list and stop reading:

A visual, non-technical team board. Monday.com and Asana are the usual moves for marketing, ops, and cross-functional teams that want boards, timelines, and clean task lists.
A free personal Kanban. Trello's own free tier, or a simple tool like Microsoft Planner if you already live in Microsoft 365, covers personal and small-team boards without much fuss.
Open-source and self-hosted. Focalboard, Wekan, Taiga, and OpenProject keep the board on your own infrastructure if that is the constraint.
A spreadsheet-shaped board. Airtable fits teams whose real need is structured records and views, not an issue lifecycle.

If you are in one of those groups, one of those is your answer. But if you have been running engineering work on a Trello board and feeling the drag, keep reading, because the shape of the tool is the problem, not the plan you are on.

When a board needs to become a system

The pattern is familiar. A team starts a board because it is the fastest way to see work move left to right. It is genuinely great at five cards. Then the work grows, and the board quietly stops being enough:

A card is not an issue. There is no stable short ID to reference in a commit, a branch, or a script. You cannot say "see RAD-219" in a pull request and have it mean something.
There is no opinionated lifecycle. Triage, priority, estimates, and sprints are things you fake with labels and lists, and the fakery is only as reliable as the least-disciplined teammate.
Search and filtering are shallow. Finding "all high-priority bugs assigned to me across three boards" is not a first-class query; it is a manual hunt.
Automation lives in Power-Ups and Butler rules, not in a real API your scripts and coding agents can drive as the primary interface.

None of this makes Trello a bad product. It means a Kanban board is doing an issue tracker's job, and the friction you feel is the mismatch. Graduating is not an insult to the board; it is what happens when the work becomes a system and needs to be tracked like one.

A tracker that does one thing

Radial is a fast, keyboard-first issue tracker, and that is the entire product. Instant search, a command palette, list and board layouts, Cycles (time-boxed sprints), estimates, triage, and projects. Issues have stable short IDs like RAD-219 you can drop into a commit, a branch, or a CLI call. It does the one job a tracker does, and it does not try to also be your wiki, your whiteboard, or your everything-app.

Two things make it the deliberate next step up from a board.

One flat, locked price, with no meter. Radial is $50 per user, per year, flat, billed annually, locked at the rate you join. There is no AI add-on tier, no credit balance, and no usage meter, because there is nothing AI in the product to meter. The wedge is not that Radial is the cheapest option (the shortlist above lists plenty of cheaper and free boards on purpose). The wedge is that the number does not move: no per-Power-Up creep, no metered surface, no quarterly surprise.

A written pledge to keep it that way. The Plain Software Pledge makes it binding: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

This is not anti-AI. Your agent doing real work is great; the point is where the intelligence lives. It belongs to your agent, not baked into the tracker and billed back to you by the credit. Agents ride free in Radial. Every agent credential is a client of the API, not a billed seat, and Radial ships a real CLI, REST API, and MCP server for them to drive.

Trello has no direct one-command importer into Radial (the built-in radial import handles Linear and Jira exports), so graduating a board means recreating the work that still matters, which is usually a small subset of a large board. That is a create away, from the terminal or from CI:

npm i -g radial.build
radial create "Move active work off the Trello board into a real tracker" -t ENG -p high --json

Every command takes --json, so the same move scripts from CI, and your agent can do the equivalent over MCP at mcp.radial.build. Keep a board for the things a board is good at. Move the issues to a tracker.

Where Radial is honestly not for you

A fair comparison names the gaps. Radial is not a Trello replacement for the general-purpose-board job. It has no docs, no whiteboards, no forms, no CRM, no calendar-shaped planning surface. If your team wants a visual board for a marketing calendar, an event checklist, or a personal to-do system, Trello or Monday.com is the right call and Radial is not.

Radial is also not a whole-company work platform. There is no portfolio or initiative layer, no burndown or velocity dashboards, no roadmap timeline. It is built for engineering-led teams who want a fast tracker their agents can drive, not a planning-and-reporting suite. If those are load-bearing for you, better to hear it now than find out in a bake-off.

FAQ

Is there anything better than Trello?

"Better" depends on the job. For a general-purpose visual board, Monday.com or Asana; for a free personal Kanban, Trello's own free tier is hard to beat; for open-source and self-hosted, Focalboard or OpenProject. For tracking software work specifically, a dedicated issue tracker like Linear, Jira, or Radial beats a board, because an issue in a lifecycle is a different thing than a card on a list.

Does anyone use Trello anymore?

Plenty of people do, and for the right job it is still excellent: personal boards, small-team checklists, editorial and event calendars, anything where the value is seeing cards move left to right. What tends to break down is using it as the system of record for engineering work at scale, where a board's flat structure runs out of room and teams start rebuilding a tracker out of labels and Power-Ups.

Is there a free alternative to Trello?

Yes, several. Focalboard and Wekan are open-source and free to self-host, Microsoft Planner is free inside Microsoft 365, and Trello's own free tier covers a lot of personal use. Radial is not in this bracket; it is a paid, flat $50 per user per year, aimed at engineering teams that have outgrown a free board rather than at replacing one.

Can I use Trello as an issue tracker for engineering?

You can, and at small scale it works fine. A board with a few lists and a priority label tracks a handful of tasks well. It breaks down as you scale: no stable issue IDs, no opinionated lifecycle, triage and sprints faked out of labels, shallow search, and automation trapped in Power-Ups instead of a real API your coding agents can drive. At that point a dedicated tracker is the fix.

How do I move from Trello to a real issue tracker?

The honest answer is that most of a large Trello board is stale, so you rarely want a full one-for-one import. Recreate the work that still matters (usually a small active subset) in the new tracker, and going forward file straight into it. In Radial that is a radial create from the terminal or CI, or the equivalent create_issue call from your agent over MCP. There is no built-in Trello importer; radial import currently reads Linear and Jira exports.

The short version

Trello is a great board, and a board is the right tool for a lot of work. But a board is not a system, and engineering work eventually becomes a system: stable issue IDs, a real lifecycle, fast search, and an API your agents can drive. When the workarounds outnumber the work, that is the signal to graduate.

Radial is the tracker for that case. Fast and keyboard-first, one flat locked $50 per user per year, agents ride free over a real CLI, REST API, and MCP server, and a pledge that pays you if we ever add an AI meter.

See the one number on pricing, or read the manifesto for why a tracker should stay a tracker. If you are weighing the everything-apps instead, here is the honest take on when a ClickUp alternative is really an issue-tracker question in disguise.

Originally published on the Radial blog.

An issue tracker your agents can actually drive

Nico Acosta — Fri, 17 Jul 2026 13:13:16 +0000

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.

Originally published on the Radial blog.

File issues from CI with the Radial CLI and --json

Nico Acosta — Thu, 16 Jul 2026 13:15:46 +0000

A failed CI job already knows everything a good issue needs: which test broke, on which commit, in which job, with a link to the logs. The problem is that this information dies in a pipeline log unless someone reads the red X, copies the details into your tracker by hand, and assigns it. That someone usually forgets, and the flake comes back next week as a surprise.

The fix is to let the pipeline file the issue itself. With the radial CLI, that is one command: radial create, with --json so your script can read back the identifier of the issue it just filed. No browser, no dashboard, no human in the loop, and because every automation credential is an agent that rides free, no seat cost for the CI job doing the filing.

The one command

Here is the whole move. When a job fails, create an issue titled after the failure, tagged to the right team and priority, and capture the returned identifier:

# In a CI job that runs on failure. RADIAL_API_KEY is a scoped key stored as a secret.
issue=$(radial create "CI failed on ${CI_COMMIT_SHORT_SHA}: ${FAILED_JOB}" \
  --team ENG \
  --priority high \
  --label ci \
  --description "Job ${CI_JOB_URL} failed on ${CI_COMMIT_BRANCH}. Logs attached above." \
  --json)

# --json returns the created issue as an object; read the human-readable id back out.
echo "Filed $(echo "$issue" | jq -r '.id') — $(echo "$issue" | jq -r '.url')"

The --json flag is the part that makes this scriptable. Every radial command takes it, and for create it emits the created issue as a single JSON object. The field you almost always want is .id, the human-readable identifier like RAD-412, so your pipeline can print it, post it to a chat, or hand it to the next step. There is also .url if you want to link straight to the issue, and .status, .priority, .team if you want to assert what you filed. These are real fields on the response, not invented ones: the CLI speaks the same human-readable shape everywhere, so you get RAD-412 and ENG back, never a raw UUID.

Why the CLI and not raw REST

You can absolutely do this against the REST API with curl, and for some pipelines that is the right call. But the CLI buys you three things that matter inside CI:

One binary, no request plumbing. npm i -g radial.build or brew install BrainGridAI/radial/radial and you have the command. You are not hand-rolling headers, JSON bodies, and error handling in bash.
Human-readable in, human-readable out. You pass --team ENG and --priority high, not internal ids you had to look up first. The response comes back with RAD-412 and status names, so the identifier you print is the identifier a human recognizes.
--json on every command. The same flag that makes create scriptable also makes list, show, search, and close scriptable, so the CLI composes. A cleanup job can radial search "CI failed" --json to find yesterday's flakes and radial close the ones that a rerun already fixed.

The CLI is a thin, honest wrapper over the same REST surface. Reach for curl when you are already deep in a language runtime and adding a dependency is a hassle; reach for the CLI when you want the shortest correct line in a shell script.

The credential: a scoped key, stored as a secret

CI is non-interactive, so there is no browser to click "approve" in. That means you authenticate with a scoped API key, not OAuth. Mint one key for this job, give it exactly the access it needs, and store it as a CI secret:

radial keys create "ci-bot" --scope write

The key comes back once, prefixed rk_, and you paste it into your CI provider's secret store as RADIAL_API_KEY. If a CI job only ever files bugs and never closes them, you could even scope it to something narrower, but filing needs write, so write is the honest scope here. The important part is that this is one key for one job: if it ever leaks, you revoke that one credential and leave the rest of your automation running. That is the whole argument for one scoped key per agent.

And the key provisions its own agent identity in the workspace, which never counts as a billed seat. Your CI bot is not a $50 user. The humans on the team are the seats; the pipeline is a free client of the API. There is no per-agent charge and no AI credit meter anywhere in the product, which is the Plain Software Pledge in practice: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

Wiring it into a pipeline

The pattern is provider-agnostic, because it is just a shell command reading environment variables your CI already sets. In GitLab CI it is an after_script or a job with when: on_failure; in GitHub Actions it is a step with if: failure(); in a Jenkins pipeline it is a post { failure { ... } } block. In every case the shape is the same:

The job fails.
A failure hook runs radial create with the commit, branch, and job URL pulled from the CI environment variables.
--json returns the new issue; you capture .id and .url and print or post them.

Because create is idempotent only if you make it so, a naive setup will file a fresh issue every time a flaky job fails. If that is noisy for you, add a radial search --json guard before creating: look for an open issue with the same title, and only radial create when there is not one already. The CLI composes precisely because every command speaks --json.

FAQ

How do I create an issue from a CI pipeline automatically?

Run radial create inside a failure hook in your pipeline (GitLab when: on_failure, GitHub Actions if: failure(), Jenkins post { failure }). Pass the title, team, priority, and a description built from your CI environment variables, and add --json so the pipeline can read back the created issue's identifier. Authenticate with a scoped rk_ API key stored as a CI secret. That is the entire integration: no plugin, no webhook server, just a CLI command in a hook.

How do I get the new issue's ID back in my script?

Add --json to radial create. It prints the created issue as a JSON object, and the human-readable identifier is on the .id field (for example RAD-412). Pipe it through jq -r '.id' to capture just the identifier, or read .url to link straight to the issue. Every field the CLI returns is human-readable by design, so you get RAD-412 and ENG, not UUIDs.

Does a CI bot filing issues cost a seat?

No. The API key you mint for the job provisions an agent member, and agent members never count as billed seats. You pay the flat $50 per user, per year, billed annually for the humans on the workspace, and that number does not move when you add a CI bot, a triage agent, or a whole fleet of them. Agents ride free.

How do I avoid filing a duplicate issue every time a flaky job fails?

Guard the create with a search. Run radial search "<the failure title>" --json first, and only call radial create when it returns no open match. Because every radial command takes --json, the search result is machine-readable and easy to test in a shell condition. Import is single-run and create is not deduplicated for you, so this guard is how you keep the tracker from filling up with copies of the same flake.

Can my coding agent do this instead of a shell script?

Yes. If an interactive agent like Claude Code is already connected over the MCP server, it can call create_issue directly when it notices a failing job, no CLI required. The CLI path is for the non-interactive case: a pipeline running headless with no human at the browser. Same tracker, same free agent identity, two ways in.

The short version

A red pipeline should file its own issue. Install the CLI, mint one scoped write key, and run radial create ... --json from a failure hook, then read .id back out to link the issue you just filed. The CI bot is a free agent, the identifier that comes back is one a human recognizes, and nothing about it touches a meter.

See the full CLI and API surface on the developers page, or read how scoped API keys let you give each automation exactly the access it needs.

Originally published on the Radial blog.

The best AI for project management isn't in the tool. It's your agent.

Nico Acosta — Wed, 15 Jul 2026 13:16:34 +0000

Search "AI project management tool" and you get a wall of the same product: ClickUp Brain, Asana Intelligence, Motion, Wrike, monday AI. Each one bolts a copilot into the sidebar that summarizes your standup, drafts your tickets, predicts your delays, and reshuffles your day. The pitch is that the intelligence should live inside the tracker.

We think it belongs somewhere else: in the agent you already run. The best AI for managing your work in 2026 is not a feature your tracker sells you by the credit. It is Claude Code, Codex, or Cursor, driving a fast tracker through real interfaces, with your keys and your model. The tracker's job is to be the fast, trustworthy record that agent writes to. That is a different design, and it changes what you pay and who you trust.

To be clear up front: this is not an anti-AI take. AI is genuinely redefining a lot of software, and the intelligence in your workflow is real and welcome. The narrow claim is that the tracker is not the thing that should host it.

The category is converging on a meter

Watch how these tools price the intelligence. The pattern the whole category is settling into looks like this: bring your own agent and it's free, use the hosted agent and it's credit-based. One product in an adjacent space said it in plain words: "connecting your own agent is free. The hosted agent is credit based."

That fork is worth staring at, because it tells you where the money is. The vendor gives you a free door (your own agent, through an API) and a metered door (their agent, in their sidebar), and every incentive they have is to push you through the metered one. The copilot gets more prominent each release. The free API gets less documentation. The credit balance in the corner is the business model, not a convenience.

Radial deletes the second door entirely. There is no hosted agent to meter, so there is no meter. You bring your own agent, and it rides free, forever, because that is the only kind of agent the product has. The intelligence is yours; the record is ours; nothing in between bills you.

What "your agent, not the tool's" actually looks like

The concrete difference is where the thinking happens. In the copilot model, the tracker's AI reads your board and generates a status update inside a UI you rent. In the bring-your-own model, your agent already has the context (it wrote the code, it ran the tests, it read the failing CI log) and it files the result straight into the tracker through an interface built for exactly that.

Here is the whole loop, from the terminal, with the real CLI:

npm i -g radial.build
radial create "Investigate flaky checkout test in CI" -t ENG -p high --json

That returns JSON your scripts, your CI, and your agent can read. Every command takes --json. Your agent can do the same over MCP at mcp.radial.build, or hit api.radial.build/v1 directly with a scoped, revocable key, one per agent, read-only or triage-only if you want to keep it on a short leash. Point Claude Code at it and it creates issues, updates status, and closes them as it works. You get the intelligence of a frontier model doing project management, and the tracker never sees a token of it or charges you for one.

The reason this matters is control. The harness your agent runs in is the real lever, and it is brittle when a vendor owns it: swap the underlying model and a copilot built around last quarter's model can break. When the intelligence is your agent talking to a plain REST and MCP surface, you swap models freely and the tracker does not care. It was never in that loop.

But don't I lose the summaries and the auto-scheduling?

You lose the vendor's version of them. You do not lose the capability, because your agent is strictly more capable than a copilot pinned to one tracker's sidebar. Ask Claude Code to summarize what shipped this cycle and it reads the issues over MCP and writes you a summary in whatever form you want. It is not limited to the template the vendor shipped, and it does not cost a credit.

What you actually give up is the meter, the copilot you have to relearn every quarter, and the risk that the AI feature you built a workflow around gets repriced or deprecated. Those are the things worth losing.

FAQ

What is the best AI project management tool?

For engineering teams, the better question is which tracker your agent can drive, because the strongest "AI for project management" available in 2026 is a frontier coding agent (Claude Code, Codex, Cursor) with access to your work, not a copilot bolted into a tracker. Radial is built for that model: a fast issue tracker with a CLI, an MCP server, and a REST API, so your agent does the intelligent work and the tracker stays the fast record it writes to.

Is AI project management software worth it?

If "AI" means a metered copilot inside the tool, it is worth scrutinizing: you are paying a per-credit surcharge for a feature your own agent can already do, and you are locking that workflow to one vendor's model choices. If "AI" means your own agent driving the tracker through real interfaces, it is worth a lot, and with Radial it costs nothing extra because agents ride free.

Does Radial have AI features built in?

No, on purpose. Radial ships no copilot, no built-in AI, and no credit meter. It ships the surface your agent runs on: a CLI, an MCP server at mcp.radial.build, and a REST API. This is written down as a binding pledge, so it is a commitment, not a mood: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

How is this different from ClickUp Brain or Asana Intelligence?

Those put the AI inside the tool and bill it, often as credits on top of your seats. Radial puts the AI in your hands (your agent, your model, your keys) and keeps the tracker a plain, fast system of record. One flat price, no metered surface anywhere, and your agents work for free.

How much does it cost?

$50 per user, per year, flat, billed annually. Agents ride free. No trial gimmick, no free tier, no tiers, no credits, no "contact sales." The rate you join at is the rate you keep. See pricing for the one number.

Point your agent at the tracker, not the other way around

The AI project management tool you are looking for is probably already open in another terminal tab. Give it a fast tracker it can drive, keep the intelligence on your side of the line, and stop paying a meter for a copilot you didn't ask for.

Wire your own agent in through the developer surface, or read exactly what we will and won't build in the manifesto. And if you want the fuller case for a tracker that stays out of the way, here is why boring on purpose wins in 2026.

Originally published on the Radial blog.

The agile project management tool that is just a fast issue tracker

Nico Acosta — Tue, 14 Jul 2026 13:14:43 +0000

Search for an agile project management tool and the results tell you what the category has become: Jira, Asana, monday, ClickUp, Zenhub, Azure DevOps, each pitched as a platform that can do everything a whole company might ever need. Backlogs and boards, yes, but also timelines, portfolios, dashboards, resource planning, forms, docs, goals, and a marketplace of add-ons on top. The tool grew to fit every team in the building, and somewhere in there the actual job (track the work, run the sprint, ship) got buried under the parts you will never touch.

This post makes the opposite case. For most software teams, the right agile tool is the small one: a fast issue tracker with real, time-boxed sprints and a real command line, and nothing else you have to configure, grow into, or pay for before it helps you. Agile was supposed to be lightweight. The tooling forgot.

What "agile project management tool" usually means, and why that is the problem

The phrase covers a wide spread. On one end you have Jira, the industry standard for software teams: deeply customizable, built for Scrum and Kanban and scaled frameworks like SAFe, and heavy enough that it needs an administrator. On the other you have the everything-apps (ClickUp, monday, Asana) that market ten different views and pitch themselves to marketing, ops, and HR as much as to engineering. What they share is a direction: more surface, more configuration, more that has to be set up before the thing does its one job.

The result is a familiar tax. The board is fine, it is always fine, but it arrives wrapped in a planning suite you did not ask for. New engineers spend their first week learning the tool instead of the codebase. Half the fields on an issue are mandatory and nobody remembers why. The dashboard reports up to someone who does not read it. None of that moves a card from To Do to Done, and all of it is friction on the one workflow you actually run every day.

Agile methodology is deliberately minimal: short iterations, working software, respond to change. The tooling that grew up around it went the other way, and "agile project management tool" now mostly means "a large platform that happens to include a board."

The smaller thing: a tracker, not a platform

Here is the version worth wanting. An agile tool is doing its job when it gives you exactly four things and gets out of the way:

Issues you can create in a second. A title, an owner, a priority, an estimate if you use them. Not a fifteen-field intake form.
A board and a list over the same work. Board when you want the at-a-glance flow, list when you want to scan and sort. Same issues, two layouts, no migration between them.
Real sprints. A time-boxed cycle with a start and an end that scopes the board to this iteration, not the entire backlog. That boundary is what makes a board agile rather than an endless pile.
A way to drive all of it without the mouse. A real command line, so filing and updating work is something you can script, not a chore you click through.

Notice what is not on that list: roadmaps, portfolios, resource-allocation grids, burndown dashboards, goal-tracking, a docs wiki. Those are the features that turn a tracker into a platform, and a platform is a different, heavier thing than most engineering teams need. The smaller tool is not a stripped-down version of the big one. It is the correct size, chosen on purpose.

This is the honest place to say what Radial actually ships, because "just a fast issue tracker" has to mean something concrete. Radial gives you issues, board and list layouts, Cycles (time-boxed sprints with a start and an end), estimates, a triage step for unsorted work, priorities, projects, and Git integrations that link branches, commits, and PRs to issues. That is a genuine agile workflow: plan the cycle, run the board, ship, reset. Radial does not ship burndown or velocity charts, scrum dashboards, roadmaps, timelines, milestones, or a portfolio suite, and that is a design decision, not a backlog we are racing to clear. If a burndown chart reporting up to leadership is load-bearing for your team, Radial is honestly the wrong tool and Jira exists for exactly that. If what you want is the board and the sprint minus the everything-suite, that is the whole product.

The part almost no agile tool gets right: the command line

Sprints and boards are table stakes. The thing that separates a tracker you fight from a tracker you forget you are using is whether you can drive it from where you already work: the terminal.

When the board lives behind a web app you can only click, keeping it current is manual labor. Someone drags a card in a meeting; someone updates a status after the fact; the board drifts from reality between standups. When the tracker has a first-class CLI, the board updates itself as a byproduct of the work, because filing and moving issues is just another command in the same shell where you run your tests and your git.

Every Radial command takes --json, and issues carry a --cycle, so you can file work straight onto the current sprint and read the board back as data:

# File an issue onto sprint 14's board, high priority, with an estimate
radial create "Rate-limit the export endpoint" -t ENG -p high --cycle 14 --estimate 3 --json

# Read that sprint's in-progress work back as JSON you can pipe anywhere
radial list --cycle 14 --status "in progress" --json

Because --json is on everything and the cycle is just a flag, the board stops being a place you visit and becomes something you script. A CI job files a failing-build issue directly onto the sprint. A pre-commit hook checks what is on your plate this cycle. And your coding agent does the same operations over MCP, filing and moving cards using the identical API a human uses. Every credential is a client of the API, not a billed seat, so your agents ride free: there is no per-agent charge for letting Claude Code or Codex keep the board current.

The bill should be boring too

Agile pricing has quietly gotten complicated. Most tools are per seat per month, and most now meter AI work on top of that, a credit allowance per seat, a separate charge for the agent that touches the board, a tier you get bumped into when your team grows. The number you sign up for stops being the number you pay.

Radial is one number: $50 per user, per year, flat, billed annually, locked at the rate you join. No per-agent seats, no AI credits, no usage meter, because there is no AI in the product to meter. That is backed by the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you did not ask for, your subscription is free. This is not anti-AI. Your agent doing real work on the board is exactly the point. The intelligence lives in your agent, over the CLI and MCP, not billed inside the tracker.

FAQ

What is an agile project management tool?

An agile project management tool is software that helps a team plan, track, and deliver work iteratively, using frameworks like Scrum or Kanban. In practice that means a backlog, a board (columns for status, cards for issues), and time-boxed sprints, so the team can see what is queued, in progress, and shipped this iteration. The category ranges from focused issue trackers to large everything-platforms that bundle roadmaps, dashboards, and resource planning on top of the board.

What are the top agile project management tools?

The tools that dominate the category are Jira (the customizable industry standard for software teams), Asana and monday and ClickUp (broad everything-suites that serve many departments), and developer-centric options like Zenhub (GitHub-integrated) and Azure DevOps (tied to the Microsoft stack). They differ mostly in how much surface they add around the board. Radial sits at the focused end on purpose: a fast issue tracker with real sprints and a first-class CLI, without the portfolio and dashboard suite.

Do you need a heavyweight tool to run agile?

No. Agile methodology is deliberately minimal, short iterations, working software, responding to change, and the tooling only needs to support that: issues, a board, and a time-boxed sprint. Heavyweight platforms add roadmaps, dashboards, and resource planning that most engineering teams never use, and that surface becomes setup cost and ongoing friction. A focused tracker with real Cycles covers the actual agile workflow with far less to configure.

What is the difference between a scrum board and a kanban board in an agile tool?

Both are column-and-card boards; the difference is the time-box. A kanban board is continuous, work flows in and out with no reset. A scrum board is scoped to a sprint: you pull a fixed set of work onto it at the start of the cycle and reset at the end. A good agile tool gives you both layouts over the same issues so you do not have to choose upfront. Radial covers this with board and list layouts plus Cycles; see a fast board and real sprints, without the scrum tax for the full breakdown.

Can you drive an agile tool from the command line?

Most cannot, at least not as a first-class path. Radial can: every command takes --json and issues carry a --cycle flag, so you can file, list, and update work on the current sprint from the terminal, a CI job, or a git hook, and read the board back as structured data. Your coding agent can perform the same operations over MCP using the identical API, and because agents are clients rather than billed seats, they ride free.

The short version

Most agile project management tools grew into platforms: a board wrapped in a planning suite you have to configure, grow into, and pay a climbing bill for. The smaller thing is often the right thing, a fast issue tracker with real sprints and a real command line, sized to the job instead of the org chart. Radial ships issues, board and list layouts, Cycles, estimates, projects, and Git integrations, scriptable from the terminal and drivable by your agents, at one flat locked $50 per user per year with no AI meter. It does not ship burndown charts, roadmaps, or dashboards, on purpose.

See the one number on pricing, or read how the same CLI turns the tracker into something you script in engineering project management without the overhead.

Originally published on the Radial blog.

monday makes you pre-buy AI credits. We sell one flat number.

Nico Acosta — Mon, 13 Jul 2026 13:17:12 +0000

If you searched "monday alternative," the fastest honest answer is: it depends on why you are leaving. monday.com is a capable, highly visual work-management platform, and for a lot of teams the reason to look elsewhere is price, not features. As of May 6 2026, monday no longer gives new signups free AI credits, so the AI you get nudged toward is a metered line item you pre-buy alongside your seats. That is the specific thing this post is about.

This guide serves both readers. If you want another broad work-management platform, there is an honest shortlist below. If you are an engineering team that has been running your work in monday and mostly want a fast tracker that does not sell you credits, that is a different move, and it is the one Radial is built for.

If you want another work platform: the honest shortlist

monday is a general work-management tool. People leave for concrete reasons, and the right replacement depends on which one is yours.

You want the same shape, cheaper. If monday's boards, automations, and dashboards work for you and the problem is the bill, ClickUp and Asana are the usual swaps, both broad platforms with free tiers and lower entry pricing. The catch is that each is now layering its own AI meter on top: ClickUp AI Super Credits, Asana AI Studio credits. You may be trading one meter for another.

You want spreadsheets and databases. If your team lives in grids, Smartsheet gives you a spreadsheet-style planner and Airtable is the database-first option with strong views and relations. SmartSuite comes up often on Reddit as the "same features without the nickel-and-diming on views" pick.

You want free and simple. For very small teams, Trello and Plaky cover basic visual boards at or near free. They stay simple, which is the point and the limit.

You want open-source or self-hosted. Plane and Huly get named a lot in developer threads as the self-hostable escapes, with GitHub and Slack coverage. The trade is you run the infrastructure.

If one of those fits, take it and stop reading. Radial is not a broad work-management platform and will not pretend to be one. But there is a group the "best monday alternative" listicles never write for.

If you're a dev team, monday was probably never the right category

Here is the pattern. monday is easy to start in, so engineering work lands in a board with a Status column, a few automations, and a dashboard. It looks fine. Then the work scales and the mismatch shows:

It is a visual work platform, not a tracker tuned for an issue lifecycle. Triage, sprints, and estimates are things you assemble out of columns and discipline, not native primitives.
Items are rows in a board, not stable short identifiers. "The bug in RAD-219" is not something you can drop into a commit message or a terminal.
Your coding agents cannot drive it the way they drive a real developer surface. There is an official monday MCP, but the model underneath is a work-management platform, not an issue API.
And the AI you keep getting pushed toward is metered. Per-seat pricing plus a credit meter that climbs with usage is the exact bill-you-didn't-choose problem.

None of that makes monday a bad product. It makes it the wrong category for a team that just wants to track engineering work fast. The fix is not a cheaper everything-platform. It is a tracker built to track.

A tracker that stays a tracker, at one number that never moves

Radial is a fast, keyboard-first issue tracker, and that is the whole product. Instant search, a command palette, list and board layouts, Cycles (time-boxed sprints), estimates, triage, and projects. Issues have stable short IDs you can reference in a commit or a script. It does the one job a tracker does.

Two things make it a deliberate counterpoint to monday's direction.

One flat number, and no meter anywhere. Radial costs $50 per user, per year, flat, billed annually, locked at the rate you join. There is no AI credit balance, no usage meter, and no overage line, because there is no AI in the product to meter. The Plain Software Pledge makes that binding: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free. monday's sharpest data point is that AI credits became something new signups must buy; Radial's is that there is no credit to buy, ever.

Your agents ride free. This is not anti-AI. Your agent doing real work is great, and plenty of tools now let you bring your own agent for free too. The difference here is that the whole product is that flat number with no metered surface anywhere. Every agent credential is a client of the API, not a billed seat, and Radial exposes a real CLI, REST API, and MCP server for agents to drive. Run a fleet of them and your bill does not move.

Because what strands most teams is getting the work out of the old tool, filing into Radial is meant to cost a command, not a project. You (or an agent) can create straight from the terminal:

npm i -g radial.build
radial create "Move issue tracking off monday" -t ENG -p high --json

Every command takes --json, so the same move scripts from CI, and your agent can do the equivalent over MCP at mcp.radial.build.

Where Radial is honestly not for you

A fair comparison names the gaps. Radial is a dev issue tracker, not a whole-company work platform. There is no portfolio or initiative layer, no roadmap timeline or Gantt, no burndown or velocity dashboards, no CRM, no forms, no docs. If your team uses monday to run marketing, sales, and ops in one place, Radial does not replace that and is not trying to.

It is built for engineering-led teams who want a fast tracker their agents can drive at a price that does not climb. If a whole-company platform is what you need, one of the tools in the first section is the honest answer, and we would rather say so now than lose your trust in a bake-off.

FAQ

Who is monday.com's biggest competitor?

For broad work management, monday competes most directly with ClickUp, Asana, Smartsheet, and Wrike, all general platforms in the same shape. For the narrower slice of teams using monday to track engineering work, the real competitors are dedicated issue trackers like Linear, Jira, GitHub Issues, and Radial, which are built around an issue lifecycle rather than a general board.

Is there a cheaper alternative to monday.com?

Several tools have lower entry pricing than monday, including ClickUp, Asana, Trello, and Plaky, and open-source options like Plane can be self-hosted for infrastructure cost only. The catch on the paid platforms is that most now add an AI credit meter on top of per-seat pricing, so the headline price is not the whole bill. Radial takes a different shape: one flat $50 per user per year, locked, with no metered surface anywhere, though it is a dev issue tracker, not a broad work platform.

Does monday.com charge extra for AI?

Yes. monday's AI features are metered in credits, and as of May 6 2026 those credits are no longer free for new signups, so AI is billed on top of your per-seat cost. Its agents draw from the same credit pool. This per-seat-plus-a-meter model is the reason many teams start pricing out alternatives.

Can I use monday.com as an issue tracker for engineering?

You can, and at small scale it works. A board with a Status column tracks a handful of issues fine. It gets awkward as you scale, because monday is a general work-management platform rather than a tracker with a native issue lifecycle: no real triage inbox, no built-in cycle or estimate primitive, no stable short issue IDs for commits, and an API shaped for work management rather than an issue API for agents to drive. At that point a dedicated tracker is the cleaner fit.

What is the best monday.com alternative for developers?

If you want a broad platform, ClickUp or Asana are the common swaps. If you are a developer team that mostly wants a fast, scriptable tracker, a dedicated issue tracker beats a general work platform: stable short IDs, a real CLI and REST API, an MCP server your agents can drive, and, in Radial's case, one flat locked price with agents riding free instead of an AI credit meter.

The short version

monday.com is a strong, visual work-management platform. If you want another one, cheaper or self-hosted, the first section has the honest shortlist. But if you are a dev team that landed in monday because it was easy to start and now wants a fast tracker without an AI meter attached, the problem is the category, not the plan tier.

Radial is the tracker for that case. Fast and keyboard-first, one flat locked $50 per user per year, agents ride free over a real CLI, REST API, and MCP server, and a written pledge that pays you if we ever add a meter.

See the one number on pricing, or read the manifesto for why a tracker should stay a tracker. If you are weighing the everything-apps, here is the honest ClickUp alternative take too.

Originally published on the Radial blog.

DEV Community: Radial

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

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

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

The record Radial is

Where the line is

FAQ

What are background agents?

What are background agents good for?

Where should a background agent read its tasks from?

Does running more background agents against Radial cost more?

Does Radial run or trigger the agent?

The short version

Why the results appear before the spinner would: how a tracker feels instant

The default architecture makes you wait

Keep the working set in the client

Where this is honest, and where it is not

The same idea, from the terminal

FAQ

What is local-first software?

Does Radial work offline?

Why does filtering feel instant but search does not?

How does optimistic editing avoid losing my changes?

Is a faster tracker actually worth switching for?

The short version

GitHub stores the code, not the decision. Where the \"why\" should actually live.

What goes in an ADR

When to write one

The decisions that never make it to doc/adr/

Two records, one repository

FAQ

What is an architecture decision record?

What should an ADR contain?

When should you write an architecture decision record?

What tools are there for architecture decision records?

Where should decisions live if not in an ADR?

Do ADRs replace commit messages or a changelog?

The short version

Agentic coding ships the 80%. Your tracker holds the other 20%.

The 80% problem, stated plainly

Where the durable 20% should live

Why this is a tracker, not an AI feature

FAQ

What is agentic coding?

What is the 80% problem in agentic coding?

How is agentic coding different from vibe coding?

Where should an AI coding agent record its work?

Does running multiple coding agents against Radial cost more?

The short version

You don't want a git issue tracker. You want issues that live next to your code.

Why developers keep reinventing the git issue tracker

What actually solves it: the terminal, not the filesystem

The part the repo can't give you: linking to git

Why this matters more once agents are filing the issues

FAQ

Does GitHub have an issue tracker?

What is the best git issue tracker?

How do I create an issue from the command line?

Can I keep my issues in my git repository?

The short version

Your Claude Code sub-agents keep losing the thread. Give them one shared record.

What actually breaks when you run more than one agent

The shared record, and where it should live

Why the record is the tracker and not a memory feature

FAQ

What are Claude Code agents?

How do Claude Code agent teams stay in sync?

Why do my Claude Code agents forget what other agents did?

Can Claude Code agents update an issue tracker automatically?

Does running a team of agents against Radial cost more?

The short version

Graduating from Trello: when a board needs to become a system

Why teams look for a Trello alternative

If you want a better board: the honest shortlist

When a board needs to become a system

A tracker that does one thing

Where Radial is honestly not for you

FAQ

Is there anything better than Trello?

Does anyone use Trello anymore?

The decisions that never make it to `doc/adr/`