Read this page when you need the current canonical answer for who owns AI behavior in Holon, where structured output is already required, and what minimum proof is expected before claims about AI-facing contract surfaces should be trusted.
This page describes the high-level system shape and authority boundaries.
The holon CLI binary is implemented by the holon-cli crate and exercises the full Holon runtime protocol surface. It shares the same holon-runtime-core::Runtime contract as the desktop application.
Status: Implemented. The .NET sidecar (Holon.DesktopHost) has been removed and replaced by the in-process holon-runtime-core runtime.
Holon is an expert automation product focused on turning human intent into reliable outcomes.
Holon uses the word "lane" in several distinct ways. In canonical docs, every occurrence must carry a qualifier. Unqualified "lane" is ambiguous and must not appear in docs/system/.
This page defines the canonical orchestration flow.
Read this page when you need the accepted architecture boundary for Holon's future plugin marketplace without treating the marketplace as broad current implemented behavior.
Holon plugin packages are the intended packaging abstraction for capability sources. The long-term direction is one Holon-governed install and import surface that can wrap portable skills, capabilities, docs, assets, and adapter hints without forcing users to start from MCP, CLI, or other implementation-lane details.
rust-code-tool is Holon's current compiled-code frozen-tool implementation kind. It lets a workspace persist a governed Rust CLI tool as managed source, build it under runtime control, validate it with tests and fixtures, and project it into the runtime tool catalog only after artifact readiness is proven.
This page describes the system as layered runtime responsibilities.
Holon separates tool enumeration, capability discovery, and guarded execution into distinct runtime surfaces.
This page defines the canonical workflow model for Holon.