Workstation

A Workstation is the runtime carrier for a Digital Employee in standalone mode—a physical or virtual machine with the Gendial client installed and registered with the platform. The introduction of workstations physically separates a Digital Employee's "thinking" from its "execution": reasoning and decisions happen in the cloud, while tool and skill operations execute on the designated workstation.

Overview

The workstation management entry is located in the Workstations tab under the Digital Employees page in the admin panel. Each user can only see and manage their own registered workstations; workstations cannot be shared between users. Tenant administrators additionally have a Tenant Workstation Management view to see all users' workstations across the tenant.

Workstation and Work Mode Relationship

Digital Employees have three work modes (see Digital Employee Settings). Both standalone and dynamic modes can use workstations:

Work Mode	Execution Environment	Uses Workstation
Assistant Mode	User's local computer	No
Standalone Mode	Designated workstation	Yes (required)
Dynamic Mode	Switched dynamically at runtime	Yes (optional)

When a Digital Employee selects standalone mode, all tool calls and skill executions are routed to the designated workstation. The cloud handles reasoning and decisions; the workstation handles execution. The two communicate in real-time via WebSocket long connection.

Registering a Workstation

Workstations are not pre-created on the platform—they are automatically registered when the client runs for the first time. The process is:

Step 1: Install the Client

Install the Gendial Workbench client application on the target machine. After installation, the client runs in the background as a system tray icon.

Step 2: Select Work Mode

On first launch, the client displays a configuration wizard. In the first step, select Standalone Workstation Mode, then log in with your platform account.

Step 3: Fill in Workstation Information

In the wizard's final step, enter the workstation's name, description, and the working directory accessible to Digital Employees. After confirming, the client automatically registers the workstation with the server, generating a unique workstation ID.

After registration, the workstation appears in the admin panel's Workstations tab and can be selected as the execution target for Digital Employees in standalone mode.

Workstation Status

A workstation's operational status is reflected by these indicators:

• Online Status: Online (green) indicates the client's WebSocket connection to the platform is normal; Offline (red) indicates a disconnected connection
• Enabled Status: Disabled (yellow tag) indicates an administrator has manually disabled the workstation. When disabled, the workstation receives no tasks even if the client is online
• IP Address: The workstation's current network address, used for operational location
• Operating System: The workstation's OS information (Windows / macOS / Linux)
• Offline Time: When the most recent disconnection occurred

Click Refresh to update online status.

Management Operations

Enable/Disable Workstations

In the actions menu, you can Enable or Disable a workstation. Disabling is a "soft offline"—the client remains connected, but the platform no longer dispatches tasks to the workstation. This is suitable for scenarios requiring temporary maintenance without fully disconnecting.

Delete Workstations

Deleting a workstation deregisters the instance and releases the workstation ID. Note: if any Digital Employees are bound to this workstation in standalone mode, they will be unable to execute tools and skills. Confirm no active Digital Employees depend on the workstation before deletion.

Workstation Ownership and Visibility

Workstations belong to the user who registered them. In the admin panel's workstation list, each user can only see their own registered workstations. Tenant administrators can view all users' workstations and their respective owners in the Tenant Workstation Management view.

Workstation Following for Shared Digital Employees

When you share a Digital Employee with other users, if the Digital Employee has workstations configured (standalone or dynamic mode), the recipient automatically uses the Digital Employee's configured workstations when chatting — no need to register or configure their own.

This means:

• Sharing a Digital Employee also shares its workstation capabilities
• Recipients don't need to register workstations themselves to use the Digital Employee's tools and skills
• When multiple users use the same Digital Employee, all sessions use the Digital Employee's configured workstations

Isolation Design

For unshared scenarios, workstation isolation still applies:

• User A's workstations cannot be seen or used by User B (except indirectly through a shared Digital Employee)
• If a team needs shared workstation resources, a single user (or service account) should register and manage all workstations uniformly
• Administrators can start/stop/delete workstations across users for unified operations

Containerized Workstations

