---
title: Admin — Agent Templates
description: Reusable Computer Template and Agent Template bundles - runtime, model, built-in tool opt-ins, workspace files, MCP servers, guardrails - plus the explicit sync flow that propagates changes.
---

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

Templates are reusable configuration bundles for either Computers or delegated Agents. A template defines the default runtime, model, built-in tool opt-ins, default knowledge bases, MCP server assignments, guardrail attachments, system prompt, budget caps, and a workspace file set.

Template kind matters:

- **Computer Templates** create or migrate user-owned [Computers](/concepts/computers/). They describe the durable workspace/orchestrator.
- **Agent Templates** create delegated managed Agents. They describe reusable workers that Computers, threads, and automations can invoke.

Templates propagate to linked agents via two distinct mechanisms depending on what changed:

- **Configuration fields** (built-in tool opt-ins, KBs, MCP servers, guardrails, model, system prompt, budget) — propagated via the explicit **Sync** flow described later on this page. Operators review per-agent diffs and confirm.
- **Workspace files** (`SOUL.md`, `IDENTITY.md`, `USER.md`, `GUARDRAILS.md`, etc.) — propagated via the [workspace overlay](/concepts/agents/workspace-overlay/). Live-class files update on next invocation with no sync step; guardrail-class files require a per-agent **Accept update** review; `USER.md` is rewritten server-side on human reassignment.

This is how fleet-wide configuration gets managed in ThinkWork without having to touch every Computer or delegated Agent individually.

## The template list

**Route:** `/agent-templates`  
**File:** `apps/admin/src/routes/_authed/_tenant/agent-templates/index.tsx`

The list is a searchable table showing every template in the tenant. The tabs filter by **All**, **Computer Templates**, and **Agent Templates**.

| Column | Notes |
|---|---|
| Name | Display name |
| Description | Short summary |
| Category | Author-chosen category tag |
| Kind | Computer Template or Agent Template |
| Runtime | Default managed runtime for agents created from the template (`Strands` or `Pi`) |
| Model | The default model this template uses (Claude Haiku, Sonnet, Nova, etc.) |
| Source | Where the template came from (built-in, tenant-created, imported) |
| Skill count | How many skills are attached |
| Published | Badge showing whether the template is publishable to child agents |
| Action | Computer Templates link to Computers; Agent Templates open the create-agent dialog |

The backing query is `AgentTemplatesListQuery`. The create-agent-from-template flow fires `CreateAgentFromTemplateMutation` only for Agent Templates. Computer creation and migration are handled from the Computers surface and migration CLI.

## The template detail

**Route:** `/agent-templates/:templateId`  
**File:** `apps/admin/src/routes/_authed/_tenant/agent-templates/$templateId.tsx`

The detail page has three tabs:

- **Configuration** - identity, model/runtime, system prompt, and built-in tool opt-ins.
- **Workspace** - template-level workspace files and workspace skills.
- **MCP Servers** - tenant MCP assignments for agents using the template.

### Configuration tab

- **Identity** — name, slug, description, category, publish toggle
- **Kind** — Computer Template or Agent Template
- **Runtime selector** — default managed runtime for new agents created from this template: Strands or Pi
- **Model select** — dropdown backed by the tenant's configured model catalog
- **System prompt editor** — the prompt inherited by agents created from the template
- **Code Sandbox card** — opt this template into `execute_code` and pick a network mode
- **Browser Automation card** — opt this template into `browser_automation`
- **Web Search card** — opt this template into the tenant-configured `web_search` built-in
- **Send Email card** — opt this template into the platform `send_email` built-in

The older **Skills** tab redirects to the Workspace tab. Operator-editable skills now live as workspace files under `workspace/skills/<slug>/SKILL.md`; built-in tools remain separate template configuration.

### System prompt editor

A full CodeMirror editor in markdown mode, vscodeDark theme. The system prompt is the single most impactful field on the template — it's what most iteration happens against.

### Linked agents section

Below the main form, the template detail page lists every agent currently linked to this template. For each linked agent, the row shows its name, status, and (after a sync is triggered) its sync status.

### Built-in tool cards

The Configuration tab carries compact cards for the built-in tools that are controlled per template. These cards do not install workspace skills; they set JSON configuration fields on the template that the runtime config resolver reads before every turn.

| Card | Template field | Runtime tool | Extra gates |
|---|---|---|---|
| Code Sandbox | `sandbox` | `execute_code` | Tenant `sandbox_enabled`; Code Interpreter provisioning |
| Browser Automation | `browser` | `browser_automation` | Agent-level capability overrides can enable or disable individual agents |
| Web Search | `webSearch` / `web_search` | `web_search` | Tenant Web Search provider row must be configured and enabled |
| Send Email | `sendEmail` / `send_email` | `send_email` | Agent email channel controls sending address and delivery policy |

#### Code Sandbox card

The Configuration tab carries a **Code Sandbox** card that controls the template's opt-in to the AgentCore Code Interpreter sandbox. The card has a single toggle — **Enable `execute_code` for agents in this template** — and, when enabled, a **Network mode** dropdown with two options:

