Runtime Support Layer Fundamentals

• Runtime support layer is an execution-time software layer that bridges high-level application intent with low-level system mechanisms to ensure portability and stability.
• It abstracts heterogeneous resources, maintains execution state, schedules access, manages data movement, and enforces policies dynamically.
• Architectural patterns include separating control and execution planes, gateway or proxy boundaries, and plugin-based realizations to enable runtime observability and intervention.

A runtime support layer is an execution-time software layer that mediates between application- or runtime-level intent and lower-level system mechanisms such as devices, memory spaces, schedulers, communication substrates, package managers, or execution gateways. In the supplied literature, it is variously located “between distributed heterogeneous systems and runtime systems” (Martin et al., 1 Sep 2025), “above the model and below the application” (Cruz, 28 Feb 2026), or between an HPC resource manager and a scarce QPU (Wennersteen et al., 24 Sep 2025). Despite domain differences, the recurrent function is to expose a stable execution abstraction while observing, constraining, adapting, or extending behavior during execution rather than only at build time or after the fact. This suggests that “runtime support layer” names a family of execution-time control, mediation, and portability mechanisms rather than a single implementation pattern.

1. Definition and position in the software stack

The clearest explicit definition appears in HiCR, which “coin[s] the phrase Runtime Support Layer” for a software level “naturally located between distributed heterogeneous systems and runtime systems” (Martin et al., 1 Sep 2025). In that formulation, the layer exposes an implementation-agnostic API for hardware topology discovery, kernel execution, memory management, communication, and instance management, while leaving device-specific realization to plugins. The same boundary-setting recurs in “AI Runtime Infrastructure,” which defines a distinct execution-time layer that operates “above the model and below the application,” and requires three properties: it operates during execution, performs active intervention, and reasons over long-horizon context (Cruz, 28 Feb 2026).

Several papers sharpen this placement by contrast. The HPC-QC work states that its contribution is not a new quantum algorithm or a vertically integrated stack, but a practical runtime/middleware architecture that fills the missing layer between an HPC center’s batch system and an attached QPU (Wennersteen et al., 24 Sep 2025). The ROOT modularization paper similarly places its contribution above ROOT’s historical source directories, libraries, and CMake targets, arguing that “build-time components” alone do not provide enough separation of concerns for package discovery, dependency resolution, or post-install activation during a live session (Shadura et al., 2018). In serving systems, MorphServe is described as “a runtime support mechanism” that adds an adaptive control plane and a state-preserving execution substrate on top of a modern serving engine, rather than a static compression method (Su et al., 24 May 2025).

A recurrent misconception is that a runtime support layer is merely a thin adapter. The papers repeatedly reject that narrowing. The HPC-QC system is “not just an adapter to submit circuits to hardware” (Wennersteen et al., 24 Sep 2025). HiCR is “not” a programming model and “not” a thin wrapper around MPI, OpenCL, CUDA, or cloud APIs (Martin et al., 1 Sep 2025). “AI Runtime Infrastructure” is explicitly separated from passive logging, inference optimization, orchestration, and application logic (Cruz, 28 Feb 2026). This suggests that the defining property is execution-time control over already-running computations, resources, or workflows.

2. Core responsibilities

Across the supplied works, the runtime support layer repeatedly assumes six technical responsibilities: resource abstraction, state tracking, scheduling or admission, data or package movement, intervention or policy enforcement, and observability.

First, it abstracts heterogeneous resources. HiCR does this through abstract managers for topology, memory, communication, compute, and instances (Martin et al., 1 Sep 2025). The heterogeneous distributed PREMA extension does so with hetero_object and hetero_task, device abstraction via a Device API, and runtime-managed dependency detection, coherence tracking, scheduling, and inter-node communication (Thomadakis et al., 2023). RIMMS does so with a hete abstraction carrying host pointers, resource pointers, and a last-resource flag, thereby decoupling application logic from low-level memory placement and transfer rules (Gener et al., 28 Jul 2025).

