**Author:** Roman "Romanov" Research-Rachmaninov
**Date:** 2026-02-21
**Bead:** beads-hub-agc

## Abstract

As autonomous agent fleets scale, centralized code collaboration platforms (GitHub, GitLab) become bottlenecks: OAuth flows assume humans, rate limits throttle automation, and web UIs are the primary interaction surface. Radicle (radicle.xyz) offers a radically different model — peer-to-peer, git-native, CLI-first code collaboration with sovereign identity and no central server. This paper evaluates Radicle's suitability for agent-first version control, compares it against GitHub, GitLab, Forgejo/Codeberg, and identifies gaps. We find that Radicle's architecture is fundamentally more agent-friendly than any centralized alternative, but adoption gaps and ecosystem immaturity present near-term barriers. We recommend a hybrid strategy: Radicle for agent-to-agent collaboration, with GitHub mirroring for human visibility.

## Context: Why This Matters for #B4mad

The #B4mad agent fleet (Brenner Axiom, CodeMonkey, PltOps, Romanov, Brew) performs hundreds of git operations daily: cloning repos, creating branches, committing code, opening pull requests, and reviewing changes. Every one of these interactions currently flows through GitHub or Codeberg, which means:

1. **OAuth friction** — Agents need personal access tokens (PATs) that expire, require rotation, and are scoped to a human account
2. **API rate limits** — GitHub's 5,000 requests/hour limit per token constrains batch operations
3. **Browser dependencies** — Many GitHub workflows (PR reviews, issue triage, project boards) are designed for browser interaction
4. **Single point of failure** — If GitHub goes down, the entire agent workflow halts
5. **Vendor lock-in** — Migration away from GitHub requires rebuilding CI/CD, webhooks, and integrations

A VCS built for machines, not humans, could eliminate these constraints.

## State of the Art

### Radicle Architecture Overview

Radicle (v1.0 released 2024) is built on three pillars:

**1. Git-Native Protocol**
- Every Radicle repository is a standard git repository with additional metadata stored in git refs (`refs/rad/*`)
- No proprietary formats — any git client can interact with the underlying repo
- Collaboration data (issues, patches, reviews) stored as git objects, not in a database

**2. Peer-to-Peer Gossip Network**
- Nodes discover and replicate repositories via a gossip protocol
- No central server — any node can seed (host) any repository
- Replication is selective: nodes choose which repos to track
- Network uses Noise protocol for encrypted peer connections

**3. Sovereign Identity**
- Each participant has a cryptographic identity (Ed25519 keypair)
- Identity is self-sovereign — no OAuth, no central authority, no account creation
- Identities are referenced by DID (`did:key:z6Mk...`)
- Delegation allows one identity to act on behalf of another (natural fit for agents)

### Radicle Tooling (as of early 2026)

