[Sandbox] Hive Commons #516

Project summary

Hive Commons is a Kubernetes-native, governed orchestration platform for fleets of AI coding agents that autonomously maintain software repositories - maximizing engineering productivity by operationalizing state-of-the-art AI-native systems research into production tooling.

Project description

Hive Commons exists to maximize engineering productivity by operationalizing state-of-the-art AI-native systems research into production tooling; its flagship, Hive, is the family's orchestration system and UI/delivery surface. Hive orchestrates fleets of AI coding agents that maintain software projects: triaging issues, writing fixes, opening pull requests, reviewing changes, and - only at the highest operator-selected autonomy level - merging on green CI.

Teams are already pointing AI coding agents at their repositories, but ad hoc: no consistent policy for what an agent may touch, no audit trail of what it did, and guardrails that live in prompts rather than code. Hive adds the missing control layer. A deterministic pipeline - filtering, classification, merge-gating, and enforcement implemented as inspectable code - runs before any LLM sees the work; agents handle only the judgment calls. Operator trust is graduated through ACMM, the AI codebase maturity model scoping which actions (comment, PR, merge) an agent may take, with matching least-privilege GitHub App token scopes. Every action lands in an append-only audit ledger, and a technically enforced egress proxy constrains what agents can reach. Hive ships as a single Go binary - a standard Kubernetes workload (Deployment/Service/PVC, no CRDs), Docker Compose stack, or Podman Quadlet units - and an optional hub coordinates many self-hosted "spoke" hives.

At its core, Hive follows a "determinism before judgment" philosophy: everything decidable by inspectable code is, and a named human is accountable for every agent identity. Hive maintains its own repository - the commit history is the product demonstrating itself.

As a vendor-neutral, Apache-2.0 project born as a subproject of KubeStellar (CNCF Sandbox), Hive is neutral across agent backends (Claude Code, GitHub Copilot, Gemini, Goose, and OpenAI-compatible self-hosted gateways such as vLLM/llm-d/LiteLLM) and forges (GitHub/GitHub Enterprise; GitLab/Gitea in progress), treating AI-agent labor as a first-class, governable cloud native workload.

Project vs Reference Architecture/Implementation

• This is a reusable open source project designed for broad adoption, not a reference architecture, reference implementation, or demonstration of patterns

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/hivecommons/

Project repo URL in scope of application

https://github.com/hivecommons/hive (transfer from kubestellar/hive COMPLETE as of 2026-09-03 - all prior kubestellar/hive URLs redirect automatically)

Additional repos in scope of the application

All repos under hivecommons listed here for clarity.

https://github.com/hivecommons/hive (transfer from kubestellar/hive complete - parent consensus issue linked in Additional information)
https://github.com/hivecommons/infra
https://github.com/hivecommons/.github
https://github.com/hivecommons/pluk
https://github.com/hivecommons/promptargs
https://github.com/hivecommons/rationguard
https://github.com/hivecommons/hotshot
https://github.com/hivecommons/hivecommons.github.io
https://github.com/hivecommons/docs
https://github.com/hivecommons/hive-redirect

Hive is the flagship orchestration system and the family's UI/delivery surface. pluk, promptargs, rationguard, and hotshot are the first members of the supporting tool family Hive delivers to adopters; infra and .github hold deployment automation and org-level community health defaults; hivecommons.github.io, docs (docs.hivecommons.dev), and hive-redirect serve the project website, documentation site, and redirects.

Website URL

https://hivecommons.dev

Roadmap

https://github.com/hivecommons/.github/blob/main/ROADMAP.md

Roadmap context

The project maintains two lines. v4 is the default branch and supported stable line: bug fixes, security fixes, and dependency updates only, plus continued hardening from the project's internal security-audit remediation backlog. v5 is the next-generation line under active development, with three headline items: (1) a dedicated reviewer lane - agents that review rather than author changes, producing strictly advisory output that never satisfies a human-approval requirement; (2) formal verification of protocol invariants - Promela/Spin models of the hub↔spoke protocol checked in CI, with protocol changes required to update the corresponding model in the same PR; and (3) channel-based release trains (edge/candidate/stable) with digest-pinned artifacts replacing moving tags, so deployed versions are verifiable. A documented migration path from v4 (including dual-version operation) is part of the v5 scope. Direction-setting follows GOVERNANCE.md: roadmap items appear after discussion in public issues, and breaking changes require the supermajority process.

