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.
| Need | Starting surface | Confirm before work |
|---|---|---|
| Sources, reasoning, and saved deliverables | Workspace Project and Session | Actual source access and a reviewable output. |
| Use an existing compatible assistant | Hosted Workspace MCP | Client compatibility, browser authorization, and exposed tools. |
| Run a supported external agent harness | BYOA when available | Supported host, provider authentication, allowances, and saved state. |
| Use websites or hosted scripts | Available cloud browser or compute | Required capabilities and the controls for stopping usage. |
| Use a particular computer’s applications | Approved connected computer | Correct enrolled machine, desktop setup, and online availability. |
| Create and control a standalone runtime by API | Sandbox API | Returned 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.
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.