---
title: Templates
description: Templates are the configuration reuse layer for Computers and Agents — one named template holds the model, guardrail, inference params, tool surface, memory behavior, workspace files, and budget caps that a fleet shares.
---

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

Templates are named bundles of configuration that Computers and Agents share — and the harness's mechanism for **fleet coherence**. Model selection, guardrail assignment, inference parameters, tool surface, memory behavior, workspace files, budget caps — everything that shapes *how* a Computer or delegated Agent behaves — lives on the template.

Templates carry a kind:

- **Computer Template** — starting point for a durable user-owned [Computer](/concepts/computers/).
- **Agent Template** — starting point for a delegated managed Agent.

Computers and Agents *reference* templates; they don't copy every live value. The whole layer exists to implement the **Reliability** operating guarantee at fleet scale (two runtime entities on the same template behave identically because they read identical config) and the **Security** operating guarantee (capability grants and guardrail attachments are template-pinned, so a malicious skill-pack upload can't widen what the runtime reaches).

That reference is the single most important property of the model: **edit the template once, and every runtime entity using it picks up the live change on the next invocation.** Rotating Claude versions across 100 delegated Agents is one write. Tightening guardrails across a tenant is one write. Cutting a budget cap in half is one write.

This page is the conceptual deep dive: why templates exist in this shape, what a template carries, how inheritance and overrides work, and the fleet-rotation playbook that motivates the whole design. For the admin UI that surfaces templates to operators (the template editor, the sync flow, the linked-agents view), see [Admin: Agent Templates](/applications/admin/agent-templates/).

## Why templates exist

Imagine configuring every agent individually. Each agent picks its own model, writes its own guardrail reference, maintains its own tool enable-list. That works for three agents. It collapses at thirty. Three things go wrong:

- **Drift.** Two agents that were supposed to behave identically diverge over a year of independent edits. Nobody remembers which was the "canonical" version.
- **Migration pain.** A new Claude model ships. You now have 45 agents to update, by hand. Half get done this sprint, half don't, and behavior across the fleet silently splits.
- **Audit collapse.** An operator asks "which agents currently use the strictest guardrail?" There's no answer without reading every agent's config individually.

Templates are the specific answer. Model, guardrail, budget, tool config, memory behavior all live on the template. The agent points at the template. A query across the fleet gives one row per agent with consistent shape — auditable, changeable in one edit.

<Aside type="tip">
  If you find yourself copy-pasting configuration between agents, you want a template. If you find yourself copy-pasting *across templates*, you probably want a shared [skill pack](/concepts/agents/skills/) both templates reference.
</Aside>

## What a template carries

Categorically — not field-by-field — a template bundles:

### Default runtime

The managed runtime newly-created agents should use by default. Strands is the default and stable path; Pi is the parallel managed runtime for canaries and Pi-backed agents. Existing agents can still override the runtime per agent, so use the template runtime when a whole class of new agents should start on Pi.

See [Runtime Selection](/concepts/agents/runtime-selection/) for the runtime model.

### Model configuration

The model id, max output tokens, temperature, and any other Bedrock inference parameters the agent should use. Changing the model id on a template swaps models for every agent on it on the next invocation. No redeploy.

### Guardrail attachment

The Bedrock Guardrail id (and version) applied on every Bedrock call for this template. Guardrails are enforced *inside* the model invocation, not wrapped around it — that's what makes them non-bypassable. If a skill pack tried to call Bedrock directly, it would still get the guardrail applied, because the runtime passes the guardrail id through every invocation configured for the template.

### Tool configuration

Which tool categories are exposed to the agent at runtime — SQL, S3, web search, integration-provided MCP tools, built-in tools. Flags, not prompt-level gates: a disabled category is actually absent from the tool registry, not just discouraged by instruction.

Also here: the per-turn tool-call cap, the safety valve against runaway tool loops.

### Company Brain behavior

Which memory adapter the agent uses (Hindsight or AgentCore Memory), how many recalls to attempt, whether the agent participates in compiled Company Brain pages, and how many pages to surface per turn. See [Company Brain](/concepts/knowledge/) for the source-routing story.

### Budget policy

Monthly spend cap. Whether hitting the cap pauses the agent automatically. Optional soft per-turn cost signal that flags expensive turns in the audit without interrupting them.

### Default skill and knowledge assignments