- **`default-public` (egress)** — the sandbox can make outbound HTTPS calls. Routed to the tenant's public Code Interpreter instance.
- **`internal-only` (compute)** — the sandbox has no network egress. Routed to the no-egress Code Interpreter instance. Use this for pure-compute workloads that must not reach the internet.

The toggle persists to the template's `sandbox` field as JSON: `{ "environment": "default-public" | "internal-only" }` when opted in, `null` when the template doesn't use the sandbox. The shape is validated server-side by `packages/api/src/lib/templates/sandbox-config.ts`.

The `execute_code` tool only registers on a turn when **both** the template is opted in on this card **and** the tenant has `sandbox_enabled` set in tenant policy. Template opt-in without tenant policy is a no-op. See [Admin → Built-in Tools](/applications/admin/builtin-tools/#policy-gated-tools) for the tenant-policy side of the gate and the [Code Sandbox concept page](/concepts/agents/code-sandbox/) for how the opt-in flows through to the agent runtime.

#### Browser Automation card

The **Browser Automation** card controls whether agents using this template can receive the `browser_automation` tool. The runtime registers an AgentCore Browser plus Nova Act tool for dynamic website workflows.

The toggle persists to the template's `browser` field as JSON: `{ "enabled": true }` when opted in, `null` when disabled. The shape is validated server-side by `packages/api/src/lib/templates/browser-config.ts`.

Agent-level capability rows can still override the template default for individual agents.

#### Web Search card

The **Web Search** card controls whether agents using this template can receive the `web_search` built-in. This is separate from configuring the tenant's provider key under [Admin → Built-in Tools](/applications/admin/builtin-tools/).

The toggle persists to the template's `webSearch` GraphQL field / `web_search` database column as JSON: `{ "enabled": true }` when opted in, `null` when disabled. The shape is validated server-side by `packages/api/src/lib/templates/web-search-config.ts`.

`web_search` is injected by runtime configuration. Do not install `web-search` as `workspace/skills/web-search/SKILL.md`.

#### Send Email card

The **Send Email** card controls whether agents using this template can receive the `send_email` platform tool. The agent email channel still controls the sending address, reply tracking, and delivery policy.

The toggle persists to the template's `sendEmail` GraphQL field / `send_email` database column as JSON: `{ "enabled": true }` when opted in, `null` when disabled. The shape is validated server-side by `packages/api/src/lib/templates/send-email-config.ts`.

`send_email` is injected as a direct runtime tool. Do not install `agent-email-send` as `workspace/skills/agent-email-send/SKILL.md`.

### Runtime selector

The Configuration tab includes the template's runtime selector:

- **Strands** — the stable default managed runtime.
- **Pi** — the parallel managed runtime substrate for Pi-backed canaries and agents.

The template runtime is the default for agents created from the template. Existing agents can carry their own runtime value, so changing a template's runtime is primarily a future-agent default unless a sync or per-agent edit changes linked agents. See [Runtime Selection](/concepts/agents/runtime-selection/) for the invocation-time routing model.

## The Workspace tab

The template detail page has a **Workspace** tab alongside **Configuration** and **MCP Servers**. This is where the template's inheritance base for workspace files lives — `SOUL.md`, `IDENTITY.md`, `GUARDRAILS.md`, `skills/<slug>/SKILL.md`, and so on.

Edits to this tab propagate to linked agents through the [workspace overlay](/concepts/agents/workspace-overlay/) at read time, not through the Sync flow. Specifically:

- **Live files** (`SOUL.md`, `IDENTITY.md`, `ROUTER.md`, `memory/*.md`, etc.) — edits are visible to every linked agent on the **next invocation**. No per-agent sync, no explicit propagation step. If an agent overrode the file, its override still wins; otherwise it picks up the template's new bytes.
- **Pinned files** (`GUARDRAILS.md`, `PLATFORM.md`, `CAPABILITIES.md`) — edits do **not** flow automatically. Every linked agent surfaces a **Template update available** badge on that file. Operators review and accept per-agent (or bulk per-template) from the agent's Workspace tab. This is the safety lane for anything that could meaningfully change agent behavior.
- **Managed files** (`USER.md`) — the template's `USER.md` carries `{{HUMAN_*}}` placeholders. Agents get a rendered copy written to their own prefix when their human pair is assigned or reassigned. Editing the template's `USER.md` only affects agents that are subsequently reassigned or newly created — existing agents already carry the rendered bytes.

**Tasks on this tab:**

- **Edit a template file** — click the file in the tree, edit, save. Live files take effect on next agent invocation.
- **Add a new file** — use the **+** button in the sidebar. New files automatically flow to linked agents (unless they're ad-hoc names outside the overlay's canonical set, in which case they still inherit normally).
- **Delete a template-level override** — remove a file here and linked agents will fall through to the tenant defaults layer for that file.

Workspace skills are editable files in this tree. Built-in tools are not workspace files and are configured from the Configuration tab instead.

For the tenant-wide defaults that every template inherits from, see `/agent-templates/defaults` (the **Default Workspace** page).

<Aside type="note">
The template's Workspace tab does **not** show a per-file source badge, because by definition every file listed here is at the template layer. The operator-facing distinction matters on the _agent's_ Workspace tab, where the same file could come from the agent override, the template, or the defaults.
</Aside>

## The sync flow

**Route:** `/agent-templates/:templateId/sync`  
**File:** `apps/admin/src/routes/_authed/_tenant/agent-templates/$templateId_.sync.tsx`

Sync is **explicit**. When an operator edits a template, the linked agents do not automatically absorb the change. Instead, a **Sync** button on the detail page opens a review page that shows, per linked agent, what would change if the operator confirmed.

The review page uses an `AgentSyncCard` per agent. Each card carries the current config vs the template config and an individual "Sync this agent" button. The top of the page also has a "Sync All" button that fires `SyncTemplateToAllAgentsMutation` — a single mutation that applies the template to all linked agents server-side and returns `{ agentsSynced, agentsFailed }`.

<Aside type="note">
The explicit sync step is a deliberate design choice. Auto-propagating template changes would make fleet-wide mistakes trivially easy to ship — "I tweaked the system prompt and now 47 agents misbehave." Making operators review and confirm keeps fleet operations reviewable.
</Aside>

After the sync mutation resolves, a toast notifies the operator of success or partial failure. The linked agents list refetches so the cards reflect the new state.

## State machine: template + linked agent

```
Template edit
    │
    ▼
Template saved ──► linked agents now diverge from template
    │
    ▼
Click "Sync" on template detail
    │
    ▼
Review page renders per-agent diffs
    │
    ├──► Sync All ──► SyncTemplateToAllAgentsMutation ──► all linked agents updated
    │
    └──► Sync one at a time (per AgentSyncCard)
```

Until an operator clicks Sync, linked agents continue running with the pre-edit template configuration. Operators can verify the new template against a single agent before fanning out to the fleet.

## Workflows

### Ship a new fleet-wide workspace skill

1. Install the new skill via [Skills Catalog](/applications/admin/skills-catalog/)
2. Open the template at `/agent-templates/:templateId`
3. Confirm the Runtime selector is set to the runtime that supports the skill
4. Go to the Workspace tab and add or edit `skills/<slug>/SKILL.md`
5. Save the template
6. Click **Sync** and land on the review page
7. Confirm the diffs look right
8. Click **Sync All** — or sync one agent first as a canary, then sync the rest
9. Watch the linked agent list for sync status and agent heartbeats to confirm no regressions

### Enable a built-in tool across a template

1. Open the template at `/agent-templates/:templateId/configuration`
2. Toggle the relevant built-in tool card
3. Save the template
4. Verify any tenant-level prerequisite on [Built-in Tools](/applications/admin/builtin-tools/), such as the Web Search provider key or Code Sandbox policy
5. Run one linked agent as a canary before syncing broadly

### Tune a system prompt across the fleet

1. Open the template detail page
2. Edit the system prompt in the right-pane CodeMirror editor
3. Save
4. (Optional) Pick one linked agent, open its [Agents](/applications/admin/agents/) detail page, and run it through a manual turn to sanity-check
5. Return to the template, click Sync, and propagate the new prompt across the fleet

### Roll back a bad template change

1. Open the template and revert the system prompt (or whichever field was changed)
2. Save
3. Sync the revert out to the fleet

Template history is not currently versioned — rollback means editing forward. Per-agent config history **is** versioned (see the Rollback button on the [Agents](/applications/admin/agents/) detail page).

## Workflows not to do

- **Don't edit a linked agent directly when you want a fleet change.** Per-agent edits do not back-propagate to the template. If multiple agents need the same change, edit the template and sync.
- **Don't skip the sync step.** Editing a template without syncing leaves the linked agents in a divergent state where the template is nominally their source of truth but they're actually running the old config.
- **Don't install built-ins as skills.** `web_search`, `send_email`, `browser_automation`, and `execute_code` are injected runtime tools controlled by template and tenant policy.

## Known limits

- **No template versioning.** Rollback is edit-forward. Per-agent rollback is available through the agent detail page, but the template itself has no git-like history.
- **No template diff preview on the template detail page.** The diff only renders on the sync review page, after the operator has already saved changes and clicked Sync.
- **No dry-run.** "Sync All" is an all-or-nothing mutation; there's no simulate-sync-and-show-what-would-happen mode separate from the review page.
- **Runtime changes are not retroactive to in-flight turns.** If an agent is already running, that turn completes on the previous runtime. The next turn uses the new selector.

## Related pages

- [Agents](/applications/admin/agents/) — the per-agent detail pages that inherit from templates
- [Runtime Selection](/concepts/agents/runtime-selection/) — Strands/Pi runtime routing
- [Agent Invites](/applications/admin/agent-invites/) — BYOB agent registration
- [Skills Catalog](/applications/admin/skills-catalog/) — the skills added to templates
- [Tenant MCP Servers](/applications/admin/mcp-servers/) — the MCP servers assigned to templates
- [Security Center](/applications/admin/security-center/) — guardrails assigned to templates
- [Agents (concept)](/concepts/agents/) — the product model behind templates
