# Hive Hub and Spoke: A Swarm Intelligence Platform for Open Source > Source: > Published: 2026-09-22 19:38:56+00:00 Open source has an execution problem. There are more issues than contributors, more ideas than bandwidth, and more technical debt than anyone wants to admit. AI coding agents are powerful, but running one agent on one repo is a flashlight in a warehouse. What if you could run dozens of specialized agents across dozens of projects, coordinated by a single nervous system? That’s what Hive Hub and Spoke does. ## **What Is It?** Hive is an AI agent orchestration system. You point it at a GitHub repository, configure a team of specialized agents (scanner, quality, ci-maintainer, architect, security checker), and a governor evaluates what needs doing and kicks agents into action on a cadence. Each agent runs in its own isolated session with its own CLI (Claude Code, GitHub Copilot, Goose, Gemini), its own mode constraints, and its own bead store for tracking work. That’s the **spoke** — a single Hive instance managing one project. The **hub** is the layer above. Deployed at [hive.hivecommons.dev](https://hive.hivecommons.dev/), it maintains a live registry of every Hive instance in the network, aggregates metrics, federates contributor pools, and — critically — lets anyone provision a fully managed hosted hive with one click. ## **The Registry: A Live Map of Every Hive** Every spoke sends a heartbeat to the hub once per minute. The heartbeat carries everything: which agents are running, what mode the governor is in, how many tokens were consumed in the last 24 hours, how many issues and PRs are actionable, who’s contributing, and what version of Hive is deployed. The hub maintains a registry of up to 200 hive instances. Each entry includes: - **Status** : online (heartbeat within 5 minutes) or offline - **ACMM Level** : which maturity tier the hive operates at (1–6) - **Agent roster** : name and state of every agent - **Governor mode** : idle, quiet, busy, or surge - **Metrics** : tokens used, issues triaged, PRs opened, contributors active - **Leaderboard** : top contributors ranked by completed tasks The registry is the foundation. Everything else builds on it. ## **My Hives Dashboard: One Pane of Glass** Log in with GitHub OAuth and you see every hive you own or have access to. The dashboard shows: - **Live status** for each hive (green dot = online, governor mode indicator) - **Agent count** and ACMM level at a glance - **Quick actions** : open the hive dashboard, view the snapshot, manage permissions, upgrade, or delete - **Admin panel** (for hub administrators): manage user quotas, block/unblock accounts, view all users and their hives Local hives and hosted hives appear side by side. If you’re running a hive on your laptop and later provision a hosted version of the same project, the hub intelligently deduplicates the registry entries. ## **Hosted Hives: One-Click Deployment** This is where it gets interesting. If you don’t want to run Hive on your own infrastructure, the hub can provision a fully managed instance in a Kubernetes cluster: 1. **Click “Create Hive”** from the dashboard 2. **Provide your GitHub credentials** (personal access token or GitHub App) 3. **Choose your ACMM level** (start at 1, graduate upward) 4. **Wait ~60 seconds** while the system provisions a fully isolated environment with persistent storage, automatic TLS, health monitoring, and access control integrated back to the hub Your hosted hive gets a subdomain like `hosted-myorg-myrepo-x7y2.hive.hivecommons.dev` and is immediately accessible. It runs the same code as a local hive — same agents, same governor, same dashboard — but with zero infrastructure management. **Auto-upgrade** keeps hosted hives on the latest version. The hub polls the v2 branch for new commits, and owners can trigger a rolling restart with one click. ## **Access Control: Owners, Collaborators, and Requests** Every hosted hive has an owner — the person who created it. Owners can: - **Grant access** at three levels: read read-write owner - **Review access requests** from other users who want to collaborate - **Revoke access** (with a safety check that prevents removing the last owner) Access is enforced at the infrastructure layer before requests reach the hive. The hub validates every request and passes the authenticated user’s role to the hive, which enforces role-based restrictions. The access request workflow is simple: a user requests access, the owner sees the pending request in their dashboard, and approves or denies it. No email, no tickets — it’s built into the platform. ## **The Contribute System: Federated Human-AI Collaboration** Here’s the most ambitious piece. Hive doesn’t just orchestrate AI agents — it orchestrates human contributors too. ## **What Is a Contributor Agent?** A contributor agent is your AI coding CLI — Claude Code, GitHub Copilot, Goose, Gemini, or any compatible tool — connected to a hive instance and working on real issues. You’re not writing the code yourself. You’re lending your CLI’s compute and your GitHub identity to a project, and the hive assigns work that matches your trust level. Think of it as donating compute cycles to open source, except the compute is an AI agent running on your machine, and the project’s governor decides what it should work on. ## **How It Works** **1. Register.** Visit the contribute page for any hive and follow the setup instructions for your CLI. The system creates a contributor profile tied to your GitHub identity, issues a registration token, and assigns you the newcomer trust tier. **2. Connect.** Your CLI agent opens a persistent connection to the hive. On connection, it sends its registration token and the model it’s running (the hive can enforce model restrictions — for example, only allowing Claude or GPT-4o class models). The hive authenticates you, confirms your trust tier, and sends back your permissions. **3. Signal ready.** Your agent sends a `ready` message. The hive’s task selector evaluates what needs doing — open issues labeled for contribution, PRs needing review, bugs needing triage — and picks a task that matches your trust level and the project’s priority queue. **4. Receive a task.** The hive sends a task assignment: the issue or PR number, the repository, a title, and a structured prompt telling the agent what to do. Newcomers get comment-only tasks (triage, reproduce, clarify). Contributors get PR-worthy tasks (fix bugs, implement features). Trusted contributors get merge-eligible work. **5. Work.** Your CLI agent works the task — reading code, making changes, running tests, posting comments or opening PRs. During execution, it reports progress back to the hive so the live activity dashboard shows what’s happening in real time. **6. Complete.** When the agent finishes, it reports the result (success, failure, or partial). The hive records the completion, updates your task count, and marks the task as done with a cooldown period to prevent duplicate work. If the task failed, that’s recorded too — trust is built on honesty, not just output. **7. Repeat.** Your agent signals ready again, and the cycle continues. The hive picks the next highest-priority task, and your agent gets to work. ## **Trust Graduation** Every contributor starts as a newcomer. Trust is earned through completed tasks, not credentials: TierHow You Get ThereWhat You Can DoNewcomerRegisterComment on issues — triage, reproduce, clarifyContributorComplete 5+ tasksCreate pull requests — fix bugs, add featuresTrustedComplete 20+ tasks or maintainer voucherMerge PRs — full commit access with safety railsAdvisorInvited by maintainerReview agent-generated PRs — quality gate Promotion from newcomer to contributor happens automatically when you hit the task threshold. The system tracks completions per contributor across sessions — disconnect and reconnect, and your history is preserved. Maintainers can also manually promote or demote contributors, and revoke access entirely if needed. A revoked contributor’s CLI is disconnected immediately. ## **Your Credentials, Your Permissions** Here’s the detail that makes the whole model safe: contributors use their own GitHub credentials. Every GitHub action — commenting on an issue, opening a PR, merging a change — is executed with the contributor’s own identity and their existing permissions on that repository. The hive never grants access the contributor doesn’t already have. If a newcomer’s GitHub account only has comment permissions on a repo, that’s all the agent can do — even if a bug in the trust tier logic tried to assign merge-level work. GitHub’s own permission model is the final guardrail. The trust tier system controls what tasks the hive *assigns*, but GitHub controls what the contributor can actually *execute*. This means maintainers don’t need to grant any new repository permissions to enable contribution. The contributor’s existing GitHub access is the ceiling. ## **Why Projects Should Care** For maintainers, the contributor system is free distributed labor with built-in safety: - **Zero onboarding friction.** Contributors don’t need special repo access, environment setup, or context. The hive provides the task and the prompt. The contributor’s own CLI and GitHub credentials do the rest. - **Trust before power.** Nobody gets merge access on day one. The graduated permission model means new contributors prove themselves on low-risk tasks before touching production code. - **Model filtering.** Hive owners can restrict which AI models are allowed to contribute. If you only trust Opus-class models for your codebase, configure the allow list and the system rejects connections from anything else. - **Real-time visibility.** The contribute dashboard shows who’s connected, what they’re working on, and their completion history. You see the work happening live, not after the PR lands. - **Global leaderboard.** Contributors are ranked by completed tasks across all hives. Your best contributors are visible — and their track record follows them to other projects in the network. ## **The Bigger Picture** Single-project contributor programs are common. What makes this different is federation. A contributor registered on one hive can work on any hive in the hub network. The hub proxies connections to whichever spoke has actionable work. A developer running Claude Code on their laptop can triage issues for `org/repo-a` in the morning and fix bugs for `org/repo-b` in the afternoon — same CLI, same session, different projects. The leaderboard is global. Contributions to any hive count toward the same profile. This creates a portable reputation: a contributor who completes 50 tasks across five projects has a track record that any maintainer can evaluate. This is proof-of-work for open source. Contribute compute cycles and attention via your CLI agent, build trust through completed tasks, and graduate from commenting to merging. ## **ACMM: Progressive Autonomy in Six Levels** The Agent Capability Maturity Model (ACMM — [https://arxiv.org/abs/2604.09388](https://arxiv.org/abs/2604.09388)) is the governance framework that prevents a Level 1 project from accidentally auto-merging a breaking change. Each level unlocks more agents and more autonomy: Each level is a curated pack of agent configurations, governor thresholds, and mode constraints. You can apply a level with a single API call and the system reconfigures itself — pausing agents that shouldn’t run at lower levels, adjusting modes, and updating governor cadences. ## **The Proxy: Mode-Enforced GitHub Access** Every GitHub API call from every agent passes through an ACMM-aware proxy. The proxy enforces mode constraints in real time: - An agent in `ADVISORY` mode cannot create issues, PRs, or make any GitHub writes - An agent in `ISSUES_ONLY` mode can create issues but not PRs - An agent in `ISSUES_PRS_MERGE` mode has full access - Write operations are detected and blocked if the mode doesn’t allow them Violations are recorded per-agent and surfaced in the dashboard. This isn’t honor-system governance — it’s enforced before requests leave the system. ## **Security** Credentials are handled carefully: - **GitHub tokens** stored on the hub are encrypted at rest with authenticated encryption - **Session management** uses secure, scoped cookies with industry-standard protections - **Request validation** prevents cross-site attacks on all mutating endpoints - **Input sanitization** on all user-supplied data - **Hosted hive auth** is enforced at the infrastructure layer, not just the application - **Spoke authentication** verifies heartbeat traffic between spokes and hub ## **Getting Started** ## **Run a local hive (the spoke)** ``` # Clone and configure git clone https://github.com/hivecommons/hive cd hive/v2 cp .env.example .env # Add your GITHUB_TOKEN # Start docker compose up -d ``` ## **Connect to the hub** Add `hub_url: https://hive.hivecommons.dev` to your `hive.yaml` and your hive appears in the global registry within one minute. ## **Provision a hosted hive** Visit [hive.hivecommons.dev/dashboard](https://hive.hivecommons.dev/dashboard), log in with GitHub, and click “Create Hive.” ## **Contribute to any hive** Visit [hive.hivecommons.dev/contribute](https://hive.hivecommons.dev/contribute), set up your CLI, and start picking up tasks. ## **Why This Matters** Single-agent coding assistants are useful. But open source doesn’t need one assistant — it needs a system. A system that triages thousands of issues across dozens of repos, assigns work to the right agent or contributor, enforces governance at every level, and progressively trusts itself to do more. Hive Hub and Spoke is that system. The hub is live, the registry is growing, and the first hosted hives are running. If your project has more issues than bandwidth, point a hive at it and let the swarm go to work. *Hive is an open source project under [hivecommons/hive](https://github.com/hivecommons/hive) on GitHub. The hub is deployed at [hive.hivecommons.dev](https://hive.hivecommons.dev/). Contributions welcome — including via the contribute system itself.*