A containerized workstation runs without a locally installed client — when a Digital Employee needs to execute tools, the platform automatically creates an isolated Docker container on a dedicated Sandbox server. The container is per-session: each time a user starts a chat with the Digital Employee, a new container is created on demand.

How It Works

Containerized workstations use lazy creation: the container is only created when the Digital Employee first invokes a tool (bash, read, write, etc.), not at session start. This keeps session initialization fast — users see an immediate response, and the container spins up in the background.

1. A Digital Employee is configured with a containerized workstation in standalone or dynamic mode
2. The user starts a chat — the session begins without a container
3. When the first tool is called, the platform creates a Docker container on the Sandbox server
4. The container runs Gendial Workbench and connects to the platform via WebSocket
5. All subsequent tool calls in the same session execute in this container
6. When the user disconnects, the container remains alive for 3 minutes to support reconnection
7. After 3 minutes of idle time, or 3 minutes of no tool activity, the container is automatically destroyed

This ephemeral model ensures:

• No cross-user data leakage (each session has an independent container)
• No idle resource waste (containers auto-destroy)
• Fast reconnect (containers persist for 3 minutes after disconnect)

Resource Limits

Each ephemeral container is allocated:

Resource	Limit
Memory	256 MB
CPU	0.5 core
Processes	30

Creating a Containerized Workstation

This feature is restricted to Tenant Admins and Agent Admins.

1. Navigate to Digital Employees and switch to the Workstations tab
2. Click Create Container Workstation in the top right
3. Enter a name and description
4. Search for and select the user to assign in the "Assign User" field
5. Click Save

The workstation record is created. Containers are created automatically on first use — no manual container management needed.

Containerized vs Physical

	Physical	Containerized
Creation	Client registers	Platform creates
Location	User's local machine	Sandbox server
Lifecycle	User controls	Per-session, auto-destroyed after idle
Isolation	Shared machine	One container per session
Who creates	Any user	Admin only
User assignment	Self	Admin assigned
Best for	Local resources, GUI apps	Background compute, batch tasks

Limitations

Due to the container environment, the following tools are not supported:

Limitation	Reason
Playwright / Puppeteer	Requires Chromium + GUI libraries
GUI applications	Requires X11/Wayland display server
Docker CLI	No Docker daemon inside container
Hardware passthrough	USB, serial, GPU not available

Use a physical workstation for the above. Bash, Python, Node.js, Git, and most MCP servers work normally.

Pre-installed Libraries

The container image includes common data science and file processing libraries pre-installed for immediate use:

Python: numpy, pandas, scipy, scikit-learn, matplotlib, seaborn, plotly, Pillow, opencv-python, openpyxl, xlrd, python-docx, python-pptx, PyPDF2, pdfplumber, requests, beautifulsoup4, lxml, pyyaml, tabulate, rich, sympy

System: git, curl, wget, poppler-utils, imagemagick, jq, unzip, p7zip-full

Container Management (Super Admin)

Super Admins can view and manage all running ephemeral containers through the Container Management page in the admin panel:

• View server resource usage (memory, CPU, container counts)
• List all running containers with session, user, and agent details
• Manually destroy containers if needed

Orphan containers (e.g., Redis data lost but container still running) are automatically cleaned up after 2 hours.

Daemon Configuration

The Sandbox daemon requires a single environment variable to function:

GENDIAL_SERVER_ADDRESS=http://your-server:3333

This tells containers where to connect. Set this in the daemon's .env file. No additional configuration is needed on the gendial server.

Deleting

Deletion works the same as physical workstations, but also destroys the underlying Docker container. Any Digital Employee relying on the workstation will lose tool execution capability.

Workstations and Digital Employees do not have a one-to-one binding relationship:

• One workstation can be shared by multiple Digital Employees created by the same user (as long as they all select standalone mode and specify that workstation)
• Once a Digital Employee selects standalone mode, it can only be bound to one workstation
• If a Digital Employee selects dynamic mode, it can dynamically decide at runtime whether to use a workstation and which one to use