---
title: Admin — Computers
description: The Computers surface for tenant-managed shared AI workspaces, assignments, runtime status, migration provenance, and ECS runtime intent.
---

import { Aside } from "@astrojs/starlight/components";

The Computers surface is where operators manage durable shared ThinkWork Computers. A Computer owns a live workspace and orchestration runtime for a role or function; assigned users bring requester context when they ask it to work. Managed Agents remain available as delegated workers.

## Computer list

**Route:** `/computers`  
**File:** `apps/admin/src/routes/_authed/_tenant/computers/index.tsx`

The list is driven by `ComputersListQuery` and shows:

| Column    | Notes                                                        |
| --------- | ------------------------------------------------------------ |
| Computer  | Name, slug, scope, and detail link                           |
| Access    | Direct user and Team assignment summary                      |
| Status    | Product lifecycle status                                     |
| Runtime   | Desired and observed runtime state                           |
| Template  | Linked Computer Template                                     |
| Budget    | Monthly cap and spend                                        |
| Heartbeat | Last runtime callback                                        |
| Migration | Historical source Agent provenance when created by migration |

The primary sidebar includes **Computers** in the Work group with a live count badge.

## Computer detail

**Route:** `/computers/:computerId`  
**File:** `apps/admin/src/routes/_authed/_tenant/computers/$computerId.tsx`

The detail page shows operational panels for shared capability management:

- **Status** — desired runtime status, observed runtime status, lifecycle status, budget pause state, heartbeat, and last active time.
- **Runtime** — ECS service name, EFS access point, live workspace root, and runtime config JSON.
- **Assignments** — direct user and Team assignment controls.
- **Access users** — DataTable of users with effective access through direct or Team assignments.
- **Migration** — historical source Agent, migration metadata, and creation provenance.

The status panel can update `desired_runtime_status`. The scheduled Computer runtime reconciler treats that as intent and uses the service-auth manager path to reconcile ECS desired count and provisioning.

<Aside type="note">
  GraphQL remains the user/operator product API. Provisioning ECS services, EFS
  access points, task definitions, and runtime desired count belongs to the
  internal Computer manager endpoint.
</Aside>

## Migration operations

Migration is exposed through the CLI:

```bash
thinkwork computer migration dry-run --tenant-id <tenant-id>
thinkwork computer migration apply --tenant-id <tenant-id> --confirm
```

Dry-run is the default operating mode. Apply refuses blocker groups such as multiple candidate Agents for one human, an existing conflicting Computer, or a source Agent backed by an Agent Template instead of a Computer Template.

## Runtime operations

The CLI is the first supported operator surface:

```bash
thinkwork computer runtime provision --tenant-id <tenant-id> --computer-id <computer-id>
thinkwork computer runtime status --tenant-id <tenant-id> --computer-id <computer-id>
thinkwork computer runtime restart --tenant-id <tenant-id> --computer-id <computer-id>
```

Operators can also enqueue Phase 3 smoke tasks:

```bash
thinkwork computer task enqueue \
  --tenant-id <tenant-id> \
  --computer-id <computer-id> \
  --type workspace_file_write \
  --path smoke/admin.txt \
  --content "admin smoke"
```

The Computer manager API remains internal service-auth:

```http
POST /api/computers/manager
Authorization: Bearer <API_AUTH_SECRET>

{
  "tenantId": "<tenant uuid>",
  "computerId": "<computer uuid>",
  "action": "provision"
}
```

Supported actions are `provision`, `start`, `stop`, `restart`, and `status`.

The task surface currently supports `health_check`, `workspace_file_write`, and `google_cli_smoke`. Google Workspace OAuth-backed actions are still deferred; the smoke only verifies image tooling.

## Related pages

- [Computers](/concepts/computers/) — product and runtime model
- [Integrations](/concepts/integrations) — how OSS ThinkWork keeps integration foundations separate from premium modules
- [Admin: Agents](/applications/admin/agents/) — delegated managed workers
- [Admin: Agent Templates](/applications/admin/agent-templates/) — Computer Templates vs Agent Templates