Directionally, Hive is also evolving as the UI and delivery surface for the wider Hive Commons tool family (pluk, promptargs, rationguard, hotshot today, more over time): the project's dashboard and workflows are the vehicle that puts those supporting tools in adopters' hands. Those tools are in scope of this application as members of the hivecommons org, and the family grows through the same public-issue, governance-driven process as the Hive roadmap itself.

Contributing guide

https://github.com/hivecommons/.github/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/hivecommons/.github/blob/main/CODE_OF_CONDUCT.md

Adopters

https://github.com/hivecommons/.github/blob/main/ADOPTERS.md

Maintainers file

https://github.com/hivecommons/.github/blob/main/MAINTAINERS.md

Security policy file

https://github.com/hivecommons/.github/blob/main/SECURITY.md

Standard or specification?

N/A. Hive includes an internal hub↔spoke coordination protocol (with formal Promela/Spin models planned as CI-checked artifacts in v5), but this is an implementation detail of the project, not a standard or specification intended for independent implementation.

Business product or service to project separation

Being candid: the maintainers operate a hosted multi-tenant hub - an operational deployment of this same open-source code that runs the project's own agent fleet and hosts spokes for early adopters during the incubation of the project's community. This is an operational service run by the maintainers, not a commercial product of any company: it is not sold, and no maintainer's employer (IBM, Universal Blue) offers Hive as a product or service.

The separation posture is: the open-source repository is complete and self-hostable. There are no gated, withheld, or enterprise-only features - the Kubernetes manifests, Docker Compose stack, and Podman Quadlet path in the repo deploy the identical system the maintainers run, and self-hosted deployments keep all data on the operator's own infrastructure (the GTR documents this: no hosted plane is required or holds adopter data for self-hosted installs). The hosted hub's branding is kept separable from the project's, and project assets (GitHub org, DNS, registries, trademarks, signing keys) are held for the project and transfer per CNCF policy on acceptance, as stated in GOVERNANCE.md's vendor-neutrality section. If the hosted hub ever evolves toward a commercial offering, it would be a downstream consumer of the project under a distinct name, governed by the same neutrality rules.

Why CNCF?

Hive Commons' founding thesis is maximizing engineering productivity by operationalizing state-of-the-art AI-native systems research into production tooling - deterministic guardrail pipelines, graduated-autonomy maturity models, technically enforced egress control, formally modeled coordination protocols. As agent automation becomes strategic to every engineering organization, that thesis only stays credible in a vendor-neutral home: no single vendor should own the layer that governs what AI agents may do to a codebase.

