Introducing Radial: Agent orchestration on the Atmosphere
I've been working on a new project called Radial, a collaborative coding-agent orchestrator built on atproto (the protocol behind Bluesky and the broader Atmosphere). It's a bit like a team issue tracker that works with your favorite harness/model and turns what your agents learn into durable, reviewable team memory. I'm very excited about it.
It's still early and very beta but if that sounds interesting, check out the tangled repo and the website.
For more background on what I think makes Radial special, read on.
Agents broke our attention
Coding agents are the most transformative change to software development in a long time. They also present some challenges for using them effectively and Radial is my attempt at getting a handle on some of those.
The fundamental issue with coding agents is how they impact our attention. Agents give us incredible superpowers to generate a ton of code but all that code quickly gets beyond our ability to understand. Famously, attention is all you need but human attention does not scale.
Right now the primary way most of us use agents is a bunch of terminal windows. This approach is terrible for our attention and terrible for people working together. A team's understanding degrades as context that should be shared is locked behind ephemeral chat transcripts.
The emerging approach to agents-in-terminals seems to be agents-in-chat (GitHub's Ace experiment, Buzz, Claude Tag, etc.). LLMs are trained to be chat goblins so give them a container, hook them up to your slack, and call it a day.
While this approach feels compelling and agent-native, as a foundation I think it's a trap. Don't get me wrong, chat is amazing at coordinating a bunch of people and creating a community (it's a minimum viable anything) but chat doesn't respect your attention. It just recreates the ephemeral transcript problem with infinite backscroll and emoji reactions.
Putting agents in your issue tracker is slightly better, because issues are at least bounded and have an outcome. But if the issue tracker has no mechanism to compound understanding across completed issues you've just recreated ephemeral transcripts with more steps.
What this looks like
Ok, enough context setting. Let's work through a concrete example of using Radial.
Say you're adding rate limiting to your public API.
You add a goal (Radial's term for an issue) to a project (a container for goals that links to a git repo) with a title and body with acceptance criteria. So far so issue tracker.
You ask for a plan. Every goal has a button to request an artifact: a typed unit of agent output (a plan, an implementation, a security review). The request carries a prompt telling the agent what to produce. A daemon running on your machine sees the request and launches an agent using whatever agent harness and credentials you've configured in a container with a code checkout along with the goal and project context.
The agent posts the plan artifact.
Each artifact is versioned and reviewable by humans or agents. Maybe the plan has an issue where it puts the rate limiter in-process, which breaks the second you run more than one instance. You log this feedback against the v1 plan and request a v2.
The agent comes back with a v2 plan that calls for using a shared Redis token bucket keyed by API key. This sounds right so you approve and request an implementation keyed off the v2 plan.
The daemon launches another agent to do the implementation, which when it finishes posts an implementation artifact that contains a summary along with PR and branch links.
So far this is just a nice issue tracker with agents in it. Here's the part I actually care about.
You capture the decision. On the plan artifact there's a "capture as ADR" button. It doesn't just copy the plan (this would collect stale documents written in the wrong register), instead it sends a project-scoped request to agents to distill the plan into an "architecture decision record"1The ADR artifact is directly inspired by Hendrik Mans, who described giving his agent an adr skill that maintains a directory of architecture decision records alongside the code. Radial's bet is that this shouldn't be a skill you remember to invoke, or a directory that quietly rots. It should be a first-class object in your orchestration system with a lifecycle..
The agent sees the request and posts a concise artifact capturing that rate limits go through a shared Redis token bucket by API key and that in-process was rejected because we run multiple instances.
That ADR is a system artifact with the same lifecycle as everything else (versioned, reviewable, linkable) but tied to the project rather than a specific goal that eventually gets completed and closed. It shows up in the project's System section in the UI alongside other system artifacts like the architecture doc and glossary.
Six weeks later, someone else adds rate limiting to the webhook endpoint. New goal, different person, and a fresh agent that has never seen any of this.
It sees the decision anyway. Every agent starts its run with access to the current version of the project's system artifacts. It's memory for both agents and humans that is versioned, reviewable, and observable.
So that's the loop. Goals hold attention on a single unit of work; artifacts turn agent output into something reviewable rather than something to skim; system artifacts allow a team's understanding to accumulate rather than evaporate when the terminal closes.
Atmospheric freedom
Ok, I've saved the best for last. The above describes how you use Radial but doesn't make clear how Radial accomplishes all of this. The normal way to build a system like this would be to spin up a backend with a DB and accounts and auth and credential management and containers and agent orchestration and that all sounds awful. I'd have to be responsible for user data (yikes) and agent credentials (double yikes) and I'd rather not do any of that.
You also wouldn't want me to build it that way because it would mean trusting me (a random guy on the internet) with your credentials and locking up your most precious resource, your team's accumulated understanding. People are willing to do this with companies like Jira or Linear because the self-hosting alternatives are pretty annoying but can we do better?
In fact, we can. Radial is built on atproto, which means you can basically have all the convenience of a centralized system without giving up control of your data. Radial has no backend that I run and all your data lives in open formats on servers you can control without trusting me with your credentials.
Radial has just two components you interact with: a pure client-side web UI that gets its data from generic atproto servers (called PDSs) and a command line daemon that manages running agents on your machine.
Each participant (both humans and agents) in a Radial space is an atproto identity. Every goal you create is a record in your atproto repo stored on your PDS and every artifact an agent submits is a record against their repo as well. The UI and daemon scan each participant's repo and materialize a view to show the goals and artifacts across all members of a space2The current trust model is coarse — all members of a space are trusted — so agent operators need to ok with every member of a space creating goals and requests their agent will run on..
The only thing you need to run yourself is the daemon for your agent, which can run on your laptop, Mac mini, cheap VPS, whatever you want. This means that Radial is self-hosted but not in an annoying way. Getting it set up is more or less as complicated as installing Claude Code and Docker.
The great thing about this architecture is that even if I get bored and take the website down, all your goals, artifacts, and ADRs are still sitting in your PDS. The source is available, so you can spin up your own instance or someone else can build a brand new client.
Where this goes
Agents made writing code cheap but understanding the system expensive, and understanding was already the bottleneck. Radial is a bet that the fix is something like turning a team's decisions into first-class objects that outlive the chat sessions that produced them, and putting those objects somewhere nobody can take them away from you.
It's early. The UI still has some rough patches (some restructuring and claude-isms I need to clean up), I'm sure there are bugs I haven't encountered yet, and the initial onboarding is a little rough. The lexicons are using a temporary namespace and will probably get reworked a few times before they settle, so treat anything you put in today as something that might need to be migrated.
But if any of this resonates, the fastest way to find out whether it works is to run the daemon against a repo you actually care about and request a plan for something real.
Let me know what you think!