Skill packs and knowledge bases that **new agents created from this template inherit**. These are seeds at creation time, not live-reference fields — see [Inheritance and overrides](#inheritance-and-overrides) below.

### Workspace files

Markdown files that shape the agent's runtime behavior — `SOUL.md` (personality), `IDENTITY.md` (name and role), `GUARDRAILS.md` (policy), `PLATFORM.md`, and others — live on the template. Agents read them through the [workspace overlay](/concepts/agents/workspace-overlay/), which composes at read time: agent override wins, template is the fallback, tenant defaults are the floor.

Template workspace edits are **live** for most files (next invocation sees the change, no sync step) and **pinned** for the three guardrail-class files (`GUARDRAILS.md`, `PLATFORM.md`, `CAPABILITIES.md`), which require a per-agent **Accept update** review before propagating. `USER.md` is a managed special case — rewritten server-side on human reassignment using `{{HUMAN_*}}` placeholders in the template bytes.

This is different from the skills / KB inheritance model: workspace files are not copied into the agent at creation time. They flow through the overlay chain on every read.

### Metadata

Name, description, category tag, published flag, source (built-in vs. tenant-created vs. imported). Informational — doesn't affect runtime behavior, just helps operators organize templates.

## Inheritance and overrides

The rule: **live fields come from the template on every turn; seed fields are copied to the agent and become editable.**

| Axis | Source at runtime | Editable per-agent |
|---|---|---|
| Runtime | Agent, falling back to template | Yes |
| Model id | Template | No |
| Guardrail | Template | No |
| Inference params (max tokens, temperature, …) | Template | No |
| Tool config | Template | No |
| Memory adapter + recall config | Template | No |
| Budget cap | Template | No |
| **Skill pack assignments** | Template (at create) | **Yes** |
| **Knowledge base assignments** | Template (at create) | **Yes** |
| **System prompt** | Template (at create) | **Yes**, often edited per-agent |

Said another way: model + guardrail + budget + tool config are **live** — the dial the template owner turns. Skill/KB assignments and system prompt are **seeds** — the template sets the starting point; the agent evolves from there.

This split is deliberate. The live dials are the ones where fleet-wide coherence matters (rotate models; tighten safety; cap spend). The seeded dials are where per-agent specialization matters (a support agent vs. a research agent on the same template need different system prompts).

### Overriding a live field

You can't. If an agent needs a different model, it needs a different template. Two options:

1. **Fork the template.** Duplicate, change the field, assign the agent to the fork. Now you maintain two templates independently.
2. **Split templates by axis of difference.** If half your fleet should run Sonnet and half Haiku, have two templates, not one.

The no-override rule is intentional. Per-agent overrides would turn templates into advisory config and bring back all the drift problems they exist to solve.

## The fleet rotation playbook

This is the reason templates exist in the shape they do. Walkthrough of a real rotation, conceptually.

**Scenario.** Claude 4.7 ships. Your tenant has 12 support agents running 4.6 via a template named *Support — Standard*. You want to move to 4.7 with a one-week rollback window.

### Step 1 — Canary

Fork the template to *Support — Canary 4.7*. Change the model id on the fork to 4.7. Reassign one agent (say, `support-canary`) to the new template.

The canary agent now runs 4.7; the rest of the fleet stays on 4.6.

### Step 2 — Observe for 48 hours

Watch cost per turn, latency per turn, tool-call patterns for the canary vs. the rest of the fleet. Spot-check threads for regressions in response quality. Check whether the canary trips guardrails at a different rate.

If anything looks wrong, reassign the canary back to *Support — Standard* and investigate. No rollback complexity — it's a template-id swap.

### Step 3 — Roll out

Canary clean after 48 hours. Update the canonical *Support — Standard* template's model id to 4.7. All 11 remaining agents pick up 4.7 on their next invocation. No deploy. No cache bust.

### Step 4 — Delete the canary template

Merge the canary agent back to *Support — Standard*, delete the fork. Done.

### Step 5 — Rollback (if needed)

If something surfaces later — a model regression, guardrail triggering more often — revert the template's model id back to 4.6. Next invocation across all agents is on 4.6 again. Total rollback time: seconds.

Compare that to 12 individual per-agent rollbacks, each with its own potential typo, and the reason templates exist in this shape is self-evident.

## Sync vs. live

There's one class of template edit that does *not* propagate automatically: **default skill and knowledge-base assignments.**

If a template originally seeded agents with `[crm, tone]` and you change the defaults to `[crm, tone, escalation]`, existing agents don't pick up the new skill pack. The defaults only apply at *agent creation time*.

For this case there's an explicit **sync flow** in the admin UI: the template owner reviews a diff of what would change, chooses which agents to apply it to, and triggers the propagation. This is explicit on purpose. Propagating skill/KB changes silently would break agents that legitimately diverged — a support agent who had `escalation` removed on purpose would have it silently re-added.

Live fields (runtime, model, guardrail, budget) don't need sync because agents either read them directly from the template or carry an explicit per-agent override.

See [Admin: Agent Templates](/applications/admin/agent-templates/) for the sync flow UI.

## Template categories and organization

Tenants typically grow to a dozen-plus templates. Organizing them matters.

### By axis of variation

Templates diverge along a handful of real axes:

- **Model tier.** Haiku for cheap/fast, Sonnet for balanced, Opus for hard reasoning.
- **Runtime substrate.** Strands for the stable default path, Pi for canary agents or templates validating the Pi loop.
- **Guardrail strictness.** Customer-facing needs strict PII; internal tools tolerate more.
- **Tool surface.** An eval agent needs no integrations; a support agent needs Slack + email + CRM.
- **Budget class.** Internal tools on $10/month; customer-facing on $200/month.
- **Memory adapter.** Most tenants use one adapter; occasionally an experimental template runs the other to compare.

A natural template taxonomy mirrors these: *Support — Standard*, *Support — High-Volume (Haiku)*, *Research — Extended Thinking*, *Eval — Sandbox*.

### Categories

The `category` tag is free-text and used only for filtering in the admin. Most tenants settle on 3–5 (`support`, `research`, `automation`, `eval`, `sandbox`). Don't over-engineer — it's for operator eyes.

### Publishing

An unpublished template can be edited but can't be assigned to new agents. Use this for:

- Draft templates you're iterating on before rollout.
- Deprecated templates you're leaving around for the agents still using them but don't want anyone new to adopt.

Existing assignments stay live even on unpublished templates — the gate is on *new* assignment, not on runtime.

## Template forks and lineage

Forks are templates created by duplicating another. ThinkWork tracks the parent relationship so forks know where they came from.

Lineage is informational — the fork doesn't stay in sync with its parent automatically. But the admin app surfaces "your parent template has changed since this fork was created" so operators can decide whether to re-sync specific fields manually.

Tenants that do frequent model rotations often maintain a two-template pattern: a *-Standard* and a *-Canary*. The canary is always a fork of Standard; rollouts are "promote canary values up to Standard."

## How to configure it

Templates are configured exclusively through the admin web — there is no Terraform-side or CLI-side template configuration, by design. The configuration surface is operator-facing because it's where day-to-day fleet decisions land (rotate a model, tighten a guardrail, cap a budget); putting it behind a deploy step would defeat the whole point of templates.

### Where it lives

Every template-side configuration knob is reachable from [Admin: Agent Templates](/applications/admin/agent-templates/). Three sub-views:

- **Template editor** — model, guardrail, inference parameters, tool config, memory behavior, budget cap, default skill/KB seeds, workspace files. Each field is documented inline in the editor with the field's runtime impact.
- **Linked agents view** — every agent currently referencing the template, with a quick filter for status (active/suspended) and a click-through to per-agent overrides on the seeded fields.
- **Sync flow** — the explicit propagation step for default skill/KB assignments (see [Sync vs. live](#sync-vs-live)). Surfaces a diff of what would change and which agents to apply it to.

### Tenant-scoped vs deployment-scoped

Everything in the template editor is tenant-scoped — each tenant manages its own templates, and templates don't cross tenant boundaries. The deployment-scoped settings that matter for templates aren't on the template itself, they're on the runtime that consumes it:

- **Available models.** Which Bedrock models the deployment has access to (a Bedrock account-setting + Terraform `bedrock_model_access` list). Templates can only reference models the deployment has enabled — the editor's model dropdown is a join against this list.
- **Available guardrail ids.** Bedrock Guardrails are deployment-scoped resources; templates reference them by id. Onboarding a new guardrail is a Bedrock-side step before it appears in template editor.
- **Memory adapter availability.** `enable_hindsight = true` in Terraform makes Hindsight available as a memory-adapter choice; otherwise, AgentCore Memory is the only option.

### When the defaults are wrong

The factory templates ThinkWork ships (`Support — Standard`, `Research — Extended Thinking`, `Eval — Sandbox`) are calibrated for a single-tenant pilot. They deviate as you scale:

- A multi-tenant deployment with strict-PII customers and lax-PII customers needs separate templates with different guardrail attachments — not one template with a "depends on tenant" rule (templates don't have those, and shouldn't).
- A high-volume cost-sensitive workload (Haiku-tier inference on millions of turns) benefits from a tighter `maxOutputTokens` than the defaults; the savings compound.
- An eval-heavy workflow benefits from a dedicated *Eval — Sandbox* template with no integrations, no MCP tools, and a low budget cap; tool-surface isolation is the cheapest way to keep eval runs reproducible.

For all three, the template editor is sufficient — no code changes, no deploys.

## Known limits

- **No cross-template inheritance.** Templates are flat — no parent-extends-child runtime hierarchy. If you want a "base" template several others extend, you maintain that shape manually.
- **No staged rollout for template edits.** Editing a template takes effect on every agent's next turn. For risky changes, use the canary pattern above — it's a staging mechanism the model supports by design.
- **No in-flight turn awareness.** Changing a template while a turn is executing doesn't retroactively affect that turn — the turn completes with the old config. The next turn uses the new config.
- **Built-in templates are read-only.** You can fork them, but you can't edit the originals. This prevents ThinkWork updates from surprising tenants who modified the built-ins.
- **Per-template budgets are monthly only.** Weekly or per-agent-day budgets aren't supported today.

## Related pages

- [Concepts: Agents](/concepts/agents/) — the agent side of the template reference
- [Concepts: Managed Agents](/concepts/agents/managed-agents/) — the runtime that reads templates on every invocation
- [Concepts: Skills](/concepts/agents/skills/) — the other reuse layer; capabilities that cut across templates
- [Concepts: Control](/concepts/control/) — guardrails and budgets that templates carry
- [Admin: Agent Templates](/applications/admin/agent-templates/) — operator surface, template editor, sync flow, linked-agents view
- [Admin: Agents](/applications/admin/agents/) — how agents reference templates in the admin UI
- [API Reference: GraphQL](/api/graphql/) — template queries, mutations, and subscriptions
