Should this work exist?
The agent observes assigned intent, compares it with local reality, and decides whether correction is needed.
Investigation 016 · Node Execution Principles
The agent owns execution.
Must it know every mechanism?
The local execution agent can launch one known program. Then reality asks for artifacts, filesystems, isolation, resources, security, monitoring, cleanup, and mechanisms that do not yet exist.
Begin the investigation ↓Execution AgentONE RESPONSIBILITY · MANY MECHANICS
Observe assigned intentPrepare environmentLaunch executionMonitor and clean up
Prologue
“Start the workload” hides almost everything.
The agent receives an assignment and decides that execution should exist locally. In the smallest world, it launches one executable already present on the machine.
FIRST REQUEST
Launch one known process.
NEXT REQUEST
Retrieve an artifact and prepare its filesystem.
THEN
Configure isolation, resources, security, monitoring, and cleanup.
LATER
Support a different execution technology with different mechanics.
Each request is reasonable. Together they ask whether the execution agent is still coordinating execution or becoming the execution platform itself.
The mystery
Should the component responsible for execution also know how every execution mechanism works?
First Principles
Do not abstract before reality demands it.
A second component adds communication, compatibility, failure, and operational cost. The simplest correct design should stay combined while execution truly means one stable operation.
How is execution produced?
The answer may begin as one process launch. We have not yet earned a separate owner.
Architecture should separate responsibilities only after their reasons to change diverge.
Naive Architecture
Let the execution agent learn everything.
The agent already owns the outcome, so every new execution requirement enters the same component.
Growing Execution Agentorchestration + every mechanism
Running Workone component produces all details
Observe desired stateRetrieve artifactsPrepare filesystemConfigure isolationConfigure resourcesConfigure securityLaunchMonitorClean up
No addition is frivolous. The design grows through reasonable local decisions.
The Architecture That Almost Worked
Functionally complete. Architecturally coupled.
The enlarged agent starts every current workload correctly. Nothing is broken in the demonstration. The warning is in its reasons to change.
Ensure assigned work runs
This obligation changes slowly and remains owned by the machine-local agent.
Every mechanism enters the agent
Artifact formats, isolation, resource models, security, and future execution technologies evolve independently.
A working architecture can still be resisting its own future.
Breaking Our Design
Four experiments expose one missing boundary.
Each episode removes one assumption. The interface does not appear until the final experiment earns it.
EPISODE 01
The Operating System Problem
Pressure. Preparing modern execution teaches the agent increasing machine-specific detail while its original responsibility remains unchanged.
Prediction. If execution is mostly process launch, adding realistic preparation should leave the agent's shape nearly unchanged.
Experiment
Add each required preparation step.
Observation
Launch becomes one small step among many mechanics.
Failure
The agent becomes tied to changing machine internals.
Discovery
Responsibility and OS mechanics are separable concerns.
Next pressure
What if mechanisms multiply?
How much of execution is process launch?
Total agent duties1
Mechanism duties0
Original responsibilityunchanged
Begin with one executable already on the machine.
EPISODE 02
The Portability Problem
Pressure. Each new execution technology enters the orchestration owner as another implementation branch.
Prediction. If the agent genuinely owns these mechanics, supporting additional implementations should be ordinary feature growth.
Experiment
Add independently implemented execution technologies.
Observation
Agent branches and release obligations grow together.
Failure
All execution innovation must modify orchestration.
Discovery
The agent needs capability, not every implementation.
Next pressure
What remains stable over time?
Add execution technologies directly to the agent.
if technology == A:
execute_with_A()
Implementations1
Agent branches1
Agent revisions1
One technology and one direct branch appear manageable.
EPISODE 03
The Evolution Problem
Pressure. Runtime technology changes over years while the agent's responsibility remains “ensure assigned work runs.”
Prediction. If responsibility and mechanism belong together, every mechanism generation should legitimately require a new agent release.
Experiment
Advance through mechanism generations.
Observation
The responsibility never changes.
Failure
Local innovation repeatedly becomes a system-wide agent release.
Discovery
A stable dependency must isolate changing mechanics.
Next pressure
What does the agent actually need?
Change the mechanism. Hold the responsibility constant.
ResponsibilityEnsure assigned work runs
Mechanism generationKnown process model
Agent revision1
Year 1: one known mechanism is embedded in agent revision 1.
EPISODE 04
The Interface Discovery
Pressure. Three failures point to the same root: the agent depends directly on how execution works.
Prediction. If a real boundary exists, responsibilities should separate without naming a particular technology.
Experiment
Classify each responsibility by owner.
Observation
Decisions and mechanics form two coherent groups.
Failure removed
The agent no longer changes for each implementation.
Discovery
A stable capability contract can connect the owners.
Boundary earned
The runtime owns how.
Who should own the next responsibility?
Observe assigned desired state0 of 7 classified
Execution agentnone yet
Stable capability boundarynot earned
Execution mechanicsnone yet
Classify the responsibility by the evidence and change it owns.
Compact Review
The Turning Point
Depend on capability.
Delegate mechanism.
The execution agent decides that assigned work should exist. A separate runtime owns how the machine produces that execution.
The Runtime Delegation Contract
Two owners. One stable boundary.
The execution agent owns desired execution. The runtime owns execution mechanics.
| Responsibility | Execution agent | Runtime |
|---|---|---|
| Observe desired state | Owns | Does not own |
| Decide whether work should run or restart | Owns | Does not own |
| Retrieve artifacts | Does not own | Owns |
| Prepare execution environment | Does not own | Owns |
| Configure machine mechanisms | Does not own | Owns |
| Launch, restart, and stop work | Requests | Executes |
| Monitor execution health | Consumes evidence | Owns mechanism-level observation |
| Report status and execution failures | Consumes and reconciles | Reports through the contract |
| Reconcile until intent matches | Owns | Does not own |
Request execution
Express that a workload should be created without prescribing implementation details.
Request removal
Express that execution should cease while the runtime owns the mechanics.
Request restoration
Express that failed execution should be recreated without transferring reconciliation ownership.
Return bounded evidence
Report execution state and failures to the agent without becoming the owner of desired state.
Only Now: Kubernetes
Kubernetes names the boundary CRI.
The Kubelet remains the execution agent. The Container Runtime Interface is the stable capability boundary. containerd and CRI-O are independently evolving runtime implementations behind it.
These names realize the contract. They did not produce the need for it.
The Kubelet decides that execution should happen. The runtime knows how to execute it.
Engineering Reflection
Stable components should depend on capabilities, not changing implementations.
A boundary earns its cost when one side's responsibility remains stable while the other side's mechanisms evolve independently.
Intellectual Lineage
Separated per-machine coordination from lower-level execution machinery.
Stable capabilities repeatedly allowed implementations beneath them to evolve.
CRI applies the same boundary to node execution.
Architectural Honesty
One stable mechanism
A small, single-purpose system may be clearer with direct execution when one team owns both sides and change is rare.
Independent evolution
A runtime boundary becomes worthwhile when mechanisms multiply, ownership diverges, and orchestration must stay stable.
Costs Accepted
Component
Another long-lived process must be operated.
Communication
Requests and results cross a boundary.
Compatibility
The shared contract must evolve deliberately.
Diagnosis
Failures can span agent, boundary, runtime, and machine.
Investigation Exercise
Replace the mechanism without rewriting intent.
Write an agent that launches one known program.
Add artifact, filesystem, isolation, resource, and monitoring requirements.
Change the execution mechanism and record which orchestration code changes.
Keep create, stop, restart, status, and failure-reporting semantics in the shared boundary.
Run the trace after predicting which owner changes.
One Undefined Word Remains
Create this workload.
What exactly belongs together?
The runtime contract accepts one opaque execution request. We have not established whether an application is one execution unit or several cooperating units with shared identity and fate.
We separated how work runs. We have not defined what one workload contains.
Deliberate Simplifications Ledger
“Workload” treated as one opaque execution requestINV-017
Networking preparation named without mechanismINV-018
Isolation and resource limits named, not derivedINV-019
Artifact acquisition and caching assumedOpen backlog
Persistent storage assumed availableINV-025–027
Sources
- Kubernetes — Container Runtime Interface
- Kubernetes — Container Runtimes
- Kubernetes source — CRI API
- containerd source
- CRI-O source
- KEP-2040 — Kubelet CRI support
- Original CRI design documentation
- Verma et al., “Large-scale cluster management at Google with Borg,” EuroSys 2015.
- Burns, Beda, and Hightower, Kubernetes: Up & Running, 3rd edition.