Three-Layer Architecture
Kernel, Capabilities, and Cells divide the platform into invariant rules, reusable functions, and autonomous delivery units.
Three Layers, Three Owners, Three Cadences
KCC is a three-layer architecture. Each layer has a distinct owner, change cadence, quality bar, decision rights, and acceptable failure mode. The separation is deliberate; collapsing any two layers into one breaks the model. This is the structural consequence of the core thesis: one kernel, many capabilities, many cells.
Three layers. Three owners. Three change cadences.
2.1 The Kernel
The shared contract every agent in the organization implements. The kernel comprises the agent contract surfaces, the cost envelope schema and enforcement rules, the gating rules and meta-agent specifications, the decision trace format, the capability maturity criteria, the phase model definitions, and the governance policies for kernel evolution itself. The kernel is specification, not implementation - documentation plus enforcement code (validators, schema checkers, gating engines).
It is owned by a tight maintainer group of 3-7 engineers, named and publicly documented. Kernel maintainers have veto authority over kernel changes and sponsorship authority for L2-to-L3 capability promotions. The change cadence is slow because the cost of getting it wrong is high; slow kernel evolution is the price of stability.
| Change Type | Cadence |
|---|---|
| Patch (clarifications, doc improvements) | Monthly |
| Minor (new optional surfaces or fields) | Quarterly |
| Major (breaking changes) | Yearly at most |
Acceptable failure modes: the kernel may be incomplete (some surfaces marked 'specification pending'), it may lag behind state-of-the-art agent capabilities by design, but it must not be inconsistent - better to specify nothing than to specify two contradictory things - and it must not be captured by any single team or domain.
2.2 Capabilities
Versioned, reusable agents that conform to the kernel contract and are packaged for adoption across multiple cells. Each capability includes the agent itself (code, prompts, configurations), its declared agent contract (all 9 surfaces), its skills, its hooks, and its evaluation suite. Examples (illustrative, not prescriptive): spec-writer, code-reviewer, test-author, runbook-author, release-notes-generator, incident-triager. Each capability has a named maintainer (an individual) and a maintaining team; a capability without a named maintainer cannot be promoted to L2.
| Version Type | When | Backward Compatibility |
|---|---|---|
| Patch (2.1.0 -> 2.1.1) | Bug fixes, behavioral refinements | Preserved |
| Minor (2.1.0 -> 2.2.0) | Additions, new optional fields | Preserved within minor |
| Major (2.1.0 -> 3.0.0) | Breaking changes | Cells must update |
Capability families and dialect variants (reference pattern, non-normative): one logical capability often has materially different protocols depending on the stack. The middle path is a capability family - one logical capability that declares one or more variant axes (language, framework, deployment target) and dispatches to the matching variant document, a dialect, at invocation time. Dialects are catalog- or cell-level material, never kernel material - they encode conventions, not contracts.
2.3 Cells
Team-owned compositions of the kernel plus selected capabilities plus custom agents specific to the team's domain. A cell is the unit of value delivery - where work actually ships. It has a team (typically 5-15 engineers), a domain, a kernel version, a selected capability set, a custom agent set, and a cell composition document. Cells are not microservices; the cell is an organizational unit, not a deployment unit. Change cadence is fast - cells change weekly or faster.
What is not acceptable is a cell that silently violates the kernel contract. Violation must be either requested as a kernel evolution (an ADR proposal to the kernel maintainers) or explicitly declared as a cell-local exception with a documented sunset date. Silent violation is the failure mode the kernel is designed to prevent; detected silent violations are surfaced as Inspector Pipeline signals.
2.4 Why This Structure
Three layers with three owners and three cadences is the answer to a specific problem: ungoverned agentic adoption produces fragmented practices, invisible costs, untraceable decisions, and trapped knowledge. KCC's structure inverts each failure.
| Failure Mode | KCC's Inversion |
|---|---|
| Fragmented practices | Curated capability catalog - not reinvented per team |
| Invisible costs | Explicit cost envelopes - enforced by the Token Guard |
| Untraceable decisions | Structured decision traces - recorded per invocation |
| Trapped knowledge | Inspector Pipeline - flows from cells back to capabilities back to kernel |
2.5 What This Structure Is Not
KCC is not a hub-and-spoke topology in the runtime sense - the kernel does not sit in the middle of agent invocations at runtime. It is not a centralized governance model in the political sense - cells own their work. It is not a Conway's Law mapping - the team structure does not need to mirror the layer structure. And it is not a maturity model - the kernel/capabilities/cells structure is the target architecture, while maturity and the phase model measure progress toward it. See What KCC Is Not for the full scope boundaries.