Skip to main content
An agent workspace is a project-scoped runtime for tools such as shell and Data Lake operations. Select the organization and project, then open AgentOps → Workspaces. The actions available depend on your permissions, the workspace’s ownership and runtime type. A shared workspace may be visible but read-only; some agent-managed workspaces have different controls.

​
Inspect or create a workspace

Select a workspace to review its status, runtime, image and observation details. A status observation can be stale or unconfirmed; refresh and inspect the resource before starting, stopping, or updating it. If it is missing, check the selected project and its access settings. For example, create a cloud workspace using Azure Container Apps:
  1. Choose Create workspace, enter a name such as analysis-workspace, set Type to cloud, and choose Azure Container Apps as Runtime provider. The provider is fixed at creation; the deployment must have its infrastructure and permissions configured.
  2. Choose Track stable under Image Update Policy. Leave environment variables, GitHub repository, and setup script empty for this example. Under Storage, add a Blob Path only for a project folder the workspace is permitted to use; obtain the actual path and grants from your administrator. A path in the form does not itself grant storage access.
  3. Review Sharing and select the intended project scope, then create the workspace. Wait for provisioning and inspect the displayed status and image. If provisioning fails, use the displayed error with your administrator; do not assume a cloud runtime is ready merely because it appears in the form.
Workspace creation does not configure secret injection or network policy. Arrange and verify these with your deployment administrator before relying on them. A track-stable image follows the platform-selected stable image; a pinned image stays on the selected image until changed. For an eligible track-stable workspace, Roll out image updates the runtime. Check the resulting image and status before relying on the change.

​
Open a web application

A process listening on localhost inside a workspace is not automatically reachable from your browser. Do not assume that the workspace’s tool API URL can forward an arbitrary loopback port or provide a project-authorized web preview. Use a preview endpoint only when it is explicitly supported and configured for that runtime. For a container-backed web app, use the supported Hosted App publication workflow when it is enabled. Otherwise, ask the deployment administrator for a separate authenticated application endpoint. That application must verify its users and their access to the intended project. Opening a URL from a ThinkPlatform page does not transfer the page’s permissions to the application. See Cloud and edge operations for the distinction between inspecting a cloud app and changing its deployment.

​
Stop, resume, or delete

Where available, Stop and Resume change runtime state. Check the resulting status after the action. A Sandbox preview may retain its disk across stop and resume, but recreating it starts a new disk. Treat workspace local files as ephemeral unless durable backing is configured, and verify any required outputs in durable storage. See Data management. Deleting a workspace removes the workspace and can interrupt agents or flows that use it. Before using Delete, review dependencies and save needed files to a durable location. Confirm the deletion in the dialog and check the workspace list afterward. Deletion and stopping are different operations; stopping is appropriate when the runtime should remain available to resume. Human sign-in and workspace execution credentials are separate. A workspace may use a managed identity for external resources, and its allowed paths and grants affect what it can access. See Security and authentication. If provisioning or an action fails, check the displayed error, selected project, workspace ownership, runtime configuration and underlying resource permissions with the responsible administrator. See also Cloud and edge operations and the CLI guide. For an agent-owned Sandbox, use the update controls in Agent settings rather than treating it as an ordinary shared workspace. Legacy migration and Sandbox updates have distinct file-transfer conditions.