Admin — Agent Templates

Templates are reusable configuration bundles for agent authoring infrastructure. They still exist for supported template flows, but they are no longer the primary place operators tune the managed-agent runtime. For day-to-day operation, configure tenant-wide defaults in Tenant Agent and local context or runtime policy in Spaces.

Note

Older template docs described fleet-wide rotation across many top-level managed agents. The current model is one tenant platform agent plus Spaces. Use this page for template UI that still exists; use Tenant Agent and Spaces for current runtime behavior.

A template can define defaults such as model, built-in tool opt-ins, default knowledge bases, MCP server assignments, guardrail attachments, system prompt, budget caps, and workspace files where the template UI still owns that flow.

Template kind matters:

• Agent Templates describe reusable or legacy bundles for delegated-agent authoring infrastructure.

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 (AGENTS.md, CONTEXT.md, GUARDRAILS.md, TOOLS.md, skills/<slug>/SKILL.md, etc.) — propagated via workspace composition. Live-class files update on next invocation with no sync step; pinned guardrail files require a per-agent Accept update review; USER.md is rewritten server-side on human reassignment.

This is how template-backed authoring flows stay reusable. It is separate from Space runtime policy, which is the current model for workroom-specific execution behavior.

The template list

Route: /agent-templates
File: apps/web/src/routes/_authed/_tenant/agent-templates/index.tsx

The list is a searchable table showing every Agent 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 (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	Supported legacy or authoring actions

The backing query is AgentTemplatesListQuery. Where an Agent Template still exposes a create-agent action, treat it as legacy or authoring infrastructure rather than the primary path for new managed-agent specialization.

The template detail

Route: /agent-templates/:templateId
File: apps/web/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: 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
• Web Extraction card — opt this template into the tenant-configured web_extract 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
Web Extraction	webExtract / web_extract	web_extract	Tenant Firecrawl 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 Spaces -> 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 Spaces -> 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.

Web Extraction card

The Web Extraction card controls whether agents using this template can receive the web_extract built-in. This is separate from configuring the tenant’s Firecrawl key under Spaces -> Built-in Tools.

The toggle persists to the template’s webExtract GraphQL field / web_extract 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-extract-config.ts.

Use Web Extraction for reading, summarizing, analyzing, or quoting one known public URL. Use Web Search to discover candidate URLs, then Web Extraction to read selected pages. Browser Automation remains the fallback for pages that require interaction or rendered-state inspection.

web_extract is injected by runtime configuration. Do not install web-extract as workspace/skills/web-extract/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:

• Pi — the active managed runtime substrate for agents.

The template runtime is retained for template-backed flows. It is not the primary user-facing control for normal Space operation. See Runtime Configuration for tenant-agent defaults and Space overrides.

Template model choices are constrained by the tenant Model Catalog. A globally known Bedrock model does not appear here unless the tenant catalog has an enabled row for it. Disabling a model in Model Catalog prevents new template/profile selections from using that model while preserving historical traces that already reference the raw Bedrock model ID.

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 — AGENTS.md, CONTEXT.md, GUARDRAILS.md, TOOLS.md, skills/<slug>/SKILL.md, and so on.

Edits to this tab propagate to linked agents through workspace composition at read time, not through the Sync flow. Specifically:

• Live files (AGENTS.md, CONTEXT.md, ROUTER.md, TOOLS.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) — 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/web/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, Firecrawl Web Extraction 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, web_extract, send_email, browser_automation, and execute_code are injected runtime tools controlled by Space, platform-agent, 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

• Tenant Agent — tenant-wide platform-agent defaults
• Spaces — Space-specific context, triggers, settings, and members
• Runtime Configuration — tenant-agent defaults and Space overrides
• 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 current tenant platform-agent model