Synced from Hive. This page is pulled from hivecommons/hive@v5 during the docs build. Edit the canonical source in the Hive repository.
Hive landscape and positioning
Conducted: 2026-08-07. This document will rot. Agentic software-delivery tools are moving quickly; treat product details as time-sensitive and update this page by PR when public docs change.
Hive is an operations plane for AI-agent fleets: operator-controlled system runs multiple coding/review agents, applies deterministic policy before and after model judgment, and exposes live dashboard, cost, hub/spoke, and contributor-compute surfaces. This page positions that design against nearby agentic orchestration tools.
Agentic AI Foundation (AAIF) and Goose
The Linux Foundation’s Agentic AI Foundation hosts Goose, originally developed at Block. Goose is an execution backend; Hive is a downstream orchestration layer that dispatches to Goose at fleet scale, with operator-controlled policy and contributor-compute relays. This is an integration relationship, not AAIF membership, hosting, or endorsement of Hive.
The AAIF landscape submission instructions
ask for an alphabetical landscape.yml PR and an SVG logo, and generally
require 1,000 GitHub stars. Hive had 63 stars when checked for
#10627.
Listing eligibility request aaif/aaif-landscape#22
asks whether Hive qualifies below that threshold and which category fits;
it is a pending submission inquiry, not an accepted listing.
Review material: OpenSSF Best Practices badge, Apache-2.0 license, security self-assessment, and CNCF reference architecture.
The unattended Goose integration guide is maintained here for now. Goose’s contribution workflow requires a Ready issue on its board before any external docs PR, and asks humans to write new issues themselves. No open Hive issue was found there when checked for #10627, so no upstream PR has been opened. A human sponsor must file the documentation proposal and obtain Ready status before the page can be proposed upstream; the local guide is not upstream approval.
Fullsend
Public references: fullsend.sh, fullsend-ai/fullsend, Fullsend architecture, Fullsend roadmap, Fullsend runtimes, Fullsend intent representation.
Fullsend is a closely comparable open-source project. Its public README
positions it as autonomous agentic software development for Git-hosted
organizations, including GitHub, GitLab, and Forgejo. Its docs emphasize a
repo-visible coordination model: target repositories carry .fullsend/
configuration, GitHub installations use shim/reusable workflows and OIDC-minted
GitHub App tokens, and GitLab support is being built through native CI triggers
and polling. Its architecture names a vertical execution stack of dispatch,
infrastructure, sandbox, harness, and runtime; production runtime docs currently
list Claude Code as the production runtime and dummy for behavior tests, while
future runtimes are tracked separately.
Fullsend is also notably strong in public design discipline: many ADRs, a public roadmap, security and governance problem documents, and a thoughtful intent model. Its intent docs discuss git as an intent ledger and tiered authorization, which directly influenced Hive’s catch-up work in #2812.
Where Hive differs
| Dimension | Fullsend, fairly summarized | Hive, today or in-flight |
|---|---|---|
| Control plane | Repo-centered install and workflow dispatch, especially strong for GitHub Actions-native adoption. | A live fleet operations plane with governor modes, dashboard/SSE, terminal access, budget tracking, hub/spoke heartbeats, and contributor compute. |
| Execution model | Short-lived, workflow/sandbox-oriented agent runs; production docs currently center Claude Code. | Long-lived tmux-managed agents today, with multiple backends documented in config: Claude, Copilot, Gemini, Goose, and OpenAI-compatible gateways. |
| Autonomy model | Public docs discuss shadow/autonomous and intent-tier concepts. | ACMM L1-L6 maps operator-selected maturity to deterministic per-agent modes and merge authority. |
| Security enforcement | Sandbox, harness, scanner, and OIDC-mint controls are first-class in the docs. | Defense-in-depth combines CLI tool denial, scoped tokens, per-UID attribution, and a runtime-agnostic MITM proxy that enforces GitHub writes at the network boundary. |
| Fleet topology | Per-repo install is the public deployment model. | Hub/spoke registry, callbacks, leaderboard, SaaS/manual provisioning paths, and ClankeR contributor-compute relay are built into the product shape. |
Neither approach is inherently better for every team. Fullsend-style tooling is lighter when the target is repo or GitHub organization, GitHub Actions is already the trusted execution substrate, and the team wants minimal standing infrastructure. Hive is a better fit when operators need live fleet visibility, multiple runtimes, graduated autonomy, hub-managed spokes, contributor compute, or network-level enforcement independent of agent runtime hooks.
OpenAI Symphony
Reviewed against OpenAI Symphony at
be10a1b.
Public references: README,
Draft v1 SPEC.md.
Symphony is Apache-2.0 licensed and describes its Elixir reference implementation
as an engineering preview for trusted environments. Its demo monitors Linear,
runs isolated coding agents, and presents proof of work (CI status, review
feedback, complexity analysis, and walkthrough videos) before accepted PRs land.
Those demo artifacts and auto-landing are not mandatory spec requirements:
a successful spec run can stop at a human-review handoff.
Hive applies the Symphony operating model—manage work rather than supervise
every coding turn—to GitHub/GitLab-native projects, with deterministic policy
gating in front of the agent. This is a positioning analogy, not a claim
that Hive implements Symphony’s WORKFLOW.md or Codex app-server contracts.
| Dimension | Symphony | Hive |
|---|---|---|
| Work source | Linear in the demo; the current spec defines a provider-neutral tracker adapter. | GitHub/GitLab forge workflows; primary planning adapters include GitHub Issues/Projects, Linear, and Jira. |
| Pre-agent gating | Config preflight, active/terminal states, required labels, adapter dispatchability, claims, and concurrency checks (spec §§6–8). | Deterministic shell enumeration/classification/merge eligibility before a kick, plus ACMM and network-level write enforcement. |
| Agents | Codex app-server is the specified runner protocol. | Multiple CLI backends, including Claude, Copilot, Gemini, Goose, and Codex; confinement depends on backend and deployment. |
| Scale model | Per-issue persistent workspace, bounded concurrent runs, reconciliation, continuation, and retry. | Queue-depth-driven cadence, long-lived agents, isolated execution paths, hub/spoke, and convergence audits. |
| Packaging | Language-neutral draft specification and experimental Elixir reference implementation. | Go runtime and supporting scripts, Compose/Quadlet deployment, dashboard, and contributor relay. |
Choose Symphony when a repo-owned WORKFLOW.md, the Codex app-server contract,
and per-ticket workspace lifecycle are the desired integration surface. Choose
Hive when fleet operations, multiple runtimes, forge-native review/merge policy,
and graduated autonomy are central. Neither tool’s workspace isolation alone
constitutes a sandbox.
See the section-by-section alignment review for gaps and intentional divergences, the existing Linear work source, and work-source provider contract.
Single-agent and service-oriented tools
GitHub Copilot coding agent
GitHub Copilot’s coding agent is a hosted, GitHub-native way to assign issues or PR follow-ups to an agent. It is the lowest-friction option for teams already in GitHub that want a single background agent without operating their own control plane. Hive differs by coordinating a fleet of specialized agents, enforcing ACMM-derived permissions, aggregating fleet cost/status, and supporting non-Copilot runtimes.
Devin-class hosted services
Hosted software-engineering agents such as Devin-class services optimize for outsourcing a task to a capable autonomous worker with a managed environment and product UX. They can be a better fit when a team wants a vendor-operated agent and does not want to run orchestration infrastructure. Hive is more appropriate when the organization needs open-source control, explicit policy, self-hosted operation, or integration with Kubernetes/hub/spoke workflows.
SWE-agent and research harnesses
SWE-agent-style projects are excellent for benchmarking, experiments, and single-task repair loops where the research question is the agent’s ability to solve an issue. Hive is not primarily a benchmark harness; it is an operating system for repeated project maintenance, policy-bound merge decisions, and multi-agent fleet operation.
When to choose what
- Choose GitHub Copilot coding agent when you need the quickest hosted path for GitHub issues and do not need a separate fleet governor or custom policy plane.
- Choose Symphony when you want a spec-first, repo-owned
WORKFLOW.mdand Codex app-server orchestration with per-ticket persistent workspaces. - Choose Fullsend-style tooling when you have a small number of repos, want
GitHub Actions or native CI to be the execution substrate, prefer repo-visible
.fullsend/configuration, and want little or no always-on infrastructure. - Choose Devin-class services when managed autonomy and vendor UX matter more than self-hosted controls or open implementation details.
- Choose SWE-agent/research harnesses when the goal is evaluation, reproducible experiments, or-off issue repair rather than operations.
- Choose Hive when the problem is operating a live AI-agent fleet: multiple runtimes, ACMM maturity gates, deterministic merge policy, hub/spoke provisioning, contributor compute, cost visibility, and network-level MITM enforcement.
Hive claims checked against this repo
- Live fleet operations plane: architecture, dashboard and observability.
- Multi-runtime model: architecture, agent configuration.
- ACMM autonomy: architecture, ACMM matrix.
- Hub/spoke and contributor compute: architecture, manual provisioning.
- MITM enforcement: architecture, ADR-0002.