---
title: "Update Template"
method: PATCH
path: "/worker-templates/{template_id}"
tags: ["worker-templates"]
---

# Update Template

`PATCH /worker-templates/{template_id}`

## Path parameters

- `template_id` string, required

## Request body

- UpdateWorkerTemplateRequest — Partial patch. Only the fields passed are written. Editing a template changes what **future** workers are seeded with. Workers already deployed from it keep the config they were created with — the template is copied at origination, never re-read. ``custom_instruction`` carries all three intents: omitted leaves it alone, a string overwrites it, and an empty string clears it. Attachments are changed by naming them: ``add_trigger_rule_ids`` points more rules at this template, ``remove_trigger_rule_ids`` clears the pointer on rules that have it. Rules you don't name are untouched, so a field-only patch can never disturb them and a caller never has to send the current set back to preserve it.
  - `name` string, nullable — Omit (null) to leave unchanged.
  - `mode` 'incident' | 'alerts' | 'custom' — The kind of channel the agent lives in — its standing mission. Drives the swappable mode block in the system prompt (and, later, the toolset). ``escalation`` and others land as localized drop-ins (their standing block + tooling) when that work begins. ``incident`` and ``alerts`` each state a mission the worker owns whatever the operator writes. ``custom`` states none: it supplies only the conduct floor the identity block forward-references, and the operator's ``custom_instruction`` is what gives the worker something to do. A channel that is neither working an incident nor triaging alert fires gets this one rather than being told it is in an incident (PRD-3766). The value is what customer-facing surfaces render, so it reads as the operator's own word for it rather than as an internal category. A member's *name* is persisted, in ``resident_agent_workflow.mode`` and ``resident_agent_template.mode`` — plain varchars with no DB-side value set — and read back through this enum, so adding a member is one deploy but removing or renaming one orphans every row holding it. It also makes a member forward-only: code that predates it raises on a row that carries it, rather than degrading. So a new member wants its read deployed everywhere before anything can write it — either landing the member ahead of the paths that create it, or gating creation while it rolls out.
  - `custom_instruction` string, nullable — Omit (null) to leave unchanged, pass a string to overwrite, or pass an empty string to clear it.
  - `add_trigger_rule_ids` string[] — Live rules to point at this template. Valid on its own.
  - `remove_trigger_rule_ids` string[] — Rules to stop pointing at this template. Valid on its own.

## Response `200`

Successful Response

- WorkerTemplateResponse
  - `id` string, required
  - `organization_id` string, required
  - `name` string, required
  - `mode` 'incident' | 'alerts' | 'custom', required — The kind of channel the agent lives in — its standing mission. Drives the swappable mode block in the system prompt (and, later, the toolset). ``escalation`` and others land as localized drop-ins (their standing block + tooling) when that work begins. ``incident`` and ``alerts`` each state a mission the worker owns whatever the operator writes. ``custom`` states none: it supplies only the conduct floor the identity block forward-references, and the operator's ``custom_instruction`` is what gives the worker something to do. A channel that is neither working an incident nor triaging alert fires gets this one rather than being told it is in an incident (PRD-3766). The value is what customer-facing surfaces render, so it reads as the operator's own word for it rather than as an internal category. A member's *name* is persisted, in ``resident_agent_workflow.mode`` and ``resident_agent_template.mode`` — plain varchars with no DB-side value set — and read back through this enum, so adding a member is one deploy but removing or renaming one orphans every row holding it. It also makes a member forward-only: code that predates it raises on a row that carries it, rather than degrading. So a new member wants its read deployed everywhere before anything can write it — either landing the member ahead of the paths that create it, or gating creation while it rolls out.
  - `custom_instruction` string, nullable, required
  - `created_at` string, date-time, required
  - `updated_at` string, date-time, required

## Other responses

- `422` — Validation Error

## Changes

> 27 revisions in range; 7 not diffed.

- **2026-09-02** `3025330cc50d` — 1 warning, 1 info
  - added the new `custom` enum value to the `mode` response property for the response status `200`
  - added the new `custom` enum value to the request property `mode/anyOf[subschema #1: Mode]/`

[Change history](https://skmtc.dev/traversal/apis/fastapi/changes/worker-templates/:template_id/patch.md)

---

[API](https://skmtc.dev/traversal/apis/fastapi.md) · [All operations](https://skmtc.dev/traversal/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/traversal/fastapi/revisions/3025330cc50d/schema)