Continuous work, separated responsibilities
OPL Cloud extends the One Person Lab work model beyond a single machine. A user can begin with local materials and an OPL App project, move into an online Workspace when remote access or collaboration is useful, bring approved data and computing resources into the same work, and return results with their context intact.
The design starts from a simple observation: complex knowledge work does not become easier merely because it runs in the cloud. Researchers still need to understand what is being used, what changed, where a result came from, and who is responsible for the next decision. OPL Cloud therefore keeps the work surface continuous while separating the responsibilities behind it.
A cloud product organized around user questions
The product is composed of six cooperating surfaces:
| Surface | User-facing role |
|---|---|
| OPL Workspace | A continuous online workbench for projects, materials, tasks, artifacts, and review. |
| OPL Gateway | Stable AI access, routing, and understandable usage signals. |
| OPL Console | Workspace, access, policy, approval, quota, and cost visibility. |
| OPL Fabric | Governed connections to compute, storage, environments, data, and external tools. |
| OPL Ledger | Inspectable links between plans, approvals, inputs, environments, outputs, and reviews. |
| OPL Serve | A path for offering mature Agent capabilities through APIs, embedded experiences, or hosted interfaces. |
These surfaces do not compete to own the same truth. Infrastructure facts stay with the resource layer, professional quality stays with the relevant Foundry Agent and human expert, and the workbench brings those facts together as clear actions for the user.
Designed for private data and real organizations
OPL Cloud assumes that valuable data and computing resources often already have an owner. Hospital data may need to remain inside an institutional boundary; a lab cluster may have its own access and cost policy; a collaborator may need to review a result without gaining broad infrastructure access.
Rather than copying everything into one platform, OPL Cloud brings an understandable plan to the relevant boundary: which inputs are needed, where work will run, what it may cost, where outputs will return, and how it can be stopped. Routine work remains quiet. Sensitive, costly, or externally visible actions receive explicit approval.
From Agent capability to a usable service
The same separation also supports Agent developers. A mature Agent can remain responsible for its domain methods and quality while OPL Cloud provides the surrounding service experience: access, policy, execution feedback, usage, evidence, and a choice of API, embedded component, or hosted interface.
This avoids two common failures. Agent developers do not have to rebuild an entire service platform for each capability, and the cloud platform does not claim professional authority that belongs to the Agent and its human owner.
Current product boundary
The current implementation has a focused Pilot shape: a thin Console, independent online Workspaces, governed model access, a portable local workspace path, and evidence that remains separate from professional quality judgment. The immediate goal is to prove one complete user path in which a Workspace can be created, inspected, opened, and removed while AI usage remains authoritative and understandable.
This page describes the product direction and current focus, not a general-availability announcement. Release artifacts, installation evidence, live availability, and production operation remain separate proof surfaces. The OPL Cloud Whitepaper explains the design in depth, while the current status records what has been evidenced now.