Agentic Organization Design and Collaboration

Regen AI
1

Three Stacks, One Substrate — Org-OS, Egregore, and RegenOS Are Converging on the Same Pattern

TL;DR. Three independent open-source stacks — Regen Coordination’s Org-OS template, Egregore (Curve Labs / Egregore Labs), and Regen Network’s RegenOS + KOI substrate — have arrived at the same architectural shape: an agent-native organizational workspace. Five primitives keep showing up: an identity document the agent loads first, Git as shared memory, slash commands as ceremony, session bookends with auto-sync, and federation declared as data. None of these stacks compete; they compose. The post that follows lays out what each stack adds on top, where the gaps are, and a few feedforward recommendations the Tokenomics WG, the Regen Commons stewardship council, and the ReFi DAO community can each pick up immediately. There’s also a small note at the end about the Open Civics Knowledge Commoning hackathon and how the knowledge-commons-swarm prototype might nest inside this picture.

Why we’re posting

We’ve been watching the same pattern emerge from three corners of the regenerative-finance / open-coordination space, all at once, all open-source, all without coordination. That kind of convergence is rare and load-bearing. When teams who don’t talk to each other build the same thing, the thing is usually right.

This post is an offering: a synthesis of what we’ve read, an invitation to compose rather than compete, and a few concrete suggestions the people who already engage with this work can pick up tomorrow if they want to.

What we read

