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
Current development connects Console, Workspace, Serve, and resource services around two application paths: an OPL App workspace and a built Agent deployment. Local qualification covers application deployment, process-failure observation, and recovery; this is implementation evidence, with hosted installation and end-to-end instance acceptance still tracked separately.
Public release contents, current source capabilities, and a deployed instance can differ. The repository’s installation guide and roadmap record those boundaries and the remaining work.
This page presents OPL Cloud’s product direction and current focus. Release artifacts, installation evidence, live availability, and production operation are maintained on their respective evidence surfaces. The OPL Cloud Whitepaper explains the design in depth, while the current status records what has been evidenced now.