OpenHive Wiki

Documentation for the OpenHive AI agent orchestration platform. Version 4.6.3.

Core Architecture Invariant

Main → Orchestrator → Subagents → Skills → Plugins.

• Main agent routes user requests and delegates to child teams. No subagents, no skills, no direct execution.
• Team orchestrator manages subagents. Never invokes skills directly (ADR-40).
• Subagents follow skills and own learning/reflection cycles. Each brings a different perspective (ADR-40).
• Skills orchestrate plugins via ## Required Tools. Pure orchestration — no raw API calls (ADR-39).
• Plugins are executable TypeScript tools for single external operations.

Version

4.6.3. Do not reference v3 or prior versions in page content. Version references inside ADR historical text (Context/Decision sections) are preserved as-is.

Canonical Ownership Rule

Every concept has exactly one canonical page. Other pages use 1-2 line cross-references with [PageName#Section](/Z-M-Huang/openhive/wiki/PageName#Section) syntax. Never duplicate explanatory content.

Canonical Ownership Map

Concept	Canonical Page
Skill adoption flow (12-step)	Skill-Repository
Skill format, plugin/skill roles	Skills
Subagent format, wiring, hierarchy	Subagents
Memory schema, search, injection	Memory-System
Isolation mechanisms	Isolation-Model
Rule cascade, format	Rules-Architecture
Three-tier data model, code inventory	Architecture
Execution model (daily-ops / org-ops pool + mutex)	Architecture#Execution Model
Learning cycle, reflection, governance	Self-Evolution
Trigger engine, overlap, circuit breaker	Triggers
window trigger type (continuous watch)	Triggers#window Trigger Type
config.yaml, vault, data store tree	Team-Configuration
Session lifecycle, tool assembly	SDK-Integration
Message flow, trust gate	Request-Processing
Topic classification	Conversation-Threading
Dashboard views	Admin-Dashboard
Browser sessions, SSRF	Browser-Proxy
Organization tools, task queue	Organization-Tools
query_teams parallel fan-out	Organization-Tools#query_teams — Parallel Fan-out
enqueue_parent_task work handoff	Organization-Tools#enqueue_parent_task — Work Handoff
Tool selection decision framework	Tool-Guidelines
Activation Decision Framework (when→which trigger)	Tool-Guidelines#Activation Decision Framework
End-to-end walkthroughs	Scenarios
Design principles	Design-Principles
ADR decisions & rationale	Architecture-Decisions
Log levels, credential scrubbing	Logging
Durable state, recovery	Durability-Recovery
Channel adapters, WebSocket protocol	Channel-Adapters

ADR Conventions

• Fully superseded ADRs are deleted entirely (4.6.3 clean start).
• Partially superseded ADRs use a **Superseded:** line after Status.
• When deleting an ADR, update the intro text and any back-references in replacement ADRs.

Formatting

The wiki serves both humans and LLMs. LLMs read these pages at session bootstrap via the rule cascade, so structure-first formatting (tables, diagrams, explicit flows) is a hard requirement — not a stylistic preference.

• Mermaid diagrams are required for every execution model, state machine, and flow (sequence, flowchart, stateDiagram). Narrative prose is acceptable for non-flow explanations (concepts, rationale, definitions).
• No ASCII art for architectural diagrams. ASCII analogies are permitted inside prose when they clarify a concept an LLM will read (e.g., the guard-on-duty analogy in Tool-Guidelines#Why window ticks feel long-running).
• Wiki links: [PageName](/Z-M-Huang/openhive/wiki/PageName) or [PageName#Section](/Z-M-Huang/openhive/wiki/PageName#Section). Prefer section-anchored links when cross-referencing a specific canonical diagram or table.
• Tables: GitHub-flavored markdown pipe syntax.
• No code snippets from actual codebase — reference source file names.
• Every diagram has exactly one canonical home page; other pages cross-reference it rather than re-embedding. Canonical homes are listed in the Canonical Ownership Map above.