Regen Coordination’s Org-OS template — an MIT-licensed, fork-this-and-go template for running a DAO/coop/nonprofit/network as an “agent-native organizational workspace.” A single Git repo combines EIP-4824 / DAOstar on-chain identity (.well-known/dao.json auto-generated from data/*.yaml registries by a GitHub Action), a multi-runtime agent layer (Claude Code, OpenCode, Cursor), and a federation manifest (federation.yaml v3.0) with a customizations: array that declares which paths survive an upstream sync.

Egregore (Curve Labs / Egregore Labs) — also MIT, also a Claude-Code-based shared-memory framework, paired with a conceptual manifesto that explicitly steps past “code-as-law” toward agent-mediated, file-substrate cognition. Two-mode architecture: local (sovereign, files-only) and connected (hosted Neo4j knowledge graph + Telegram). Net-new primitives: a mandatory worktree-per-topic discipline with a branch-guard.sh PreToolUse hook that blocks writes on main/develop; the /summon skill for persistent agent processes (“spirits”); and a /contribute PR primitive that pushes patterns from a downstream instance back to the upstream framework.

KOI (Knowledge Organizing Infrastructure, originating with Block Science) and RegenOS (Regen Network) — KOI is the federation/sensor layer that wraps any data source (“vacuum for data,” in one collaborator’s framing — orient the agent once, then point it at any directory and it spawns a sensor with built-in per-node consent). RegenOS is the team-visible operating system inside RND PBC that integrates the agentic harness, BizDev, product engineering, ops/finance, and KOI commons into a coherent fabric. Crucially, RegenOS adds two layers neither Org-OS nor Egregore ship today: claims-engine verification (KOI extract → witness → enforce, content-addressed, hash-anchored, countersigned) and ledger anchoring of canonical artifacts via x/data MsgAnchor.

A recent ReFi DAO ↔ KOI discovery conversation pulled all three threads together explicitly: the ReFi DAO team is building on a Git-based “org OS”; KOI federates Git repos as sensors; the claims engine adds the rigorous, deterministic knowledge-graph layer that LLMs alone can’t produce. Three substrates, one membrane.

The convergent substrate

All three stacks share these five primitives:

Primitive Org-OS Egregore RegenOS + KOI
Identity doc as substrate IDENTITY.md + SOUL.md + MASTERPLAN.md egregore.md CLAUDE.md, knowledge.md or agent.md hierarchy
Git as org memory data/*.yaml + memory/today.md memory/ symlinked Git repo vault/ + workspaces
Slash commands as ceremony .claude/commands/ + .opencode/skills/ .claude/skills/ ~/.claude/skills/
Session bookend with auto-sync /initialize + /close SessionStart + Stop hooks session-resume + session-wrap
Federation as data, not RPC federation.yaml v3.0 with customizations: array /update + /contribute KOI federation + cron sync

Each stack adds a distinct layer on top. Org-OS brings a publishable on-chain organizational-identity surface (EIP-4824), a working OPAL meeting-pipeline TypeScript bridge into a knowledge graph, declarative dashboarding, and a sync-safe customizations manifest. Egregore brings the strongest write-time discipline (branch-guard + worktree-per-topic), persistent-agent lifecycle (“spirits”), a clean two-mode degradation story, and a manifesto that frames collective cognition as transductive — structure precipitates from activity, the organization is collective cognition. RegenOS + KOI + claims engine brings the verification rail: rigorous content-addressing, ledger-anchored attestations, semantics, and an explicit lineage discipline that traces upstream contribution (Block Science → KOI → RegenOS → claims engine → ledger).

The proposed shape — RegenOS as nested operating fabric

graph TB
    subgraph PERSONAL["Personal · individual operating system"]
        P1["Local Git workspace<br/>identity doc · memory · skills"]
    end
    subgraph TEAM["Team · shared agentic workspace"]
        T1["Team repo (Org-OS / Egregore template)<br/>session bookends · branch-guard · dashboard"]
    end
    subgraph COMMUNITY["Community · bioregional / thematic cohorts"]
        C1["Federation manifest<br/>peers · upstream · downstream"]
        C2["KOI sensor cluster<br/>per-node consent · orient-once"]
    end
    subgraph COMMONS["Knowledge Commons · shared substrate"]
        K1["KOI federation layer<br/>data-vacuum · sensor library"]
        K2["Claims engine<br/>extract → witness → enforce"]
    end
    subgraph NETWORK["Network · verification + accountability"]
        N1["Regen Ledger<br/>x/data MsgAnchor · x/ecocredit"]
        N2["Conditional Use Agreement<br/>membership membrane"]
    end

    P1 --> T1
    T1 --> C1
    T1 --> C2
    C1 --> K1
    C2 --> K1
    K1 --> K2
    K2 --> N1
    N2 -.gates.-> K1

    style PERSONAL fill:#f0f7e8
    style TEAM fill:#dceac8
    style COMMUNITY fill:#bedca0
    style COMMONS fill:#9fcc7d
    style NETWORK fill:#7fb95a

The picture is intentionally nested. A person runs an agent against a local Git workspace. A team runs the same primitives against a shared repo (Org-OS or Egregore or RegenOS — pick one). Communities and bioregions federate across teams via declarative manifests. The Knowledge Commons sits underneath as a shared substrate where KOI sensors compose a network-effect library. The Regen Network adds the verification rail — claims-engine pipelines that produce hash-anchored, countersigned attestations, and ledger anchoring that gives those attestations a public, content-addressable timestamp. A Conditional Use Agreement (a governance proposal currently under discussion in Regen Commons) gates how outside agents draw on the commons.

Crucially: none of these layers force a chain choice on anyone. Egregore is chain-agnostic by design. Org-OS ships an EIP-4824 surface but doesn’t require it. RegenOS uses Cosmos-native ledger anchoring, but the substrate around it is portable. The substrate is the convergence point; the verification rail is what Regen Network specifically contributes.

Roadmap — what could happen between now and end of year

gantt
    title Convergence Roadmap (illustrative, no team commitments)
    dateFormat YYYY-MM
    axisFormat %b %Y

    section Substrate adoption
    Branch-guard + worktree-per-topic hook (port from Egregore)        :2026-05, 1M
    Session-bookend skills (port from Org-OS /initialize + /close)     :2026-05, 1M
    Two-mode local/connected degradation                               :2026-06, 1M

    section Identity + federation
    .well-known/dao.json for Regen Network                             :2026-06, 2M
    federation.yaml customizations: pattern (regen-ai-core split)      :2026-06, 1M
    KOI sensor library (community-contributed)                         :2026-06, 4M

    section Verification rail
    OPAL meeting-pipeline.ts → claims-engine ingestion path            :2026-07, 2M
    First cross-org claim anchored to regen-1                          :2026-08, 1M
    Conditional Use Agreement proposal published                       :2026-07, 1M

    section Governance + commons
    Inverted-subsidy precedent codified                                :2026-07, 1M
    Lineage / upstream-contribution discipline (Block Science model)   :2026-06, 6M
    First federated knowledge-commons hackathon output                 :2026-06, 1M

This is illustrative, not a commitment. Each item is independently adoptable. Items in the substrate adoption lane are direct ports of MIT-licensed code; items in identity + federation are config-level; items in verification rail are where Regen Network’s distinctive contribution lives.

Feedforward recommendations

For three of the audiences this post is meant to reach, here’s where we think the lowest-friction next step lies. None of these are asks for a commitment — they’re sketches.

For the Tokenomics WG / agentic-tokenomics community: Egregore’s /summon “spirits” primitive — a persistent, named, long-running agent process with a clear lifecycle — maps cleanly onto the four Protocol Politicians agent characters and the M015 contribution-weighted-rewards mechanism. Adopting the metaphor and the file conventions could give the agentic-tokenomics rollout a clearer mental model for “what an agent is” without rewriting the implementation.

For the Regen Commons stewardship council: two governance ideas surfaced in the recent ReFi DAO conversation that deserve a council pass. First, a Conditional Use Agreement as a membership membrane — gating MCP servers (the Regen MCP, the ReFi DAO MCP) behind commoner credentials makes the commons-membership value proposition concrete and machine-checkable. Second, an inverted-subsidy precedent for new-member onboarding: rather than the commons subsidizing technical setup for new entrants, early adopters lean in and contribute back, while later members can pay for engineering escalation. Both ideas need community deliberation; both are sketches, not proposals.

For the ReFi DAO community: the ReFi DAO podcast/blog/academic corpus is already structured (markdown / XML, decade-plus archive). KOI is designed exactly for this — orient an agent once, point it at the corpus directory, and it spawns a sensor with per-node consent. The interop is real; the on-ramp is sharing a language. We’d love to see the first ReFi-DAO-hosted KOI sensors join the network-effect library.

For RND PBC’s own RegenOS, the team-visible adoption recommendations are a longer document — not the subject of this post — and the agentic-tokenomics repo is where the agent-side artifacts will land as they mature.

Open Civics hackathon — a small note

The Open Civics Knowledge Commoning hackathon (May 2026) is sitting at exactly the right moment for this convergence. The knowledge-commons-swarm prototype that’s already taking shape gives us a frame for it.

A few sketches (zero team commitment — these are invitations to think with):

  • Each participating org runs a KOI sensor over its own Git workspace. The hackathon produces the seed of a federated sensor library that survives the event.
  • One end-of-event artifact is a hash-anchored attestation — a claims-engine pipeline that countersigns “this content emerged from this swarm, here are the contributors, here is the ledger anchor.” This demonstrates the architectural pattern is available; it doesn’t ask anyone to commit to using it long-term.
  • The “knowledge commoning” framing lines up naturally with the inverted-subsidy precedent and the Conditional Use Agreement membrane — the hackathon is a forcing function for both governance ideas to get a real-world stress test.

The nested relationship: Open Civics ⊂ Knowledge Commons ⊂ KOI federation ⊂ verification rail (claims engine + ledger anchoring). Each layer adds rigor; none requires the next; everyone keeps their own substrate.

Open invitations

  1. Read the source repos. Org-OS, Egregore, the Egregore manifesto, KOI / Block Science. All are MIT or open-license. Lift what’s useful.
  2. Tell us where we got it wrong. This post is a first-pass synthesis from outside two of the three stacks. If you’re closer to Org-OS, Egregore, KOI, or any of the adjacent work, the corrections are more valuable than the synthesis.
  3. Bring the next sensor. If your org has a knowledge corpus that wants federation, that’s the most direct way to make this real.
  4. Push back on the verification framing. Whether claims-engine + ledger anchoring belongs at the bottom of this stack or somewhere off to the side is a real question. We think it’s the bottom; we’d rather find out we’re wrong now than later.

Acknowledgments and lineage

This synthesis stands on work by:

  • Block Science (github.com/BlockScience) — KOI originator and ongoing steward; the upstream-contribution discipline below is theirs first.
  • Curve Labs and Egregore Labs (blog.curvelabs.eu/egregore, github.com/egregore-labs) — the Egregore manifesto and OSS framework.
  • Regen Coordination (github.com/regen-coordination) — Org-OS template (with ReFi BCN heritage upstream).
  • The Regen Network team and contributors — KOI integration, claims engine, ledger anchoring, RegenOS framing.
  • The ReFi DAO contributors who joined the recent KOI discovery conversation and made the convergence visible.

The lineage matters. KOI is open-source today because Block Science built it, and stays open-source because users contribute upstream. We’re trying to honor that pattern as we go.

References (every link resolves for a public reader)

Source stacks:

Regen Network primary sources:

Standards + adjacent specs:

Hackathon + community:

This post is a draft. Comments, corrections, additions welcome on the forum thread or as PRs against the source repos. Posted in collaborative spirit — the synthesis is more useful if it’s wrong in places that get fixed than if it’s vague enough to never be wrong.

1 Like
2

Reply: Adding Parachute + Prism to the Convergence Picture

Two stacks worth folding into this picture, both showing up at Open Civics in May.

A fourth substrate: Parachute.computer

Parachute.computer (Colorado Public Benefit Corporation, AGPL-3.0-or-later, alpha) implements the same agent-native primitives at personal-vault scale: a local SQLite knowledge graph (notes, tags, links, attachments) exposed to any AI client over MCP, plus a modular ecosystem (Vault, Notes as a reference PWA, CLI, Octopus for team coordination, Daily voice journaling, Scribe for transcription + LLM cleanup, Channel for messaging gateways, and a sketch-status Agents layer on Cloudflare Durable Objects).

Two notes worth bringing into the convergence frame:

  1. Vault is OpenBrain-shaped at the data layer and Karpathy-shaped in posture. Typed SQLite rows + graph traversal (find-path) + cheap CRUD ingest = OpenBrain primitive. Single-user + Obsidian-bidirectional + file-over-app = Karpathy posture. The substrate is agnostic to the write-time-vs-query-time fork — the compilation layer (synthesis at ingest, the leg Karpathy’s wiki provides) is left for the consumer to add. This is exactly the SQLite-sidecar slot the Karpathy/OpenBrain analysis leaves open, already shipped and MCP-native.

  2. Composability is design intent. From parachute-patterns modularity rule: “Each piece stands alone. Compose what you want, leave the rest.” The Vault is intentionally minimal; the surrounding modules are deliberately swappable rather than locked. The substrate invites alternative implementations rather than positioning as a vendor stack — which makes it easier to compose with Org-OS, Egregore, KOI, and RegenOS than a traditional product.

There is also a useful new pattern in Octopus: tmux-based multi-agent coordination where one team-lead Claude Code session dispatches focused “tentacles” via /spawn into separate panes, with isolation: 'worktree' available per spawn. Sibling to Egregore’s /summon “spirits” — but ephemeral (tentacles dispatch, report, exit) where spirits are persistent. The two patterns compose: spirits for long-lived governance roles, tentacles for parallel implementation work.

Sibling: Prism, by a known collaborator

Prism by omniharmonic / Benjamin Life — same author as OPAL, already in the OP’s lineage chain via the meeting-pipeline TypeScript bridge — is an MIT-licensed Tauri 2.x + React 19 + Rust desktop personal OS that uses Parachute Vault as its canonical data layer over HTTP API at localhost:1940, never embedding source. This is the textbook AGPL-Vault + MIT-frontend pattern: the substrate’s network license obligations stay clean, the frontend is freely permissive, and the seam between them is the same MCP/HTTP surface KOI federation already speaks.

Prism adds 11 native renderers (document, code, presentation, task board, email, calendar, dashboard, etc.), a 22-tag-schema content type system, glass-morphism UI in dark and light modes, Claude Code CLI subprocess integration for inline AI editing (Cmd+J), and a v0.3-roadmapped plugin system. The relational graph: Parachute creators ↔ Benjamin Life ↔ omniharmonic/OPAL (already cited) ↔ all converging at Open Civics. One-step-removed orbit, not coincidence.

Where this lands in the nested architecture

The OP’s nested architecture (Personal → Team → Community → Knowledge Commons → Network) doesn’t need to change to accept these. Two refinements:

  • The Personal layer can name Parachute Vault as one supported personal substrate alongside local Git workspaces. The substrate choice doesn’t propagate up — exactly the loose-coupling property the OP argues for.
  • The composable-frontend slot. Prism demonstrates the Personal layer can have polished UI without forcing UI choice on Team or Commons layers. The v0.3 plugin system is the natural place to ship Regen-specific renderers (claims-engine views, deal-code displays, ecocredit dashboards) without building a parallel desktop app.

Open Civics is the meeting point

The OP’s note about the Open Civics Knowledge Commoning hackathon (May 2026) is more load-bearing than it looked at first read. With Org-OS, Egregore, KOI, RegenOS, Parachute, and Prism all converging in one virtual room in one week, the hackathon becomes the natural surface for substrate-level co-design rather than parallel-stack outreach.

Three concrete co-design propositions worth seeding now, in the OP’s spirit (sketches, not asks):

  • A KOI sensor pointed at a Parachute Vault — generalizes the “sensor around any local agent-native graph” thesis beyond Git, with a real graph backend as the demo target.
  • .well-known/parachute.json ↔ .well-known/dao.json (EIP-4824) convergence — same RFC 8615 pattern, two ecosystems, worth crosswalking or proposing a shared schema.
  • Claims-engine + ledger anchoring as Parachute’s missing provenance leg — the verification rail Regen Network specifically contributes is what the substrate-only architecture deliberately omits. Composable, not competitive.

Acknowledgments — two additions

  • Parachute Computer (PBC) — substrate authors. Modular-composable orientation, Octopus team-layer for Claude Code, AGPL-3.0-or-later. Showing up at Open Civics.
  • omniharmonic / Benjamin Life — OPAL upstream (already in the lineage), Prism author, in the Parachute orbit. Demonstrating the AGPL-Vault + MIT-frontend pattern in working code.

Same posture as the OP. The synthesis is more useful if it gets corrected than if it stays vague enough to never be wrong.

1 Like
3

We think AI agents are about to run a lot of orgs.

Those orgs will need tamper-proof records of what their agents decided. Regen Ledger can be that rail.

We’re going to test it at the Knowledge Commoning Swarm in May.
Want in?

Knowledge Commoning Swarm · Luma

https://x.com/ecowealth_eth/status/2048217452572774544?s=20

2 Likes