Second, it maintains execution-relevant state. In AI Runtime Infrastructure, the runtime layer must maintain “continuous visibility into agent state, intermediate outputs, and environmental interactions across multiple steps” (Cruz, 28 Feb 2026). In MorphServe, the controller continuously observes GPU memory utilization, request queue depth, throughput, TTFT, TPOT, and KV-cache pressure, then adapts layer precision and KV capacity online (Su et al., 24 May 2025). In the trauma-resuscitation recommender, the runtime layer fuses static patient context, dynamic patient context, recent process history, cumulative process history, and timestamp to emit next-minute activity predictions during an ongoing clinical workflow (Li et al., 2022).

Third, it arbitrates access to scarce or dangerous resources. The HPC-QC middleware inserts a second scheduler beneath Slurm because coarse-grained cluster allocation does not by itself handle efficient sharing of a scarce QPU among multi-user hybrid workloads (Wennersteen et al., 24 Sep 2025). AgentWall intercepts every proposed agent action before it reaches the host and evaluates it against declarative policy with ALLOW, DENY, or ASK decisions (Aravind, 24 Mar 2026). The embodied-agent governance framework externalizes capability admission, policy checking, execution monitoring, rollback handling, and human override into a dedicated runtime layer (Qin et al., 9 Apr 2026).

Fourth, it manages movement of state or artifacts. ROOT’s package manager is designed to fetch, build, install, and integrate missing functionality “on demand” within the same interactive session (Shadura et al., 2018). PoCL-R routes OpenCL commands and data across client, server, and peer servers, with direct server-to-server migration and optional RDMA to avoid needless client bounce (Solanti et al., 2023). RIMMS conditionally moves buffers only when metadata indicates that the target resource does not already hold the valid copy (Gener et al., 28 Jul 2025).

Fifth, it performs active intervention. MorphServe swaps selected layers from FP16 to quantized replicas and resizes KV-cache capacity under pressure, then reverses the process when pressure subsides (Su et al., 24 May 2025). AI Runtime Infrastructure treats execution itself as an optimization surface for adaptive memory management, control-flow adjustment, recovery triggering, and policy enforcement (Cruz, 28 Feb 2026). The embodied-agent governance work formalizes intervention outcomes as continue, pause, stop, rollback, or handover (Qin et al., 9 Apr 2026).

Sixth, it provides observability. The HPC-QC architecture treats observability as a first-class part of the runtime environment, exposing QPU state through Prometheus with InfluxDB and planned Grafana dashboards (Wennersteen et al., 24 Sep 2025). AgentWall records a complete execution trail for audit and replay (Aravind, 24 Mar 2026). OpenClaw PRISM adds a tamper-evident audit plane with chained-hash and HMAC-style integrity semantics, while Peacock is framed as a firmware runtime observability layer for pre-OS execution (Li, 12 Mar 2026, Gorelik et al., 12 Jan 2026).

3. Architectural patterns

Several recurring architectural patterns appear across otherwise unrelated domains.

A common pattern is the split between a control plane and an execution or data plane. AI Runtime Infrastructure describes a closed-loop execution-time control plane that observes execution artifacts and emits control signals affecting subsequent execution (Cruz, 28 Feb 2026). MorphServe implements this through a Serving Monitor, a Morphing Controller, and per-worker Morphing Actuators (Su et al., 24 May 2025). TetraRL divides the runtime into a Preference Plane, Resource Manager, RL Arbiter, and Hardware Override Layer, while the base DRL agent continues to choose environment actions (Li et al., 11 Jun 2026).

Another pattern is the use of a gateway, daemon, or proxy as the service boundary. In the HPC-QC architecture, the Quantum Access Node hosts a middleware daemon that sits between SDK-facing clients and the actual QPU task queue, centralizing session management, queueing, validation, policy enforcement, and observability (Wennersteen et al., 24 Sep 2025). AgentWall is implemented as a policy-enforcing MCP proxy and native OpenClaw plugin (Aravind, 24 Mar 2026). PRISM uses an in-process plugin plus optional sidecars, distributing enforcement across lifecycle hooks from ingress through tool execution, persistence, egress, sub-agent spawning, and startup (Li, 12 Mar 2026). PoCL-R exposes remote accelerators as OpenCL devices through a remote driver and a PoCL daemon on servers (Solanti et al., 2023).

