Governance vs. Execution
The kernel is a governance layer of inheritance and ownership — not a runtime topology that requests flow through.
Why This Section Exists
Readers coming from microservices, orchestration engines, service meshes, or middleware frameworks instinctively read architectural diagrams as runtime data flow diagrams. Arrows look like requests. A central component looks like a hub. A 'kernel' sounds like something the runtime depends on at execution time.
This instinct is wrong for KCC, and the spec needs to kill it before it propagates.
The kernel doesn't run the cells. It defines the contract they all honor.
This section makes the distinction concrete through two contrasting diagrams.
Diagram 1 — What KCC Is: The Governance Layer
The KCC architecture diagram describes inheritance, ownership, and influence relationships. It is not a runtime topology.
The arrows here mean:
- maintains: the maintainer group is responsible for the kernel.
- defines contract: the kernel specifies the agent contract that capabilities and cells honor.
- available for adoption: capabilities exist in the catalog; cells choose what to use.
- compose: cells assemble kernel + selected capabilities + their own custom agents.
None of these arrows represent runtime invocation. None of them mean 'a request flows through here.'
Diagram 2 — What Happens at Runtime
When an agent actually runs, this is what happens.
The Two Diagrams Together
The first diagram is specification topology: who owns what, who defines what, who inherits from whom. It changes on the kernel's slow cadence (yearly major, quarterly minor). The second diagram is runtime topology: how a single invocation flows from request to response. It happens millions of times per day in a large organization.
| Aspect | Specification Topology | Runtime Topology |
|---|---|---|
| When it operates | Design time, registration time | Every invocation |
| What flows | Contract definitions, version updates | Requests, tool calls, outputs |
| Frequency | Quarterly to yearly | Continuous |
| Owner | Kernel maintainers | Cell that owns the running agent |
| Failure mode | Inconsistent contracts | Failed invocations |
| Visible to | Kernel maintainers, capability authors | Agent users, ops engineers |
The kernel is in the first diagram. The kernel is not in the second.
What KCC Is Not
Not a Service Mesh
A service mesh (Istio, Linkerd) sits in the runtime path. Every service-to-service call traverses the mesh's sidecars. KCC is not this. The Token Guard and Butler are kernel-mandated meta-agents, but they run within each cell's runtime infrastructure — not as a central hub through which all invocations pass.
Not an Orchestrator
An orchestrator (Temporal, Step Functions, Airflow) coordinates multi-step workflows and owns the workflow state. KCC is not this. Cells own their own orchestration (or choose not to orchestrate). KCC governs the contract each agent honors, regardless of how the cell composes them into workflows.
Not Middleware
Middleware (API gateways, message brokers, RPC frameworks) sits in the request path between components. The kernel is documentation plus enforcement code that runs at agent registration time. The validators check that an agent's declaration is well-formed; after registration, the kernel does not participate in invocations.
The Practical Implication
- The kernel has no SLA for latency — it is not in the hot path and can take seconds to validate a new registration without affecting any running cell.
- Cells choose their own runtime infrastructure — Lambda, Kubernetes, on-premises VMs, edge devices. The kernel only validates that the declared contract is honored.
- Failure of the kernel does not stop cells — existing agents keep running; only new registrations are blocked. The kernel is on the critical path for change, not for execution.
- Cost visibility is eventual, not real-time — decision traces are written durably and read asynchronously by the Inspector Pipeline.
The Mental Model
The kernel is to cells what the constitution is to citizens. It defines what they may and may not do. It does not stand between every citizen and every action.
The constitution doesn't show up at the grocery store when someone buys milk. It defines the framework within which the transaction is legitimate. KCC works the same way: the kernel defines the framework within which agent invocations are legitimate. It does not participate in each invocation.
What This Means for Adoption
The common objection is 'we don't want another centralized service in our runtime path.' That objection is reasonable if KCC were a service mesh or orchestrator. It is not. What KCC actually adds at adoption time:
- Documentation and contracts (the kernel).
- A validation step at agent registration (one-time per agent version).
- A telemetry sink for decision traces (durable storage, written by cells).
- An asynchronous pattern-detection process (the Inspector Pipeline, not in the request path).
- A capability catalog (a library, not a runtime intermediary).
Nothing in this list sits between a cell and its agents at invocation time. The structural discipline is real. The runtime overhead is minimal. That's the point.