Hive was incubated inside KubeStellar, a CNCF Sandbox project - KubeStellar's GOVERNANCE-HIVE.md formally declares Hive its subproject, and Hive's governance, contributor ladder, DCO practice, Prow-based CI, and CNCF Code of Conduct adoption were all built to CNCF norms from the start. Applying to Sandbox as a separate project (with the parent's public consensus, linked below) is the natural continuation of that lineage rather than a new direction.

Beyond lineage, the category needs a neutral home. AI-agent automation for software maintenance is currently dominated by single-vendor, closed offerings tied to one model provider or one forge. Hive is deliberately neutral across agent backends and model providers, and its maintainers span three unrelated affiliations; CNCF stewardship (trademark and asset neutrality, open governance oversight) is the credible way to keep it that way as the space heats up. Concretely, we want from CNCF: a vendor-neutral trademark home (the project renamed to "Hive Commons" specifically to clear this path), TAG Security engagement - we have unusually substantive security material for a project this age (technically enforced egress control, credential-scoping, an internal audit and key-rotation program) and want expert scrutiny of it, since governed agent autonomy is exactly where neutral security review matters most - and access to the community of cloud native maintainers who are both the tool's operators and its most demanding critics.

Benefit to the landscape

The landscape has strong answers for automating infrastructure (GitOps, operators) and pipelines (CI/CD), but no project addressing the newest labor pool in cloud native engineering: AI coding agents. Organizations are adopting them anyway - ungoverned, unaudited, and vendor-locked. Hive contributes the missing control plane: a way to run agent fleets against repositories with deterministic guardrails enforced in code rather than prompts, a graduated autonomy model (ACMM) that lets an organization dial trust up one capability at a time with matching least-privilege token scopes, and an append-only audit ledger of every agent action.

The differentiators over existing capabilities in and around the landscape: (1) governed fleet orchestration - not a single agent on a single repo, but hub/spoke coordination of many agents across many repositories with queue-depth-governed cadences; (2) determinism before judgment - filtering, classification, and merge-gating happen in inspectable pipeline code before any LLM is invoked; (3) auditability and human accountability - every agent identity is registered to a responsible human in MAINTAINERS.md, agent-authored PRs are labeled, and humans hold all approval authority; (4) neutrality - pluggable agent CLIs and OpenAI-compatible self-hosted inference gateways, so the same governance applies whether the models are SaaS or in-cluster vLLM/llm-d. It also gives the landscape a working, public case study: Hive maintains its own repository, so its claims are inspectable in its own commit history.

Finally, Hive brings a distribution model along with the tool: as the flagship and UI of the Hive Commons community, it is the on-ramp through which the family's supporting developer tools (pluk, promptargs, rationguard, hotshot - all in scope of this application) reach adopters quickly, giving the landscape not just a project but a channel for AI-native systems research tooling to land in production hands.

Cloud native 'fit'

Hive is built and operated as a standard cloud native workload:

• Kubernetes-native deployment: shipped manifests (Namespace, Deployment, Service, PVC, ConfigMap, Secret, backup CronJob) plus a Kustomize base; startup/liveness/readiness probes wired to real health endpoints (/api/livez deliberately checks the eval loop, not just process-up); least-privilege, namespace-scoped RBAC; documented resource requests/limits. It introduces no CRDs, webhooks, or aggregated API servers - it is a well-behaved workload, not an API-server extension.
• OCI artifacts: multi-arch (amd64/arm64) container images published to ghcr.io/hivecommons (dual-published with ghcr.io/kubestellar during the transition), moving to digest-pinned channel releases in v5.
• Declarative, layered configuration with inspectable provenance (GET /api/config/provenance reports which layer won per field).
• Observability: opt-in Prometheus /metrics endpoint; health endpoints backing all three deployment runtimes.
• Standard cloud native operational posture: TLS terminated at ingress (cert-manager + ingress-nginx documented as the Kubernetes prerequisites), secrets via Kubernetes Secrets, state on a single PVC (no external database), documented backup/restore via a CronJob to object storage.
• Portability: the same binary runs under Kubernetes, Docker Compose, and Podman Quadlet/systemd (rootful and rootless), with honest documentation of what each runtime can and cannot enforce.

And its purpose is cloud native: its primary users are platform and project teams maintaining the kind of repositories the landscape is made of - Hive's own parent, KubeStellar, is its first production consumer.

Cloud native 'integration'

• Kubernetes (CNCF Graduated) - primary production deployment target; hub-side spoke provisioning drives namespaces/PVCs/Deployments via the Kubernetes API; probes, RBAC, and Kustomize base as above.
• Prometheus (CNCF Graduated) - opt-in /metrics scrape endpoint for fleet observability.
• cert-manager (CNCF Graduated) and ingress-nginx - documented prerequisites for TLS termination and routing in the Kubernetes deployment path.
• Helm/Kustomize - Kustomize deployment base ships in-repo.
• Prow (Kubernetes SIG tooling) - the project runs its own contribution workflow on Prow (OWNERS-based review, lazy consensus, Tide merges), and Hive's merge-gating is designed to compose with Prow-managed repositories.
• KubeStellar (CNCF Sandbox) - parent project and first production adopter (the KubeStellar Console fleet); Hive was built to maintain KubeStellar-family repositories.
• Ecosystem beyond CNCF: GitHub/GitHub Enterprise (GitLab and Gitea via the in-progress forge abstraction); agent backends Claude Code, GitHub Copilot CLI, Gemini, Goose; self-hosted inference gateways vLLM, llm-d, LiteLLM through an in-pod credential-translating proxy - relevant to CNCF's growing AI-workload story, since it lets organizations keep model inference in-cluster.

Cloud native overlap

We are not aware of a CNCF project that does what Hive does - orchestrating fleets of AI coding agents against source repositories - so there is no direct overlap. Stating the nearest neighbors honestly:

• CI/CD projects (Argo, Tekton, Flux, Keptn): these execute defined pipelines and reconcile declared state; Hive dispatches open-ended judgment work (triage, authoring, review) to agents and governs it. Hive composes with CI rather than replacing it - green CI is an input to its merge gates.
• Kubeflow and CNCF AI/ML efforts: concern training/serving ML workloads on Kubernetes; Hive is a consumer of model inference (and can use in-cluster gateways), not an ML platform.
• OpenFeature/OPA-style policy projects: Hive's ACMM guardrails are policy-like in spirit but domain-specific (agent capability tiers mapped to forge token scopes); an integration with a general policy engine is plausible future work, not an overlap today.

If the TOC considers another applicant or project adjacent in the agentic-automation space, we would welcome the comparison - the space is young and we would rather over-disclose than claim uniqueness.

Similar projects

No CNCF project is similar; outside CNCF, honestly:

• Single-agent coding assistants/agents - GitHub Copilot coding agent, OpenHands (formerly OpenDevin), SWE-agent, Aider, and commercial offerings like Devin. These run one agent on one task; most are tied to one vendor's models or one forge.
• Narrow automation bots - Dependabot, Renovate, Mend: excellent at one deterministic class of change (dependency updates); not general maintenance, not agentic.
• Agentic CI/review bots - CodeRabbit, Sweep, and similar PR-review or issue-to-PR SaaS tools: closed, hosted, per-repo, prompt-governed.

Hive's differentiator against all three classes is governed fleet orchestration: many agents, many repositories, hub/spoke coordination, a deterministic pipeline that gates work before any LLM sees it, a graduated autonomy maturity model (ACMM) tied to least-privilege credentials, an append-only audit ledger, and governance that makes a named human accountable for every agent identity. It is also self-hostable and model/forge-neutral, where most of the above are single-vendor SaaS.

Landscape

Not yet listed. We attempted the entry alongside this application, but the landscape's bar for non-CNCF projects is 300+ GitHub stars, which the project does not yet meet - so we will be listed upon Sandbox acceptance (CNCF projects are added regardless of stars) or upon reaching that bar, whichever comes first.

Insights

Not yet listed on LFX Insights; we will submit the project alongside this application.

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?

N/A - the project is licensed Apache-2.0 (with NOTICE file), and dependencies conform to the CNCF allowlist policy.

Project "Domain Technical Review"

We have completed the full General Technical Review questionnaire as a self-service document, answering all 73 questions with file/line citations against the repository, including a plainly stated known-gaps section: https://github.com/hivecommons/hive/blob/v4/src/docs/general-technical-review.md

We have not yet presented to a TAG; we intend to request a presentation slot with TAG App Delivery (or the TAG the TOC recommends) as part of this application's review, and would particularly welcome TAG Security engagement given the project's domain.

Application contact email(s)

andy@clubanderson.com

Contributing or sponsoring entity signatory information

If an organization:

Correction (2026-09-15): this section previously listed Andy Anderson as an individual signatory in error. Per IBM's Open Source Participation Guidelines, the contribution is made by IBM as the contributing entity (consistent with the KubeStellar precedent); Andy Anderson (IBM) remains the project's Chief Maintainer and application contact. Project assets (org, domain, registries, trademark) are held for the project per GOVERNANCE.md's vendor-neutrality section and transfer per CNCF policy on acceptance.

CNCF contacts

The KubeStellar (CNCF Sandbox) maintainer community is familiar with the project - Hive was developed as KubeStellar's subproject and maintains KubeStellar-family repositories in production. We do not currently have a TOC or TAG member engaged with the project; we would welcome an assigned TAG contact.

Additional information

Subproject separation (required evidence). Hive originated inside the KubeStellar org (kubestellar/hive) as a formally declared subproject - see https://github.com/kubestellar/kubestellar/blob/main/GOVERNANCE-HIVE.md. The public consensus issue in the parent project's repository documenting KubeStellar maintainer approval of Hive's separation into its own org and this Sandbox application: kubestellar/kubestellar#3986. The repository was transferred to github.com/hivecommons/hive with full history on 2026-09-03 (created 2026-04-17 in the KubeStellar org; GitHub redirects preserve all prior URLs). Hive now lives in its own vendor-neutral org and is no longer hosted under the KubeStellar org; container images are dual-published to ghcr.io/hivecommons and ghcr.io/kubestellar during the transition window.

Security posture. OpenSSF Best Practices passing badge at 100% (https://www.bestpractices.dev/projects/14261). Beyond the badge, the project has an unusual amount of verifiable security practice for its age: a sustained internal security-audit program with public remediation branches, a master-key rotation program, a technically enforced egress policy proxy (CAP_NET_ADMIN-gated, with honest documentation of when enforcement degrades to advisory), and Ed25519-only hub↔spoke channel authentication. We intend to publish a TAG Security-style Security Self-Assessment and request a joint review.

Honest framing of contribution statistics - please read before looking at the commit graph. Hive maintains its own repository: a large share of commits are authored by the project's AI agents (the hive-bot GitHub App and agent identities), operated under the accountability rules in GOVERNANCE.md and CONTRIBUTING.md (registered responsible humans, labeled PRs, human-only approvals, human DCO sign-off). This is the product demonstrating itself and we present it as such - not as evidence of contributor breadth. Counted separately: roughly 13 distinct human committers in the last 6 months, 4 with sustained activity across 4 distinct organizations (IBM, Universal Blue, on-board.ai, independent). Growing sustained human contributors and independent adopters is our top community priority, and the community infrastructure below exists to serve it.

Community. Mailing lists: hivecommons-dev, hivecommons-users, hivecommons-security-announce (groups.google.com). Public biweekly community meeting, Thursdays 10:00 AM ET starting 2026-09-10, with a public calendar, running agenda/notes, and recordings posted to YouTube - entry points at https://hivecommons.dev/join, /agenda, /calendar, /meet, /tv, and https://www.youtube.com/@hivecommons.

Governance is sized honestly for a small project - GOVERNANCE.md states how each rule applies at today's 3-maintainer scale and how it scales, includes an explicit AI-agent accountability policy (we believe among the first of its kind in an open source governance document), and mandates that maintainer records in MAINTAINERS.md and the root OWNERS file stay in agreement (the clause synchronizing with the upstream KubeStellar table applied while the project lived in the KubeStellar org and is retired now that Hive is in its own org).

Timing disclosure - stated plainly rather than discovered. (1) The primary repository was created 2026-04-17 in the parent org and reaches the 6-month mark on 2026-10-17; we are filing early because we understand the queue is FIFO and review will not begin before that date regardless - if policy requires it, we will gladly refile on 2026-10-17 with identical content. (2) Update, within minutes of filing: parent-maintainer consensus is now COMPLETE - all three maintainers recorded +1s and kubestellar/kubestellar#3986 is closed as completed. (3) Update 2026-09-03: the transfer is COMPLETE - the project now lives at https://github.com/hivecommons/hive in its own org, no longer under kubestellar, with history, issues, PRs, releases, and branch protection intact; all prior kubestellar/hive URLs in this application redirect automatically.