A third pattern is plugin-based or backend-based realization. HiCR’s components are abstract C++ classes realized by plugins for MPI, LPF, YuanRong, HWLoc, ACL, OpenCL, Pthreads, Boost, and nOS-V (Martin et al., 1 Sep 2025). ROOT externalizes package metadata into YAML manifests and a package database to support runtime package management above the build system (Shadura et al., 2018). Vcsn’s dyn:: layer routes dynamic calls through registries and bridge functions, and on a cache miss can generate, compile, and dlopen a plugin that registers the missing template instantiation (Demaille, 2016).

A fourth pattern is policy or override as a terminal safety valve. AgentWall’s policy model returns ALLOW, DENY, or ASK (Aravind, 24 Mar 2026). The embodied-agent governance system places a Policy Guard and Human Override on the execution path (Qin et al., 9 Apr 2026). TetraRL combines a learned arbiter with a Hardware Override Layer that projects unsafe proposals to safer executed actions (Li et al., 11 Jun 2026). This suggests that many runtime support layers use a learned, heuristic, or optimization-oriented controller for most decisions but retain a final conservative enforcement mechanism.

4. Domain-specific realizations

The concept appears in materially different technical settings, but with recognizable family resemblance.

In heterogeneous HPC and distributed execution, HiCR provides an abstract execution substrate for topology discovery, memory management, communication, and compute across distributed heterogeneous systems (Martin et al., 1 Sep 2025). PREMA’s heterogeneous runtime extends this with hetero_object and hetero_task, enabling asynchronous execution, dependency inference, memory pools, and overlap of communication with computation; it reports up to 300% improvement on a single device, up to 20% better performance than MPI+CUDA for large messages, and up to 40% improvement in distributed Jacobi when runtime support is combined with over-decomposition (Thomadakis et al., 2023). RIMMS specializes the same general area to memory-state tracking across CPU, GPU, and FPGA resources, with up to 2.43X speedup on GPU-based systems, up to 1.82X on FPGA-based systems, and only 1–2 cycles of overhead per memory-management call (Gener et al., 28 Jul 2025).

In edge and offloading systems, PoCL-R functions as a distributed OpenCL runtime support layer that virtualizes remote devices, manages peer-to-peer transfers, and handles intermittent UE disconnects with session continuity (Solanti et al., 2023). The paper reports command latency of only 60 microseconds on top of network round-trip latency, up to 19x improvement in AR frame rate, 17x improvement in local energy consumption, and roughly 80% efficiency in a multi-server CFD application (Solanti et al., 2023).

In hybrid quantum-classical computing, the runtime support layer is a site-level operational layer that complements the HPC scheduler, unifies multiple SDKs through QRMI, exposes emulator, cloud, and on-prem QPU targets through the same interface, and centralizes observability and administrative access on a Quantum Access Node (Wennersteen et al., 24 Sep 2025). Its specific motivation is the mismatch between long hybrid workflows and a scarce, slow QPU, including neutral-atom devices operating at around 1 Hz shot rate and future roadmaps aiming at around 100 Hz (Wennersteen et al., 24 Sep 2025).

In language, package, and tooling systems, ROOT’s package-manager design creates a runtime-oriented modularization layer capable of “lazy install” and same-session activation of missing components on top of a minimal bootstrap install (Shadura et al., 2018). Squimera retrofits and aligns runtime capabilities across Smalltalk, Python, and Ruby so that live programming tools can inspect stacks, restart frames, patch code, and cross language boundaries within a single virtual execution environment (Niephaus et al., 2018). Vcsn’s runtime template instantiation layer brings values of unanticipated types into a templated C++ system by symbolic typing, registries, and on-demand compilation (Demaille, 2016).

