• conforms_to::[[Conviction Form Contract]]
• in_practice_domain::[[eOS Continuum]]
• authored_by::[[Christopher Allen]]
• has_lifecycle::[[Seed Stage]]↗
• has_curation::[[Working Draft]]↗

Agent Harnesses Drive the Runtime, Not the Reverse

On the eOS runtime platform, the agent harness uses the runtime as a tool the harness drives -- the harness sends operations to the runtime, the runtime returns state and events, and the architectural relationship is the same one the harness has to LLMs and other callable services. The conventional inversion (the agent runs inside the runtime; the runtime hosts or orchestrates the harness's work; harness logic is co-located with runtime code) relocates the platform's primitives behind a layer the harness cannot directly call and surrenders the substitution-fungibility that makes LLMs, runtime, and other tools interchangeable in the harness's tool surface.

Why It Is Held

The conventional agent-platform pattern treats LLMs as tools the harness orchestrates -- file read, web search, code execution, LLM call. LLMs are one tool among many, called via API; the harness is the orchestrator that sequences calls, manages state across calls, and recovers from failures. State, atomicity, identity, and event coordination are the harness's responsibility, assembled from external infrastructure: a database for state, a queue for atomicity, identity middleware for permission boundaries, distributed locks or eventual consistency for coordination, webhook plumbing for notifications. The runtime, in this pattern, is implicit -- it is whatever language and process the harness happens to be written in. The harness's architecture is shaped by the runtime's absence rather than by its presence.

The inversion treats the runtime as one tool among many in the harness's tool surface. The harness sends operations to the runtime in the same way it sends prompts to an LLM. The runtime returns state and events in the same way an LLM returns generated text. What the harness gets from this inversion is not coincidental; it is the runtime-primitive set the runtime carries that LLMs structurally cannot. State persists across calls because the runtime holds it; mutations are atomic because the runtime's atomic envelope contains them; multi-agent coordination is coherent because the runtime serializes; identity boundaries are enforced because the runtime carries capability separation; notifications are asynchronous because the runtime fires events; observability is direct because the runtime exposes its own state. The harness gets the property set the conventional pattern rebuilds badly from external infrastructure, as a single coherent tool's natural output.

This Conviction is held because the inversion is what makes the runtime-primitive set usable by the harness. Without the inversion -- if harness logic is embedded inside the runtime as runtime code, or if the runtime is treated as the harness's framework rather than as its tool -- the platform's primitives become hidden infrastructure rather than directly-callable services. The harness loses the substitution-fungibility that lets LLM-as-tool and runtime-as-tool sit at the same architectural level: it can swap one LLM for another behind the same harness, but not swap the runtime for another platform without rewriting the harness. The inversion preserves the harness's authority over which tools to drive while letting the runtime's primitives count as one of them.

The fit between the runtime's primitive set and the agent harness's structural needs is not coincidence. Both narrative-MUD platforms and agent frameworks are coherent persistent-state systems with multiple authors operating concurrently. The architectural problem is the same; the solution applies. The runtime lineage that handled multi-author concurrent narrative simulation decades ago has the shape that contemporary agent frameworks are reaching toward by rebuilding it badly outside the runtime. The inversion is what lets the harness consume that shape directly.

What It Asks

Honoring this Conviction asks the project to defend the harness-runtime boundary as a load-bearing architectural distinction.

• The harness-runtime communication channel is a callable interface, not an embedded one. The harness drives the runtime through whatever channel lets it send operations and read back state and events. The harness is not code running inside the runtime; the harness is a separate process (or a separate logical layer) that calls the runtime as a service. Workstream scoping for the harness side -- LLM orchestration, prompt management, tool selection, agent-loop scheduling -- routes outside the runtime. Workstream scoping for the runtime side -- state, atomicity, capability separation, events, hot reload, code load, multi-agent coherence, state introspection -- routes inside.
• Architectural Decisions that propose embedding harness logic inside the runtime must surface the cost. A Decision that locates the agent loop in the runtime's own language, fuses prompt-management code into runtime objects, or co-locates LLM-call orchestration with runtime state management does not fail this Conviction by existing -- it fails by hiding the cost. The cost is: the harness loses substitution-fungibility (it can no longer swap runtimes without rewriting harness logic); harness lifecycle couples to runtime restart (a runtime crash takes down the harness); harness logic becomes subject to the runtime's compile-and-load cycle (changing prompts requires a recompile rather than a harness-process restart). The default disposition is to keep the harness outside; trading it requires the cost to be named and accepted.
• Workstream scoping uses the harness-runtime boundary as a filter condition. When a workstream proposes a capability, the scoping question is which side of the boundary the capability lives on. Capabilities that orchestrate calls (to LLMs, to the runtime, to external services) belong on the harness side; the harness drives. Capabilities that hold state, enforce boundaries, or fire events belong on the runtime side; the runtime provides. Workstreams that propose runtime-side orchestration (a runtime-implemented agent loop, runtime-managed prompt templates, runtime-side tool registries) or harness-side state-holding (harness-process database, harness-side capability enforcement, harness-side event coordination) need rescoping to align the capability with the side that should hold it.
• Communication preserves the runtime-as-tool framing. When the platform's architecture is communicated to potential adopters, the harness-as-driver framing is the load-bearing detail. Documentation that describes the platform as "a runtime that hosts agents", "an agent platform with built-in storage", or "a framework agents run inside" has lost the inversion. The held framing is more specific: the harness drives the runtime as a tool; the runtime is a service the harness uses; LLMs and the runtime sit at the same level in the harness's tool surface, distinguished by cadence and primitive set rather than by architectural rank.
• Cross-tool substitution-fungibility is preserved. The harness can call different LLMs through the same orchestration interface; the harness can call the runtime through a similar interface. Both are tools the harness selects and drives. Architectural Decisions that erode substitution-fungibility (locking the harness to a specific runtime through embedded runtime code; coupling the harness to runtime-process lifecycle; making the harness depend on runtime-internal types it could not get from a different platform) cost the inversion's structural advantage and need to surface that cost explicitly.

Drift Recognition

The Conviction has weakened when the project's outputs treat the runtime as the harness's environment rather than as one of its tools.

• Workstreams that propose embedding harness logic in the runtime without scoping evaluation. A workstream that proposes implementing the agent loop in the runtime's own language, co-locating prompt orchestration with runtime objects, or exposing harness-side tool registries as runtime objects without naming what the inversion was already buying has stopped holding the Conviction in practice. The proposals are not forbidden; the cost surfacing is required.
• Communication that frames the platform as a host for agents. Documentation, onboarding, or comparative-positioning material that describes the platform as "a runtime that runs agents" or "an agent framework with built-in state" has shifted the held position. The held position is that the platform is one the harness drives, not a host the agent lives inside. The naming distinction is load-bearing -- the inversion's structural advantage depends on the harness's directing role being explicit.
• Architectural Decisions that fuse harness lifecycle to runtime lifecycle. A Decision that requires the runtime to be running before the harness can start, that ties harness-process restart to runtime restart, or that makes harness logic dependent on runtime-internal state shapes erodes the substitution-fungibility the inversion preserves. The harness should be able to swap runtimes (LLM, this platform, future alternative platforms) without rewriting; lifecycle fusion breaks that.
• "Agent framework" framings replacing "runtime tool" framings. A framing that positions the platform alongside agent frameworks (LangChain, AutoGen, CrewAI) at the orchestration layer rather than alongside runtime platforms (DGD, BEAM, custom VMs) at the platform layer mislocates the project. The Conviction asserts that the platform the harness drives, not an orchestration framework the harness extends. Comparative positioning that conflates the two has shifted the held stance.
• BACKLOG accretion of runtime-side orchestration tasks. When workstream backlogs grow to include building prompt management inside the runtime, implementing tool selection in the runtime, or scheduling agent loops on the runtime side without questioning whether the capability belongs in the harness, the scoping check has stopped firing. The pattern across many sessions of locating orchestration capabilities in the runtime erodes the inversion cumulatively.
• Cumulative cross-session drift. No single session breaks this Conviction; the pattern across sessions does. If several consecutive rounds of work quietly assume the harness lives inside the runtime -- backlog tasks for runtime-side orchestration, decisions co-locating harness and runtime concerns, communication describing the platform as a host -- the project has drifted from holding the Conviction even though no individual change was the breaking point.

Relations

• conforms_to::[[Conviction Form Contract]]

  • Exercises the Contract's Stance plus Why It Is Held plus What It Asks plus Drift Recognition body shape. The filename uses declarative SVO comma-form held-stance shape ("X drives Y, not Z").

• grounded_in::[[Agent Runtimes Require Native Primitives, Not External Glue]]

  • The harness-runtime inversion is structurally advantageous only because the runtime carries the eight runtime primitives as native properties. Without the runtime-primitive set, the inversion is just a stylistic preference about where the agent loop runs; with the primitive set, the inversion is what lets the harness consume platform-level guarantees as one tool's natural output. Currently a ghost link; the diagnostic Conviction has not yet migrated.

• contrasts_with::[[eOS-Harness Is the Wrong Runtime Platform Without Platform-Pain]]

  • The pair sits at adjacent positions in scope-of-applicability framing. This Conviction names how the harness uses the platform -- the inversion that makes the platform's primitives directly callable. The anti-pitch Conviction names workloads where the platform's primitives offer no value because the workload does not benefit from the inversion's structural advantage. Together they bound the platform-fit space. Currently a ghost link; the anti-pitch Conviction has not yet migrated.