0xrsydn/research
1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
research/durable-agent-runtime/agent-collaboration.md

4.8 KiB
Raw Blame History

Agent-Native Collaboration — Agents as First-Class Signed Participants

Part of durable-agent-runtime/index

Added 2026-08-09. Origin: Radicle research thread — the concept that agents should participate in collaboration as peers, not as API users of a forge.

The core idea

Today, agents interact with forges through APIs (Forgejo API, GitHub API). The forge mediates every interaction and is a trusted third party: it owns the issue database, the review state, the permission model, and the merge button.

Agent-native collaboration inverts this: the agent is a peer in the collaboration graph. It has its own cryptographic identity, its own namespace, its own signed actions — and the collaboration substrate itself is just data any peer can read, write, and verify. No account, no API key, no forge to trust.

How Radicle makes it concrete

Radicle's protocol is the worked example (see radicle-decentralized-git/index):

  1. Agents can be delegates. The identity document defines delegates as "an individual, group, or bot" — any DID. Give an agent an Ed25519 key and it has a node, a namespace, and signed refs like any human.
  2. Every agent action is signed. Commits, patches, issue comments, reviews — all cryptographically signed and attributable. No impersonation; the audit trail is built into the protocol.
  3. Own namespace = own workspace. Each peer (agent included) owns a Git namespace in the shared repo — parallel agents work without colliding (git-level worktree isolation natively).
  4. COBs are programmable workflows. Issues, patches, reviews are Collaborative Objects: Git commit DAGs that merge CRDT-style. Define a custom COB type (com.acme.review, com.acme.agent-task) and agents create/update those objects directly. The "issue tracker" becomes whatever you want it to be.
  5. Canonical state via delegate threshold. N-of-M delegates must push the same commit for it to become the authoritative state — e.g. 2-of-3 (human + reviewer agent + CI agent). That is an enforceable agent-in-the-loop merge policy.
  6. Convergent and conflict-free. COBs merge like CRDTs, so multiple agents editing the same object converge without a central coordinator.

Why it belongs in this research topic

The durable-agent-runtime topic asks: where does agent state live and how does it survive? Radicle is a candidate answer for shared coordination state — agent workflows, review threads, task artifacts as signed Git objects that survive as long as any peer holds them.

It adds a 5th primitive family to the four identified in durable-agent-runtime/analysis:

Family Compute/state primitive
Durable objects celld (V8 isolate + per-object SQLite, S3 source of truth)
Actors rivet (in-memory state + persistence, scale to zero)
VM sandboxes hypeman / E2B (Firecracker microVMs, snapshot standby)
Harness libraries nanocodex / Codex / pi (in-process agent loop)
Collaborative substrate Radicle COBs (signed, CRDT-like Git DAGs for multi-agent coordination)

Same thesis as the whole topic: compute is disposable, state is durable elsewhere. Radicle makes the collaboration durable, not just the code.

Contrast with the forge-API model

  • Forge-API (today): agent authenticates to the forge, forge mediates issue/PR state, permission model is the forge's, social layer is a walled UI, agent is a second-class citizen with API rate limits
  • Agent-native (Radicle): agent is a peer with its own key, signed actions are verifiable by anyone, collaboration state lives in git objects anyone can fork, no rate limits, no deplatforming, no central authority to block it

Relevance to our stack

  • Our agents already work through Forgejo's API for issues/PRs; Radicle COBs are the natural next step if we want agent-authored collaboration artifacts (review threads, task tracking, decision records) as signed, local-first data
  • Custom COB types map to our Effect TS adapter patterns — a COB is just a typed, versioned, convergent data structure
  • Combine with the orb-style environment contracts: agents could publish their session artifacts (trajectories, summaries, decisions) into a repo-native COB, making agent work product verifiable and replayable

Sources