In serving and agent systems, MorphServe treats model precision and KV-cache capacity as runtime-managed resources rather than fixed deployment choices; it reports 92.45 percent reduction in average SLO violations and $2.2\times$–$3.9\times$ P95 TTFT improvement compared to full-precision serving in the abstract, with broader gains in the main text (Su et al., 24 May 2025). AgentWall, PRISM, and the embodied-agent governance framework all place enforcement directly on the execution path rather than solely on prompt or model outputs (Aravind, 24 Mar 2026, Li, 12 Mar 2026, Qin et al., 9 Apr 2026). TetraRL adds runtime adaptation for embedded DRL, treating real-time, reward, RAM, and reserve as coupled objectives supervised by a separate runtime policy (Li et al., 11 Jun 2026).

In observability and forensics, Peacock is positioned as a UEFI firmware runtime observability layer spanning pre-OS execution, OS extraction, and server-side verification (Gorelik et al., 12 Jan 2026). At a different abstraction level, heap abstraction provides a runtime heap support layer for program understanding, with algorithms for transforming, merging, comparing, and changing abstract heap models, and a profiler that identified memory bloat in DaCapo applications (Marron et al., 2012).

Domain	Runtime-layer function	Representative work
Distributed heterogeneous HPC	Abstract devices, memory, communication, execution	HiCR (Martin et al., 1 Sep 2025), PREMA extension (Thomadakis et al., 2023), RIMMS (Gener et al., 28 Jul 2025)
Edge/offloading	Remote device virtualization and P2P transfer	PoCL-R (Solanti et al., 2023)
Hybrid HPC-QC	QPU-side scheduling, QRMI unification, observability	HPC-QC environment (Wennersteen et al., 24 Sep 2025)
Package/tooling	On-demand installation, live activation, cross-language tooling	ROOT (Shadura et al., 2018), Squimera (Niephaus et al., 2018), Vcsn (Demaille, 2016)
Serving and agents	Online adaptation, execution mediation, policy enforcement	MorphServe (Su et al., 24 May 2025), AgentWall (Aravind, 24 Mar 2026), PRISM (Li, 12 Mar 2026), TetraRL (Li et al., 11 Jun 2026)
Observability and analysis	Runtime telemetry, firmware visibility, heap summarization	Peacock (Gorelik et al., 12 Jan 2026), heap abstraction (1201.00947)

5. Formalization, state, and control

The surveyed works vary sharply in formalization, but most define the runtime layer through explicit state, actions, and constrained transitions rather than through informal middleware rhetoric.

HiCR formalizes the layer through component classes—Managers, Stateless components, and Stateful components—and constrains operations such as memcpy to Local-to-Local, Local-to-Global, and Global-to-Local, explicitly forbidding Global-to-Global transfers (Martin et al., 1 Sep 2025). MorphServe gives a more optimization-oriented formulation, approximating layer sensitivity offline and then applying runtime adaptation with a precomputed swapping order based on Layer Transformation Sensitivity, Layer Replacement Sensitivity, Model Degradation Sensitivity, and a Layer Importance Score (Su et al., 24 May 2025). TetraRL defines runtime state as $$z_t = [h_t,\; q_t,\; f^{cpu}_t,\; f^{gpu}_t,\; \omega_t]$$, runtime action as $$a^{sys}_t = (\Delta u_t,\; \Delta f^{cpu}_t,\; \Delta f^{gpu}_t)$$, scalarized reward as $r_{scalar,t} = \omega^\top \mathbf{r}_t$, and a constrained optimization problem over energy and memory thresholds (Li et al., 11 Jun 2026).

