Skip to main content

Runtime Core

Probabilistic intelligence needs deterministic execution.

This page explains what Runtime Core is, why it exists, and how it enables governed agentic execution in practice.

What this means​

Runtime Core is a deterministic distributed runtime responsible for execution, coordination and persistence of actions across the system. In Subbasis, it is the execution authority that translates workflow intent into controlled runtime actions.

LLMs can propose actions, but Runtime Core determines how actions are executed inside policy, approval, and evidence boundaries.

Why it matters​

Real business operations must survive imperfect conditions: connector outages, human delays, retries, changed rules, and partial failures. If execution is unmanaged, side effects become unpredictable and hard to review.

Deterministic execution boundaries matter for:

  • retries without duplicate side effects
  • approval enforcement before sensitive actions
  • evidence continuity for review and debugging
  • replay/review of critical operations
  • workflow recovery after interruption
  • governance enforcement across teams

Subbasis does not claim absolute mathematical determinism for every external system. Instead, it constrains execution through deterministic contracts, policies and evidence boundaries.

How Subbasis handles it​

Subbasis Runtime Core (Rust-based runtime core) focuses on:

  1. Execution control: action eligibility is checked against role, policy, and operation state.
  2. Coordination: runtime coordinates agent tasks, approval gates, and connector actions in one execution path.
  3. Persistence: workflow state is durable so operations can wait and resume.
  4. Evidence binding: important decisions and outcomes are written into reviewable records.
  5. Recovery semantics: runtime tracks failures and retry eligibility instead of relying on ad-hoc scripts.

This approach creates a deterministic distributed execution path even when upstream reasoning is probabilistic.

Example scenario​

A sales agent recommends sending a follow-up after reading account context.

  • The LLM proposes a message and tone.
  • Runtime Core checks whether sending is authorized for that role.
  • If policy requires approval for outbound action, it routes to an approval gate.
  • After approval, runtime invokes the allowed connector path.
  • Runtime records evidence: proposal, approval, connector action, and result.

The model contributes reasoning. Runtime Core enforces controlled execution.

What to configure​

Typical runtime-facing configuration elements:

  • workflow definitions and step transitions
  • role permissions and policy rules
  • approval gates and escalation behavior
  • connector/adapter bindings
  • retry and timeout behavior
  • evidence granularity and retention posture

Limits and deployment notes​

  • Exact throughput and deployment profile depend on environment and plan.
  • External systems can still fail or respond inconsistently; runtime boundaries reduce impact but do not erase external risk.
  • Advanced distributed or federated patterns should be treated as architecture paths unless explicitly enabled in your deployment.