A frontier product is only as good as the runtime underneath it. The UI can explain the product, but the runtime decides whether it can survive real users, real money, real agents, real queues, and real devices.
That is why we built Glove as an application runtime instead of a prettier chat widget. Tools define what the system can do, renderers define what the user sees, adapters decouple models and stores, and the display stack lets tools pause for real human input. The agent is not the whole product. It is the orchestrator inside a product whose capabilities have been designed deliberately.
We made the same move with Station for background work. A job is not just a function that runs later. It is a typed signal with a schema, a handler, retries, scheduling, persistence, run history, and a dashboard. The important part is not that it can run a task. The important part is that the work has a durable shape: inputs are validated, attempts are recorded, failures retry with policy, and the system can be inspected after the fact.
The operating loop comes first.
When we design a system, we start by naming the loop it lives inside. For an agentic application, the loop is message, model, tool call, result, display, user decision, repeat. For a background job system, it is trigger, validate, run, persist, retry, observe. For a robot platform, it is connect, inspect capability, launch app, read state, send action, monitor.
Origin makes that robotics loop explicit. It gives developers a CLI and dashboard, supports real and simulated devices, and asks apps to declare what device type, actions, state, runtime, and secrets they need. The app should not have to care whether the target is a real Unitree robot or a simulator. The runtime normalizes that boundary so the developer can reason about capabilities instead of transport details.
Workflows inherit the system contract.
We apply the same posture in Cradle Markets. The product is not a single trading page. It is an issuer console, marketplace, and launchpad running on the same compliance and settlement rail. Token issuance, investor trading, lending, and capital raises are separate workflows, but they share identity, compliance, and settlement assumptions.
That matters because regulated markets punish ambiguity. If the issuer flow, investor flow, and launchpad flow each invent their own logic, the system becomes a pile of reconciliations. If they share a rail, the product can expose different workflows without fragmenting the underlying truth.
How this changes client work.
For a client, this means we do not start by asking only what screens need to exist. We ask what must be true for the system to keep working after launch:
- What are the core state transitions?
- Which operations need human approval?
- Which actions must be deterministic instead of model-mediated?
- What needs to be visible in logs, dashboards, or audit history?
- What can be swapped later without rewriting the product?
Only then do we design the interface. The interface should feel direct because the system underneath has already done the hard work of deciding what is allowed, what needs review, what can fail, and how recovery works.
That is the Cradle Labs bias: build the runtime first, then ship the interface that makes the runtime usable.