Safety-oriented systems formalize decisions as explicit policy outcomes. AgentWall’s effective decision set is ALLOW, DENY, or ASK, with first-match policy semantics implied by the paper’s benchmark failure analysis (Aravind, 24 Mar 2026). The embodied-agent governance framework defines Admit, Check, Observe, Intervene, and Recover functions over capability proposals, policy sets, governance context, and runtime observations, with outcomes such as accept, reject, defer, escalate, continue, pause, stop, rollback, and handover (Qin et al., 9 Apr 2026). PRISM uses conversation- and session-scoped risk with TTL-based decay, which the paper describes semantically and that can be reconstructed as time-decayed additive state over events (Li, 12 Mar 2026).

Some papers emphasize that formalization remains partial. “AI Runtime Infrastructure” is explicit that it provides no equations or universal intervention policy, and is primarily architectural and definitional (Cruz, 28 Feb 2026). ROOT likewise gives manifest schema and package-manager pipeline rather than a formal dependency calculus (Shadura et al., 2018). This suggests that runtime support layers are often specified operationally—through service boundaries, metadata, and state transitions—even when full mathematical semantics are absent.

6. Limitations, tradeoffs, and open questions

The literature is uniformly cautious about maturity and scope. The HPC-QC work describes progress toward a “basic, but portable” runtime environment and notes limitations including a single-QPU-vendor focus, Slurm-centric integration, emulator realism limits, and unfinished features such as explicit debugging, profiling, and richer scheduler co-design (Wennersteen et al., 24 Sep 2025). ROOT’s modularization is described as a design/prototype effort with unresolved issues in component definitions, activation semantics, versioning, binary distribution, and dependency management (Shadura et al., 2018). RIMMS assumes one API call is assigned to one resource, so it does not solve simultaneous multi-writer coherence (Gener et al., 28 Jul 2025).

Another recurring tradeoff is flexibility versus overhead. PoCL-R adds only about $60\,\mu s$ above network RTT for no-op command latency, yet still remains visibly slower than native OpenCL in the microbenchmark regime (Solanti et al., 2023). MorphServe’s in-process swapping cost is around 6 ms for a Llama 2 7B INT4 attention layer and is said to be fully overlapped with decoding, but scanner-backed or model-assisted runtime security layers such as PRISM show that deeper runtime inspection can incur substantial latency if invoked too often (Su et al., 24 May 2025, Li, 12 Mar 2026). Heap abstraction is useful enough for memory profiling, yet its prototype incurs 20x to 100x slowdown and around 40x memory increase, placing it firmly in an offline or diagnostic setting rather than always-on production use (1201.00947).

A further tradeoff concerns completeness versus deployability. AgentWall is not a kernel boundary and depends on complete interception coverage to be meaningful (Aravind, 24 Mar 2026). PRISM is “zero-fork” with respect to OpenClaw source code, but still framework-specific and dependent on its hook surface (Li, 12 Mar 2026). The embodied-agent governance framework is evaluated only in simulation and the paper explicitly notes that capability-package abstractions may not fit continuous-action end-to-end policies (Qin et al., 9 Apr 2026). TetraRL assumes an outer control loop operating on super-blocks and explicit runtime knobs, which may not cover all embedded DRL deployments (Li et al., 11 Jun 2026).

The open questions are correspondingly broad. HiCR identifies future work in interconnect topology discovery, latency and bandwidth capability annotations, distributed file management, multi-user job allocation, fault tolerance, and security isolation (Martin et al., 1 Sep 2025). AI Runtime Infrastructure calls for principled intervention policies, abstractions that generalize across agent architectures, and evaluation methods that account for avoided failures and intervention timing (Cruz, 28 Feb 2026). This suggests that runtime support layers remain an emerging systems category whose boundaries are becoming clearer faster than their canonical implementations.

In aggregate, the cited works portray the runtime support layer as the software locus where execution becomes governable, portable, stateful, and observable. Whether the managed object is a QPU session, a heterogeneous task graph, an LLM worker, a firmware boot path, a package installation, or an embodied capability invocation, the common claim is that execution-time mediation itself is a primary systems concern, not a residual implementation detail (Martin et al., 1 Sep 2025).