Understanding Prompts

What a prompt template is

A prompt template is a named object saved inside a workspace. It holds three things: an ordered list of messages, a model configuration, and the variable names the messages reference.

Take support-agent, the template this page uses as its running example. It’s built for a customer-support agent: a system message, a user message, a model configuration that picks the model and its settings, and the variables {{company_name}} and {{customer_question}} its messages fill in. Every template you build has this same shape, whatever it does.

The object model

A template doesn’t stand alone.

• It can be seeded from a base template, a reusable starter you begin from and edit into your own template instead of an empty editor. Base templates come from the product’s built-in library or from prompts your team has saved as reusable starting points, and you pick one from the template browser when you start a new prompt
• It can live in a folder, so a workspace with a growing library stays navigable
• It carries a version history, built up as you commit

flowchart TD
accTitle: The prompt template object model
accDescr: A workspace holds prompt templates directly. A folder is an optional way to organize templates within a workspace. A base template can seed a new template. Each template is made of an ordered list of messages, a model configuration, and the variable names it expects. Committing a template produces a version, a snapshot of those three parts.
WS["Workspace"] --> PT["Prompt template · support-agent"]
WS --> FL["Folder"]
FL -. optional .-> PT
BT["Base template"] -. seeds .-> PT
PT --> MSG["Messages (ordered) · system, user, assistant"]
PT --> CFG["Model configuration"]
PT --> VAR["Variable names · company_name, customer_question"]
PT -- commit --> PV["Version · snapshot"]

Two of these edges are easy to miss. Seeding from a base template only sets the starting content: once support-agent exists, editing it never touches the base template it began from. And committing produces a version, a snapshot of the messages, model configuration, and variables at that point. This page stops at that fact; how versions and labels work together is its own page.

Messages and roles

The messages inside a template are ordered, and each one carries exactly one of three roles: system, user, and assistant. A message with any other role is rejected, not just discouraged by the editor.

In support-agent, the system message sets the agent’s behavior (“You are a support agent for {{company_name}}”) and the user message carries the incoming question ({{customer_question}}).

Model configuration

The model configuration covers three decisions:

• Which model runs the template
• Generation settings, things like temperature and max tokens
• What the model is allowed to produce: a plain string, a tool call, or a structured response matching a saved schema

It’s saved on the template alongside the messages and variables. See Model configuration for the full field list and validation rules.

Variables

Variables are {{name}} markers inside a message’s content, substituted with real values at run time. support-agent’s user message reads something like:

Answer the following customer question clearly and professionally:
{{customer_question}}

The template stores the variable names it expects, company_name and customer_question, so the platform knows what to ask for wherever the template runs. Where the values themselves come from depends on where you run it: typed into the editor, pulled from a dataset’s columns, or passed in from your application.

Placeholder messages

A placeholder message is a different thing from a variable, and it’s easy to confuse the two. A variable substitutes a value inside a message’s content, so the message stays a single string. A placeholder is tracked separately from a template’s variables, as its own named entry on the template, rather than as a substitution inside a message’s content.

Why the object model matters

Every piece above, from the model configuration down to placeholders, lives on the template itself. That’s why support-agent runs the same wherever you call it, and why a version always tells you exactly what ran.

Keep exploring