Skip to content
ThinkWork ThinkWork

Template Authoring

Templates are authoring infrastructure. They give teams reusable starting points for workspace files, skills, tools, and migration flows, but they are not the main runtime concept users should reach for when shaping work.

For current managed-agent operation:

  • Configure tenant-wide defaults in Admin - Tenant Agent.
  • Configure project, team, customer, channel, or workflow context in Admin - Spaces.
  • Use template flows when you need a reusable folder tree, a supported migration path, or a legacy template record for audit.

What Templates Are For

Section titled “What Templates Are For”

Use templates when you need reusable starting points:

  • Workspace files and skill folders that should be copied or inherited by an authoring flow.
  • Built-in tool opt-in patterns that an existing template surface still manages.
  • MCP server assignments where the template UI is still the configured path.
  • Legacy agent-template records that must remain understandable for audit or transition.

Do not use templates as the first answer when a Space needs a different model, guardrail, budget, paused state, or sandbox. Put those differences on the Space.

Authoring Folder Trees

Section titled “Authoring Folder Trees”

Agent Templates are reusable or legacy bundles for delegated-agent authoring infrastructure. The exact UI available depends on the deployment and migration state. If a template page offers a workflow, use it for that workflow; otherwise prefer Tenant Agent and Spaces.

Start with the smallest folder tree that explains the work.

  1. Write the root CONTEXT.md for the tenant platform agent.
  2. Add one AGENTS.md routing row for each specialist the generalist should delegate to.
  3. Create each specialist under workspaces/<slug>/ with a focused CONTEXT.md.
  4. Add folder-level GUARDRAILS.md only when the specialist truly needs narrower policy.
  5. Put capability guidance in TOOLS.md or a local skills/<slug>/SKILL.md.
  6. Attach skills in the Skills column of the routing table.

Example:

| Task               | Go to                  | Read                             | Skills                      |
| ------------------ | ---------------------- | -------------------------------- | --------------------------- |
| Expense receipts   | workspaces/expenses/   | workspaces/expenses/CONTEXT.md   | approve-receipt, tag-vendor |
| Recruiting screens | workspaces/recruiting/ | workspaces/recruiting/CONTEXT.md | score-candidate             |

Prefer shallow trees. Nested specialists are allowed, but each additional workspaces/<child>/ layer should earn its keep. The depth cap prevents runaway delegation while leaving room for realistic enterprise structures.

Local skills can be imported under skills/<slug>/SKILL.md, but inline SKILL.md authoring in the builder is not part of the v1 surface.

Relationship To Spaces

Section titled “Relationship To Spaces”

Spaces are runtime workrooms. Templates are reusable authoring bundles.

Use a Space when you need:

  • Access control.
  • Local workspace files.
  • Space-scoped tools or memory.
  • Automations.
  • Email triggers.
  • Runtime overrides.

Use a template when you need:

  • A reusable bundle for an authoring or migration flow.
  • A legacy template record preserved for audit.
  • A starting point for workspace or tool configuration where the UI explicitly supports it.

Relationship To Folder Specialists

Section titled “Relationship To Folder Specialists”

Folder specialists are authored under the tenant agent at workspaces/<slug>/. If a specialty should be available to the platform agent, author it as a folder specialist. Do not create a separate top-level managed agent solely to represent that specialty.

Migration Notes

Section titled “Migration Notes”

After the platform-agent migration:

  • Historical agent-template links may still appear on legacy records.
  • Existing template pages can remain useful for review, audit, or supported authoring flows.
  • New operator runbooks should point users to Tenant Agent and Spaces first.
  • Per-agent model/runtime rotation playbooks should be rewritten as tenant-agent default changes or Space override changes.
Section titled “Related Pages”