Open Science makes remote compute a three-step decision
An SSH connection looks like a simple upgrade for an AI agent. Once that connection reaches a laboratory workstation, GPU box, or shared server, though, three ideas tend to blur together: the machine exists, this session may know about it, and the current task should run there.
AIPOCH's Open Science keeps those decisions separate. A remote machine can be configured, enabled for a session, and selected as an execution target in three distinct stages. The result is a control model that other agent builders can borrow, whether or not they use this workbench.
Configured is not available
Open Science is an Apache-2.0, local-first research workbench for macOS, Windows, and Linux. It combines agent sessions with Python and R execution, files, scientific connectors, artifacts, and provenance records. AIPOCH introduced session-scoped compute in Open Science v0.18.1. The product has since reached v0.20.1, while the detailed remote-compute guide was checked against v0.18.2. Anyone deploying it should confirm the behavior in their installed version.
The documented host model has three meaningful states:
- Configured: an SSH profile exists in the desktop application. The agent does not necessarily know it exists.
- Enabled: the host is exposed to one session and appears to the agent as
available, but it is not yet an execution target. - Selected: the enabled host is also chosen as a target for that session.
Consider a lab that configures one server for several projects. Its presence in the settings should not reveal its name or capabilities to every research session. Enabling it makes discovery deliberate. Selecting it records execution intent.
AIPOCH's remote SSH guide adds an important limit: selection does not send every operation to that machine. Execution still depends on the task instructions, the Remote Compute capability, permissions, connection state, and the requested operation. A session can select several hosts, but the guide does not promise automatic ranking or placement among them.
The extra click preserves a boundary. The interface does not pretend to be a cluster scheduler.
The desktop owns credentials; automation chooses from inventory
In the documented v0.18.2 workflow, host creation, credentials, connection testing, editing, and deletion were desktop-only. The CLI and Task API could select machines already in the inventory, but they could not register a new host while submitting work.
A person establishes the infrastructure inventory and its credentials. An automated task chooses only from that approved inventory. In the documented interface, the Open Science CLI used a repeatable --compute-host <provider-id> option; the Task API and SDK supplied a computeHostIds array.
The layers translate directly to other agent systems:
admin inventory: registered hosts + credentials
session scope: hosts the agent may discover
run intent: hosts selected for this task
operation approval: command, files, and network action
One toggle cannot represent all four layers without making review ambiguous. A successful connection test says only that the client can reach the host. It says nothing about whether a dataset may leave the workstation, whether the remote account can write into shared directories, or whether the installed environment matches the analysis plan.
Local-first does not mean local-only
Open Science stores project state, sessions, files, artifact versions, settings, and logs locally by default. Its data-flow guide also spells out what the label does not cover: model requests, web searches, connectors, MCP servers, and remote compute may send information elsewhere.
An SSH job can transmit commands, files, parameters, and job data. For unpublished results, licensed corpora, patient data, or information covered by regional controls, the destination and payload matter more than the phrase “local-first.”
Before a remote run, a team should be able to answer five questions:
- Which account will the agent use on the remote host?
- Which directories can that account read and write?
- Which files or records will cross the boundary?
- Can the remote process reach the public internet or internal services?
- Which logs and artifacts will return, and who can review them?
The SSH key covers only part of the authorization story. Operating-system permissions, network policy, data governance, and review of the command remain separate responsibilities. Our least-privilege checklist applies the same rule to agent tools: narrow the capability before depending on an approval prompt.
Record remote execution as a decision
Separating the states helps during a run; recording their changes helps afterward. Open Science describes immutable artifact versions and inspectable provenance for evidence it can verify. That does not establish scientific validity. It can, however, leave a clearer path from inputs and execution to the resulting file.
A useful remote-execution record should include:
- the configured host identifier, without exposing credentials;
- whether the host was only enabled or explicitly selected;
- the actor or policy that changed each state;
- the command and working directory;
- hashes or stable identifiers for transferred inputs;
- exit status, output artifacts, and relevant environment details;
- every approval, denial, retry, and fallback.
The record should stand on its own instead of requiring a reviewer to replay a chat. A remote job may finish successfully while using stale data, running in the wrong environment, or producing an artifact that cannot be tied back to its inputs. Agent traces that explain failures are also useful when the terminal says the run succeeded.
What Open Science does not solve
The versioned guide describes SSH remote compute. It does not describe native Slurm submission, cloud-GPU provisioning, automatic multi-node scheduling, or automatic placement among selected hosts. Those limits matter. A session target picker can govern access without replacing cluster policy or workload management.
Nor does the workbench validate a research method. A perfectly recorded command can still use the wrong cohort, apply an unsuitable statistical test, or reproduce an error. Open Science says researchers remain responsible for methods, interpretation, privacy, and scientific validity.
Remote compute should not be a binary permission called “SSH access.” Infrastructure registration, session discovery, target selection, and operation approval are separate decisions. Open Science gives each one a visible place in the workflow. Storing a credential is not the same as granting a session authority to use it.
