Skip to main content
A template isn’t agent-callable until it’s Active. Publishing is the act of flipping a template’s status to Active and saving — at which point the template appears in list_templates and can be rendered by generate_template. This page covers the status lifecycle, the scope model, and how scope precedence resolves when more than one template shares a key.

​
Status lifecycle

Templates live in one of two states:

Draft

Author-only. Doesn’t appear in list_templates. Cannot be rendered by generate_template. Use for in-progress work, A/B variants, or anything you want to keep private to yourself.

Active

Published. Visible to every agent connected to your Deal Brain MCP server, scoped by the template’s visibility (see below). Callable by key.
You can move a template between Draft and Active freely. Demoting an Active template to Draft is the right move when you’ve spotted a bug and want to take it out of circulation without deleting it.

​
Saving vs. publishing

There’s no separate “publish” action — toggling Status to Active and clicking Save publishes. Likewise, toggling to Draft and saving unpublishes.

​
Naming and discoverability

Your template’s name and description are what agents see when they call list_templates. Treat them as the agent-facing documentation:
  • Name should be short and unambiguous. Opportunity readout (3-paragraph) is better than Brief.
  • Description should tell an agent when to pick this template over another. “Three-paragraph brief covering deal context, last meeting, and next steps. Use for daily standup prep.”

​
Scope: who can see a template

Every template has a scope that defines its audience. There are three:
ScopeAuthored byVisible toEditable by
System (Preset)Deal BrainEveryone in every workspaceDeal Brain only — read-only for customers
Organization (Team)Anyone in your orgEveryone in your orgAnyone in your org with template-author permission
User (Personal)An individualThat individual onlyThat individual only
You can clone a System template into your Organization or User scope to customize it. The original System template is untouched; your clone is independently editable.

​
Precedence

When an agent calls generate_template by key, multiple scopes can hold a template with the same key. Deal Brain resolves the most-specific scope visible to that user: 
User scope (your personal version)
    ↓ falls through if absent
Organization scope (your team's version)
    ↓ falls through if absent
System scope (Deal Brain's default)
Example. Your organization has customized the daily-brief System template — there’s now an Organization-scoped daily-brief that includes your team’s specific KPIs. You personally further customize it for your own use — a User-scoped daily-brief. When your agent calls generate_template({ key: "daily-brief" }):
  1. Deal Brain checks for a User-scoped daily-brief for you. Found → use it.
  2. (Falls through if not found.) Check Organization-scoped → use it.
  3. (Falls through if not found.) Use the System-scoped default.
Your colleagues — who don’t have a User-scoped daily-brief — get the Organization-scoped version. Customers in a different organization get the System default.
Precedence applies per user. A User-scoped template only overrides for the author. Your personal customization doesn’t leak to teammates.

​
Scope changes are not retroactive

If you change a Draft template’s scope from User to Organization, it becomes visible to your org only after you save. There’s no historical “this used to be a User template” leak — but historical agent runs that rendered the User-scoped version remain attributed to that scope in trace metadata.

​
Editing a published template

A live template can be edited in place — change the content, save, and the next render uses the new version. Two things to know:
  1. Edits take effect immediately on save. There’s no review step. If your org wants a review workflow, gate it socially (PR-style “show your teammate before saving”) or use the Draft → Active toggle as a manual approval signal.
  2. Renders in progress are not affected. A render that’s already begun completes against the version it loaded. Subsequent renders use the new version.
For risky edits to high-traffic templates (e.g., your daily-brief), the safe pattern is: clone the Active template to a new Draft, edit the Draft, preview-and-test against several opportunities, then either replace the Active template’s content or change its key in lock-step with your agent’s generate_template call.

​
Deleting a template

ScopeDeletion rules
SystemCannot be deleted. You can clone, override, and ignore — but the System version remains as a fallback.
OrganizationAnyone in the org with template-author permission can delete. Deleted templates soft-delete (recoverable for 30 days).
UserThe author can delete their own. Soft-delete with 30-day recovery.
Deleting a higher-scope override does not delete the version it was overriding — agents fall through to the next scope.

​
What happens after publish

The moment you save an Active template:
  • It appears in list_templates output for every user it’s visible to.
  • It can be rendered by generate_template({ key }) over MCP.
  • Renders emit Langfuse traces tagged with the template’s key, status, and scope for audit.
If you want to verify your template is live, ask your agent to list templates — it should be there.

​
See also

  • Concepts for the broader model.
  • MCP tools for generate_template and list_templates in detail.