Case packet
Neutral case identifier: case-6c50ade3801134
The possible directed relationship from Artifact A to Artifact B is under review.
Artifact A
Agent runtimes decompose into scheduler context engine and execution substrate
Practitioner accounts often use one umbrella term for everything around the model: harness, runtime, agent system. That is useful rhetorically but too coarse for architecture. The parts grouped under that umbrella do different jobs, fail in different ways, and connect to different theoretical claims in this KB. The cleaner decomposition is:
- Scheduler — owns control flow, decomposition, and state progression across bounded calls. Answers: what happens next?
- Context engine — decides what enters each bounded call and in what frame. Answers: what does this call get to see?
- Execution substrate — provides the persistent and executable world outside the model: files, tools, sandboxes, versioned artifacts. Answers: where do exact state and actions live?
Not every system exposes these as neat modules; in many real systems the boundaries blur. The claim is that the functions are analytically distinct, and the distinction clarifies why practitioner taxonomies keep converging on similar component lists.
Why the split matters
Once separated this way, several recurring confusions disappear. A filesystem is not a scheduler. Tool calling is not context engineering. AGENTS.md is not the execution substrate itself; it is a runtime artifact consumed by the context engine. Grouping all of these under one undifferentiated term hides the actual design tradeoffs.
Each component also maps to existing KB theory:
- The scheduler is formalized by the [bounded-context orchestration model]: symbolic bookkeeping outside the model, bounded calls for judgment.
- The context engine is formalized by [context engineering]: routing, loading, scoping, and maintenance of bounded context.
- The execution substrate is grounded by [inspectable artifact, not supervision, defeats the blackbox problem] and [files beat a database for agent-operated knowledge bases].
Mapping the practitioner taxonomy
The [Anatomy of an Agent Harness ingest] derives six practitioner components from model limitations: filesystem, bash, sandboxes, memory/search, context management, and long-horizon execution. Those map cleanly into the three-part decomposition:
| Practitioner component | Runtime component | Why |
|---|---|---|
| Long-horizon execution / Ralph Loop | Scheduler | Controls iteration boundaries, retries, branching, and progression across calls |
| Context management | Context engine | Compacts, scopes, and injects what each call sees |
| Memory/search | Context engine + execution substrate | Retrieval logic is context engineering; the stored artifacts live on the substrate |
| Filesystem | Execution substrate | Durable exact state outside the model |
| Bash / tool execution | Execution substrate | Deterministic actions outside the model |
| Sandbox / isolated environment | Execution substrate | Constrains execution and protects the outside world |
The source's "everything not the model" definition is descriptively useful but architecturally unstable — it names a perimeter, not a decomposition. The three-part split turns the perimeter into components with distinct responsibilities.
Raschka's six components
[Raschka (2026)] independently decomposes coding agent harnesses into six named components. These map onto the same three-part split:
| Raschka component | Runtime component | Why |
|---|---|---|
| Live Repo Context | Context engine | Frontloaded workspace state injected before the first turn |
| Prompt Shape and Cache Reuse | Context engine | Stable prefix / variable suffix architecture for context loading |
| Context Bloat Minimization | Context engine | Compaction and transcript reduction as context maintenance |
| Structured Session Memory | Context engine + execution substrate | Working memory selection is context engineering; the stored transcript lives on the substrate |
| Tool Access | Execution substrate | Deterministic actions and state queries outside the model |
| Bounded Subagents | Scheduler + context engine | Delegation is scheduling; read-only scoped inheritance is context scoping |
Raschka reaches these components by asking what makes agent-mode tools outperform the same model in plain chat. His answer — "a lot of apparent 'model quality' is really context quality" — is independent convergent evidence for the same decomposition from a pedagogical rather than architectural starting point.
Scheduler
The [bounded-context orchestration model] is already the formal treatment: symbolic bookkeeping outside the model, bounded calls for judgment. What this decomposition adds is positioning that model as one component of a larger runtime architecture, alongside the context engine and substrate it depends on.
This framing also clarifies why [unified calling conventions enable bidirectional refactoring] focuses on an imperative scheduler layer. That note is not about "the whole runtime" — it is about making the control-flow-owning component cheap to refactor as capabilities move between neural and symbolic implementations.
Context engine
[Context engineering] already decomposes this component into routing, loading, scoping, and maintenance. [Agent statelessness means the context engine should inject context automatically] specializes one mechanism: reference-triggered loading.
The separation matters because many things attributed vaguely to "memory" are actually context-engine decisions. Retrieval, injection, frame construction, progressive disclosure, and compaction all concern bounded visibility, not durable storage. Durable storage is the substrate's job.
Execution substrate
The execution substrate gives the system an inspectable world outside the model:
- Persistent state — files, indexes, versioned artifacts
- Tool execution surfaces — shell commands, deterministic helpers
- Safety boundaries — sandboxes, permission layers
Both the scheduler and context engine depend on exact external state. The scheduler needs somewhere to keep bookkeeping state. The context engine needs somewhere to retrieve from. Without an external substrate, both collapse back into flat conversation state.
Two existing notes ground this component from different angles:
- [Inspectable artifact, not supervision, defeats the blackbox problem] — repo artifacts are governable in a way weights are not: they can be diffed, tested, reviewed, and reverted.
- [Files beat a database for agent-operated knowledge bases] — files defer schema commitment while giving versioning, browsing, and agent access immediately.
Practitioner component lists place filesystems, bash, sandboxes, and versioned memory artifacts here. These are not mainly "reasoning aids." They are the environment in which reasoning becomes durable and actionable.
Why independent sources converge here
Four independent practitioner sources each emphasize different parts of the runtime, but the convergence is clearer under this decomposition:
- [Lopopolo's report] emphasizes how constraints harden across the runtime — instructions, structural tests, cleanup agents. That improvement path runs through all three components but is most visible in the scheduler and substrate becoming more reliable over time.
- [The cybernetics thread] frames the space as sensors, actuators, and feedback loops. That language cuts across all three components but especially clarifies the scheduler/substrate interface: the scheduler reads state from the substrate and writes decisions back to it.
- Vtrivedy10's component taxonomy provides the anatomy — the concrete pieces a runtime needs once you work backward from model limitations.
- [Raschka's six components] reach the same decomposition from a pedagogical angle — asking what makes agent-mode tools outperform plain chat, and finding that the answer is context quality, not model quality.
The KB already had the theory for the scheduler and context engine. What was missing was the runtime-level note connecting those theories as components of one architecture, and showing that remaining practitioner components cluster under execution substrate rather than floating as unrelated infrastructure.
Scope limits
This is a decomposition, not a claim that these three components are the only ones that matter. Evaluation infrastructure, policy layers, and social workflows may deserve their own treatment. The point is narrower: the practitioner "harness" perimeter becomes much more usable once split into scheduler, context engine, and execution substrate.
It is also not a claim that every implementation must enforce hard module boundaries. A small system may collapse all three into one codebase. The analytical split still clarifies which theoretical arguments apply to which part.
Relevant Notes:
Artifact B
Inspectable artifact, not supervision, defeats the blackbox problem
The claim from ML
Chollet [observes] that sufficiently advanced agentic coding is essentially machine learning: an optimization process (coding agents) iterates against a goal (spec + tests) until convergence, producing a blackbox artifact (the generated codebase) that is "deployed without ever inspecting its internal logic, just as we ignore individual weights in a neural network."
He predicts classic ML failure modes will follow: overfitting to the spec, Clever Hans shortcuts that don't generalize, data leakage, concept drift. And asks: what will be the Keras of agentic coding — the optimal high-level abstractions for steering this process?
Where the framing breaks
The blackbox analogy holds only if the output is practically opaque. Neural network weights are [distributed-parametric] (encoded across numerical parameters) and opaque to any ordinary inspector — human or LLM. But readable artifacts (prompts, schemas, evals, deterministic code) are inherently inspectable at useful scales. They can be diffed, tested, reverted, and reviewed — by humans or by LLMs. The artifact's representational form is what matters, not who reviews it.
An LLM can review a diff and catch a Clever Hans shortcut in generated code. It can run evals and detect overfitting to the test suite. It can compare a codified function against its specification and flag edge cases. None of this is possible with weight updates — not because LLMs lack judgment, but because weights lack structure.
The failure mode mapping
Chollet's predicted ML problems map directly to [codification] failure modes — but with mitigations that weight-based systems can't match:
| ML failure mode | Codification equivalent | Mitigation available |
|---|---|---|
| Overfitting to spec | Goodharting on evals | Broader eval sets, LLM-as-judge on unseen cases |
| Clever Hans shortcuts | Bad assumptions codified confidently | Diff review (human or LLM), property-based tests |
| Concept drift | Model drift breaking codified prompts | Regression evals, CI gates |
| Data leakage | Test/train contamination in eval suites | Held-out eval sets, adversarial test generation |
Every mitigation relies on the same property: the artifact is inspectable. You can write a test for a function. You can't write a test for a weight.
The real question
Chollet asks "what will be the Keras of agentic coding?" — the abstraction layer that lets humans steer codebase "training" with minimal cognitive overhead. The [verifiability gradient] is a candidate answer: it tells you which grade of codification to use for each piece of your system, based on how verifiable you need it to be. The constrain/relax cycle is the steering mechanism — codify when patterns emerge, relax when new requirements appear. And crucially, neither the gradient nor the cycle requires a human in the loop. They require an inspectable artifact.
Relevant Notes:
- [the verifiability gradient] — determines when and how to codify
- [agent runtimes decompose into scheduler context engine and execution substrate] — component view: names inspectable repo artifacts and tools as the execution substrate layer of the runtime
Under-review context phrase
why repo artifacts and exact state belong to a separate substrate component