Model layer
The model layer produces reasoning or structured decisions. Keeping it replaceable avoids making one model provider the architecture.
Control layer
A control layer coordinates bounded work, applies product policy and determines when more evidence or human input is needed.
Execution layer
The execution layer exposes approved machine capabilities behind explicit permission and audit boundaries.
Follow one task through the layers
Suppose a user asks an assistant to compare two local files and save a summary. The model proposes a comparison. The controller selects permitted read tools, checks the requested scope and tracks what must be verified. The node or execution adapter reads only the approved files and writes the output through an authorized capability. A separate read-back checks the saved summary before the controller calls the job complete.
If the local model runs out of memory, that is a model-runtime problem; it should not grant broader file access. If the node cannot open a path, that is an execution or permission problem; swapping the language model does not fix it. Diagnose the layer that failed before retrying.
Why separation helps
Our small-model decision guide shows why the controller must preserve limits. The ten-model operating-profile study illustrates that model-facing instructions may change while the execution boundary stays fixed.
A model can change without redefining file access. A new computer capability can be introduced without giving it authority over the whole workflow. Verification policy can evolve without rebuilding every tool.