Skip to main content

A practical Workspace guide

Choose an environment by what the agent must reach.

Choose an AI agent environment by the files, tools, runtime, and access the task requires. In Clanker, start with Workspace for Project work, add cloud execution for a concrete computing dependency, use a connected computer for that machine’s apps, and use Sandbox API when you need a standalone programmatic runtime.

Start with $20 in included credits. See usage and plans.

Write the dependency before choosing the machine

Describe the missing capability in one sentence. “Read three approved proposals and save a comparison” describes a Project file task. “Run this analysis script with an installed library” adds a computing requirement. “Use the accounting app installed on the office computer” identifies a particular machine. Those are different environment choices even if the same agent coordinates them.

Begin with the least complicated environment that can satisfy the requirement and expose the result for review. Moving a writing task into a desktop introduces another running resource without necessarily improving the deliverable. Keeping a required local app outside the plan makes the task impossible regardless of how detailed the prompt is.

Match Clanker’s surfaces to the work

The table describes starting points, not interchangeable access paths. Confirm availability and selected tools in the actual account before relying on one.

Match Clanker’s surfaces to the work
NeedStarting surfaceConfirm before work
Sources, reasoning, and saved deliverablesWorkspace Project and SessionActual source access and a reviewable output.
Use an existing compatible assistantHosted Workspace MCPClient compatibility, browser authorization, and exposed tools.
Run a supported external agent harnessBYOA when availableSupported host, provider authentication, allowances, and saved state.
Use websites or hosted scriptsAvailable cloud browser or computeRequired capabilities and the controls for stopping usage.
Use a particular computer’s applicationsApproved connected computerCorrect enrolled machine, desktop setup, and online availability.
Create and control a standalone runtime by APISandbox APIReturned identity, capabilities, credentials, and expiry.

Choose what must survive the task

List the evidence and outputs that the next task needs. Save those to the intended durable location and verify them independently of the running environment. A process can finish without exporting its output; a saved file can remain after its compute stops. Treat these as separate checks.

For BYOA, inspect the last confirmed save rather than assuming every private file or in-memory change survived. For Sandbox API, /data survives compute sleep for the sandbox lifetime, but deletion removes sandbox-scoped data. Retain the resource identity and expiry. A longer runtime allowance does not replace a clear retention or export plan.

Test capability at the connection you will use

A native Workspace Agent, an external MCP client, a BYOA harness, and an HTTP script can expose different operations. Check the tool list or API contract for the chosen path. A file-reading success does not prove command execution, App publication, or direct browser control is available.

BYOA currently does not provide direct Cloud Browser or Cloud Desktop control or every native Agent tool. Hosted Workspace MCP and HTTP authentication are separate. Do not move a token between them or add broad access merely because a desired action is missing. Decide whether the task can be simplified or needs another supported interface.

Account for authorization and the review point

Write down what the agent may read, save, execute, and change outside the Project. An environment with a network connection can reach more than the user intended; capability does not establish permission. For an initial trial, choose fictional or approved sources and a saved draft with no external delivery.

With external MCP, review the permission grant across the connected user’s accessible Workspace; selecting a Project in the prompt is not a project-only OAuth restriction. For connected-computer work, confirm the actual device and required apps. Keep secrets in the supported credential path rather than embedding them in a context file.

Make one choice and keep the exit criteria

Suppose a fictional museum needs a checklist from three exhibit planning files. Start with a Workspace Project and one saved checklist. If the next step needs a script to reconcile 200 CSV rows, add supported compute for that step. If it needs a catalog application available only on the museum computer, plan that approved connection explicitly.

Before expanding, inspect the output and record actual usage. State when work stops: after the checked file is saved, after the bounded computation, or after a separately approved recurring run. Closing a viewer may leave compute active. Stop the underlying resource when finished and preserve a handoff that explains how the result was produced.

Try it with a small example.

Open Workspace

Copy into a Workspace Session. Opening Workspace does not send it automatically.

Before you use the result.

  • Each runtime choice answers a stated task dependency.
  • Required operations exist on the chosen interface.
  • Saved outputs and process lifetime are checked separately.
  • The plan has explicit permissions, review, and shutdown steps.

Common questions.

Does every agent task need a cloud computer?

No. Start with a normal Workspace Session for writing, research, Project files, and selected tools. Add cloud compute, a browser, or a connected computer only when a required operation needs it.

Can I assume the same tools across native Agents and external agents?

No. Verify the tools exposed to the actual client and account. BYOA, hosted MCP, the HTTP API, and native Agents have different coverage and setup requirements.

Does persistent context mean an agent process stays online?

No. Saved Project material and successfully saved agent state can outlive compute. BYOA tasks are bounded, and a standalone sandbox has its own lifetime. Inspect the exact running resource and retained result.

Sources: Clanker: Workspace product behavior and feature availability · Clanker: external-agent access, permissions, and managed Sessions · Clanker: BYOA setup, runtime, saved state, and usage · Clanker: Sandbox lifetime, files, and recovery runbook · Clanker: where work runs and how to stop it

Content reviewed against the Workspace Guide & FAQ. Features and access can depend on your account.