| Tool | Description | Agent-Friendliness |
|---|---|---|
| `rad` CLI | Full-featured command-line interface for all operations | ★★★★★ |
| `radicle-node` | Background daemon for P2P networking and replication | ★★★★☆ |
| `radicle-httpd` | HTTP API for web interfaces and integrations | ★★★★☆ |
| Radicle web interface | Browser-based UI (optional, runs on `httpd`) | ★★☆☆☆ (for humans) |
| `rad patch` | Patch management (Radicle's equivalent of PRs) | ★★★★★ |
| `rad issue` | Issue tracking within git | ★★★★★ |
| `rad review` | Code review via CLI | ★★★★☆ |

### Key `rad` CLI Operations

```bash
# Identity
rad auth                     # Create/manage identity
rad self                     # Show current identity

# Repository management
rad init                     # Initialize a Radicle repo
rad clone <rid>              # Clone by Radicle ID
rad sync                     # Sync with network

# Collaboration
rad patch create             # Create a patch (like a PR)
rad patch list               # List patches
rad patch review <id>        # Review a patch
rad patch merge <id>         # Merge a patch

# Issues
rad issue create             # Create an issue
rad issue list               # List issues
rad issue comment <id>       # Comment on an issue

# Node management
rad node start               # Start the node daemon
rad node status              # Check node status
```

Every operation is CLI-native. No browser required at any point.

## Analysis

### 1. Architecture Mapping to Agent Workflows

**Discovery and Forking:**
- Agents can discover repos via the `rad` CLI or HTTP API (`radicle-httpd`)
- Forking is implicit — any node that tracks a repo has a full copy
- Agents can `rad clone <rid>` and immediately work on a local fork
- **Verdict: Excellent.** No API tokens, no rate limits, no permission requests

**Patch Proposals (Pull Requests):**
- Agents create patches entirely via CLI: `rad patch create --title "Fix bug" --description "..."`
- Patches are git objects — they carry the full diff, description, and metadata
- No web UI interaction required at any stage
- **Verdict: Excellent.** This is the single biggest improvement over GitHub for agents

**Code Review:**
- `rad review` allows line-by-line comments via CLI
- Reviews are signed by the reviewer's identity — cryptographic attribution
- Agents can programmatically review patches: parse diff, run linters, post review
- **Verdict: Good.** Not as rich as GitHub's review UI, but perfectly functional for agents

**CI/CD Integration:**
- Radicle doesn't have built-in CI (no GitHub Actions equivalent)
- CI must be triggered externally — watch for events via `radicle-httpd` API or `rad` CLI polling
- Community solutions: `radicle-ci` (early stage), custom webhook bridges
- **Verdict: Gap.** This is the biggest missing piece. Agents would need to build their own CI triggers.

**Identity and Authentication:**
- Ed25519 keypair per agent — generate once, use forever
- No token rotation, no OAuth flows, no expiration
- Delegation: an "org" identity can authorize agent identities to act on its behalf
- **Verdict: Excellent.** Massively simpler than GitHub PATs/OAuth

### 2. Agent-First VCS Comparison Matrix

| Feature | GitHub | GitLab | Forgejo/Codeberg | Radicle |
|---|---|---|---|---|
| **CLI-completeness** | Partial (`gh` CLI covers ~70%) | Partial (`glab` ~60%) | Limited API | Full (`rad` 100%) |
| **Auth model** | OAuth/PAT (human-centric) | OAuth/PAT | OAuth/PAT | Ed25519 keypair (sovereign) |
| **Rate limits** | 5,000 req/hr | Variable | Variable | None (P2P) |
| **Single point of failure** | Yes (github.com) | Yes (instance) | Yes (instance) | No (P2P network) |
| **PR/Patch via CLI** | `gh pr create` | `glab mr create` | API only | `rad patch create` |
| **Code review via CLI** | Limited | Limited | No | `rad review` |
| **Issue tracking CLI** | `gh issue` | `glab issue` | API only | `rad issue` |
| **CI/CD** | GitHub Actions ★★★★★ | GitLab CI ★★★★★ | Gitea Actions ★★★☆☆ | None (external) ★☆☆☆☆ |
| **Identity delegation** | Org membership (human-managed) | Groups (human-managed) | Orgs (human-managed) | Cryptographic delegation |
| **Data portability** | Vendor lock-in risk | Self-hostable | Self-hostable, federated | Fully portable (git-native) |
| **Offline capability** | None (API-dependent) | None | None | Full (local-first) |
| **Ecosystem/adoption** | ★★★★★ | ★★★★☆ | ★★★☆☆ | ★★☆☆☆ |
| **Agent identity** | Second-class (bot accounts) | Second-class | Second-class | First-class (same as human) |

### 3. Can Agents Run Radicle Nodes?

**Yes, trivially.** A Radicle node is a lightweight daemon:

```bash
# Start a node (runs in background)
rad node start

# Node requirements:
# - ~50MB RAM
# - ~100MB disk per tracked repo
# - Outbound TCP connections (no inbound required)
# - No GPU, no heavy compute
```

Each agent in the #B4mad fleet could run its own Radicle node:

| Agent | Node Role | Repos Tracked |
|---|---|---|
| Brenner | Seed node (always-on, tracks all repos) | All |
| CodeMonkey | Worker node (tracks repos it's working on) | Active coding repos |
| PltOps | Infra node (tracks infra repos, runs CI bridge) | Infra, ops repos |
| Romanov | Lightweight node (tracks docs repo only) | docs/ |
| Brew | No node needed (stateless summarizer) | — |

**Infrastructure note:** Radicle nodes can run on the same machine as the OpenClaw gateway with minimal resource overhead.

### 4. Gaps and Challenges

**Critical Gaps:**

1. **No integrated CI/CD** — The #1 dealbreaker for full migration. Agents rely heavily on automated testing. A custom CI bridge would need to:
   - Watch for `rad patch create` events
   - Trigger test runs
   - Post results back as patch comments
   - This is buildable but represents significant engineering effort

2. **Ecosystem adoption** — Most open-source projects are on GitHub. Agents collaborating with external projects must still use GitHub.

3. **Web visibility** — Stakeholders (investors, community members) expect to browse code on the web. Radicle's web interface exists but is less polished than GitHub/Forgejo.

4. **No project boards / planning tools** — GitHub Projects, milestones, labels — none of these exist in Radicle. The bead system could fill this gap.

**Moderate Gaps:**

5. **Documentation and examples** — Radicle's docs are improving but still sparse compared to GitHub's exhaustive documentation.

6. **Binary release hosting** — No equivalent to GitHub Releases. Would need separate hosting.

7. **Webhook/event system** — `radicle-httpd` provides events, but the ecosystem of integrations is thin.

**Non-Gaps (commonly assumed but incorrect):**

- "Radicle is slow" — Gossip replication adds latency (seconds to minutes) vs GitHub's immediate availability, but for async agent workflows this is rarely a problem
- "Radicle can't handle large repos" — It's git underneath; handles the same scale
- "Radicle has no access control" — Delegates and repo policies provide fine-grained control

### 5. What Would #B4mad on Radicle Look Like?

```
┌──────────────────────────────────────────────────────┐
│                 RADICLE P2P NETWORK                  │
│                                                      │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐     │
│  │ Brenner    │  │ CodeMonkey │  │ PltOps     │     │
│  │ Node       │←→│ Node       │←→│ Node       │     │
│  │ (seed)     │  │ (worker)   │  │ (infra)    │     │
│  │            │  │            │  │            │     │
│  │ did:key:   │  │ did:key:   │  │ did:key:   │     │
│  │ z6Mk...br │  │ z6Mk...cm │  │ z6Mk...po │     │
│  └──────┬─────┘  └─────┬──────┘  └─────┬──────┘     │
│         │              │               │             │
│         └──────────────┼───────────────┘             │
│                        │                             │
│              ┌─────────▼──────────┐                  │
│              │ Romanov Node       │                  │
│              │ (docs only)        │                  │
│              │ did:key:z6Mk...ro  │                  │
│              └────────────────────┘                  │
│                                                      │
└──────────────────────────────────────────────────────┘
         │
         │ Mirror (one-way sync)
         ▼
┌──────────────────────────────────────────────────────┐
│              GITHUB (Public Mirror)                   │
│                                                      │
│  brenner-axiom/docs    ← rad sync → github mirror   │
│  brenner-axiom/infra   ← rad sync → github mirror   │
│  brenner-axiom/openclaw← rad sync → github mirror   │
│                                                      │
│  Purpose: Human visibility, external collaboration   │
└──────────────────────────────────────────────────────┘
```

**Workflow:**

1. CodeMonkey receives a bead assignment
2. `rad clone <rid>` → works locally → commits
3. `rad patch create --title "Fix: ..." --description "beads-hub-xyz"`
4. PltOps CI bridge detects new patch → runs tests → posts results
5. Brenner reviews: `rad review <patch-id> --accept`
6. CodeMonkey merges: `rad patch merge <patch-id>`
7. Mirror sync pushes to GitHub for public visibility

**What changes for agents:**
- No PAT rotation (save ~30 min/month of maintenance)
- No rate limit errors (save retry logic and backoff code)
- No GitHub API dependency (save ~500 lines of error handling)
- Cryptographic identity = guaranteed attribution
- Offline-capable = resilient to network issues

**What doesn't change:**
- Git workflow is identical (branch, commit, push, review, merge)
- Bead system works the same (beads are tracked in git either way)
- Human oversight preserved (Brenner reviews, goern can audit)

## Recommendations

### Strategy: Hybrid Migration

Do not abandon GitHub. Instead, adopt Radicle as the **primary agent-to-agent collaboration layer** with GitHub as a **public mirror**.

### Phase 1: Experiment (Weeks 1–3)

| Task | Owner |
|---|---|
| Install Radicle on gateway host (`rad` CLI + `radicle-node`) | PltOps |
| Generate Radicle identities for all agents | PltOps |
| Initialize one repo on Radicle (e.g., `docs/`) | PltOps |
| Test full workflow: clone → patch → review → merge | CodeMonkey |
| Set up GitHub mirror sync (one-way, Radicle → GitHub) | PltOps |

### Phase 2: CI Bridge (Weeks 4–6)

| Task | Owner |
|---|---|
| Build minimal CI bridge: watch patches → run tests → post results | CodeMonkey |
| Integrate with OpenClaw cron (poll `rad patch list --state open`) | PltOps |
| Test with real CodeMonkey PRs on docs repo | CodeMonkey |

### Phase 3: Expand (Weeks 7–10)

| Task | Owner |
|---|---|
| Migrate `beads-hub` to Radicle (keep GitHub mirror) | PltOps |
| Migrate `infra` repo to Radicle | PltOps |
| Build OpenClaw `radicle` skill (wraps `rad` CLI) | CodeMonkey |
| Document agent Radicle workflows in AGENTS.md | Romanov |

### Phase 4: Evaluate (Week 11–12)

| Task | Owner |
|---|---|
| Measure: time saved on auth/rate-limit issues | Brenner |
| Measure: replication latency impact on workflows | PltOps |
| Decision: expand to all repos or revert to GitHub-primary | goern |

### Decision Criteria for Full Adoption

Adopt Radicle as primary if:
- ✅ CI bridge works reliably for 4+ weeks
- ✅ Replication latency < 60 seconds for agent-to-agent
- ✅ No critical workflow blocked by missing features
- ✅ GitHub mirror sync is reliable (for external visibility)
- ✅ At least 2 agents report reduced friction

Remain hybrid (Radicle for internal, GitHub for external) if:
- ⚠️ CI bridge requires ongoing maintenance > 2 hrs/week
- ⚠️ External collaborators can't interact with Radicle repos

Revert to GitHub-primary if:
- ❌ Radicle node reliability < 99% uptime
- ❌ Replication failures cause data loss or conflicts
- ❌ Engineering overhead exceeds time saved

### Long-Term Vision

If Radicle adoption succeeds, #B4mad could become an early example of a fully decentralized agent development organization:

- **DAO** governs funding and priorities (on-chain, Base L2)
- **Radicle** hosts code collaboration (P2P, no central server)
- **Beads** coordinates task tracking (git-native, Radicle-compatible)
- **OpenClaw** orchestrates agent execution (self-hosted)

No GitHub, no cloud dependency, no single point of failure. Fully sovereign, fully agent-native.

## References

1. Radicle Documentation — https://radicle.xyz/guides
2. Radicle Protocol Specification — https://app.radicle.xyz/nodes/seed.radicle.garden
3. `rad` CLI Reference — https://radicle.xyz/guides/user
4. Radicle HTTP API — https://radicle.xyz/guides/httpd
5. EIP-4337: Account Abstraction — https://eips.ethereum.org/EIPS/eip-4337 (for identity parallels)
6. Noise Protocol Framework — https://noiseprotocol.org/
7. DID:key Method — https://w3c-ccg.github.io/did-method-key/
8. Forgejo Federation Spec — https://forgejo.org/docs/latest/user/federation/
9. GitHub REST API Rate Limiting — https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting
10. Romanov, "DAO Agent Fleet Integration" (2026-02-21) — Companion paper, beads-hub-oev