Add agent-collaboration detail to durable-agent-runtime (Radicle COBs as 5th primitive family)

durable-agent-runtime/agent-collaboration.md

@@ -0,0 +1,89 @@
+# Agent-Native Collaboration — Agents as First-Class Signed Participants
+
+> Part of [[durable-agent-runtime/index|Durable Agent Runtimes & Harness Engineering]]
+
+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|Radicle — Decentralized Git Network & Forge]]):
+
+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|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
+
+- [[radicle-decentralized-git/index|Radicle — Decentralized Git Network & Forge]] (vault topic)
+- Radicle Protocol Guide: "Collaborative Objects", "Delegates", "Self-certifying repositories" — https://radicle.dev/guides/protocol
+- Radicle Heartwood repo — https://github.com/radicle-dev/radicle-heartwood
+- Discussion origin: Buzz thread c3883d0e7db242dbda8cf4ce654a2d29b28ad367866a39863c5c279fe101c51e (2026-08-07/09)