Admin — Agent Templates

Agent templates are reusable configuration bundles that multiple agents can share. 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.

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. 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 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:

Column	Notes
Name	Display name
Description	Short summary
Category	Author-chosen category tag
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	”Use this template” button that opens a dialog to create an agent

The backing query is AgentTemplatesListQuery. The create-agent-from-template flow fires CreateAgentFromTemplateMutation with the new agent’s name, slug, and any optional config overrides.

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
• 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 for the tenant-policy side of the gate and the Code Sandbox concept page 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.

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 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 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).

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.

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 }.

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.

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
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, 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 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 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 — the per-agent detail pages that inherit from templates
• Runtime Selection — Strands/Pi runtime routing
• Agent Invites — BYOB agent registration
• Skills Catalog — the skills added to templates
• Tenant MCP Servers — the MCP servers assigned to templates
• Security Center — guardrails assigned to templates
• Agents (concept) — the product model behind templates