From Generic Kernel to Real Products: Capabilities, Extensions, and Hosts
LoopX's generic Kernel becomes useful across domains only if it refuses to own facts that belong elsewhere. The focus here is the boundary among Capability, Provider, Domain State, Extension, host, and projection, and how that boundary becomes a safe adoption path. The practical judgment is architectural: identify the caller outcome, the authority that owns each fact, and the evidence that must come back before a domain feature can change a Goal.
Domain facts enter through a narrow interface
A software issue, an experiment, and a research question do not produce the same evidence. An issue-fix workflow cares about the exact pull-request head, checks, review decisions, and merge state. An experiment cares about a matched baseline, data window, metric, guardrail, and external task identity. A research workflow may care about hypotheses, dev and holdout evidence, support or refutation, and promotion or retirement. A generic control plane should not hard-code all of those meanings into its own Todo or quota states.
LoopX separates four runtime responsibilities.
The Agent or Executor plans, analyzes, uses tools, and performs one bounded action through a host. The Agent can interpret a packet and choose among admitted work, but it does not become the durable owner of Goal state or acquire unscoped authority simply by reasoning about an action.
The Provider calls an external system or local implementation and returns a bounded observation, effect result, or readback. A repository provider can read a pull-request state. An experiment provider can return a task handle or terminal result. A notification provider can report whether a message was accepted. The Provider supplies facts and effects; it does not decide which Todo should be completed or whether a Goal has reached its terminal state.
The Capability is the stable outcome contract visible to a caller. It defines what result the caller can ask for, normalizes provider observations, applies domain policy, validates the result, and proposes a typed transition. “Qualify this exact final diff” or “classify this experiment result against its baseline” describes a Capability more usefully than “call a GitHub CLI” or “run a training script.” The transport can change while the outcome contract remains meaningful.
The Kernel accepts or rejects that proposal and owns the generic lifecycle: Goal, Todo, Gate, monitor, claim, quota, writeback, recovery, and scheduling. It does not need to know what CHANGES_REQUESTED means in every domain or how a particular evaluator calculates a metric. It needs to know whether the proposed transition is authorized, bound to the current work, supported by evidence, and safe to write back.
Domain State sits between domain interpretation and generic lifecycle. It preserves compact facts with stable identity, fingerprints, and lineage so a later turn does not have to reconstruct a PR stage or an experiment result from raw logs. It is not a second Goal state machine. It cannot grant a claim, launch authority, quota, merge permission, or production access.
An Extension is a delivery and lifecycle boundary for an optional provider. It can package, install, enable, disable, upgrade, and roll back an implementation. It may implement an existing Capability or provide a new caller-facing contract, but it does not become a fifth runtime responsibility. Installing an Extension does not give it authority over Goal state or allow it to bypass the Kernel's gates.