Operating Model

How Runtime acts as the shared operational layer for the platform.

Agentic Friendly

Runtime follows a shared platform model. It is operated as a common capability layer that multiple higher-level services consume.

Core Principle

Runtime owns platform concerns. Higher layers own product and use-case concerns.

That separation keeps the architecture clearer:

  • Runtime focuses on secure execution, exposure, persistence, observability, and delivery
  • CoreAI focuses on AI platform services and developer-facing capabilities
  • ProAI focuses on enterprise data systems and advanced data operations

Runtime Responsibilities

Runtime is responsible for the platform mechanisms that should behave consistently across the stack:

  • network exposure and ingress
  • identity and access patterns
  • secrets and certificate handling
  • inference execution substrate
  • workflow execution substrate
  • operational storage services
  • monitoring, logging, and tracing
  • GitOps deployment mechanics

How Other Layers Consume Runtime

Higher layers are expected to consume Runtime rather than replace it:

  • an AI service uses Runtime ingress, identity, storage, and telemetry
  • a workflow-oriented service uses Runtime workflow engines and storage
  • a user-facing application benefits from the same DNS, TLS, and access patterns as the rest of the platform

Why This Matters

The operating model reduces duplication and makes the platform easier to scale. Instead of each product area solving security, routing, monitoring, and storage independently, those concerns are handled once in Runtime and reused consistently.

On this page