How a run uses Hive

After this page you'll know exactly when a run reads from Hive, what a bee can write back, and why run #2 on a project doesn't start from zero. For what Hive is, start with What Hive is.

Before the bee starts: three gate reads

The router calls Hive up to three times before any bee is dispatched, and each call is fatal on failure:

hive_resolve_source     which Space does this channel / repo / ticket belong to?
hive_check_membership   is the requester a member of that Space?
hive_resolve_policy     which model provider, or NO_AI?

The membership check only applies to triggers carrying an SSO-asserted requester; system triggers (scheduled ticks, platform events) skip it and are gated by a bee allow-list at dispatch instead. Unbound channel, non-member requester, or a NO_AI policy each reject the run before it exists. If Hive itself is unreachable here, the run fails with a router-failed:hive-unreachable outcome rather than guessing.

At planning time: the context bundle

Once dispatched, the bee's planning phase fetches a project bundle before it writes a plan:

1. hive_list_sources: the Space's repos, each tagged with a role (BACKEND, WEB, IOS, ...). The distinct roles become the doc types for the next step, and the same roles drive which repo the bee decides to work on.
2. hive_get_page: the OVERVIEW page (space-wide), then ARCHITECTURE and DEV_WORKFLOW once per doc type, since technical pages are kept per platform.
3. hive_list_decisions: the ten most recent entries from the Space's decision log.

The bundle is injected into the planning prompt as trusted context: unlike a ticket body or repo README, it comes from the team's own Space, not from the trigger author. If Hive is unreachable at this point the run pauses with needs-input instead of planning blind. If only part of the bundle failed, the run continues but emits a visible degraded-context event so you can tell a degraded plan from a healthy one on the dashboard.

During the run: targeted lookups

The bee keeps a live connection to the Hive MCP server for the whole run, so it can reach past the seed bundle when the work warrants it: hive_search for hybrid retrieval across the Space's ingested context, hive_get_page for a specific page a ticket links to. The use-hive-context skill tells it when that's worth doing (anything touching architecture or a decision that might already exist) and when it isn't (a typo fix doesn't need three Hive round-trips).

After the run: proposing learnings back

The write path is deliberately narrow. Most runs write nothing. When a run produces durable signal (a decision was made, a workflow shifted, a recurring approach emerged), the write-back contract is:

hive_append({ space, page, heading, markdown })      add a new section to a page
hive_propose_pattern({ space, decisionId, rationale })  propose a reusable pattern

Both are append-only and best-effort: a bee never edits human-authored content, and a failed write never fails the run. Acceptance is a human act: an appended section or proposed pattern lands as new content in the Space for the team to keep, rewrite, or delete, which is what Keeping Hive healthy is about.

One honest caveat: as of July 2026 the live Hive server does not implement hive_append or hive_propose_pattern, so these calls soft-fail and the write leg of the loop closes through humans editing the Space directly.

Worked example: the second run is smarter

Say run #1 on school-comms is "add rate limiting to the API". The bee reads OVERVIEW plus ARCHITECTURE.BACKEND, picks the backend repo from its source role, does the work, and the resulting decision (which library, which limits, why) gets recorded in the Space's decision log.

Two weeks later, run #2 is "rate-limit the webhook endpoint too". Its planning bundle already contains that decision via hive_list_decisions, so the bee extends the existing approach instead of re-deciding, or worse, contradicting it. Nothing about run #2's trigger mentioned run #1; the continuity came entirely from the Space. That's the loop: reads compound every run, and each durable learning makes the next plan cheaper and more consistent.