Prompts

A prompt is free-form text you hand to a model. Unlike the other context types it has no schema to satisfy, which makes it the right place for anything that is not a policy, a routine, or a glossary. The most common use is an agent's system prompt, the text that defines who the agent is.

Prompts belong to the project. An agent picks one on its System prompt step and binds to the exact version you select. Writing a system prompt inline while creating an agent saves it here as an ordinary prompt, so it is versioned and reusable from that point on.

Writing a prompt

Choose the format that fits the content: Plain Text, Markdown, YAML, or JSON. The choice determines how the detail view renders the body, so a Markdown prompt displays as formatted text with its headings, emphasis, and inline code intact rather than as raw characters.

Naming a new prompt something that already exists does not create a second prompt. It adds a version to the existing one, so the same steps work whether you are creating something or revising it.

Variables

Write {{variable_name}} anywhere in the body and the platform picks it up automatically, with no separate registration step. Names take letters and underscores only. The detail view lists every variable it found, which is the quickest way to catch one you have mistyped.

Referencing other contexts

When editing or creating a prompt, the Add context reference button inserts a pointer to another context inside this prompt's body. This is how you keep a single copy of something several prompts share, a tone guide or a set of rules, instead of pasting it into each one.

Choose whether the reference follows a label or pins to a version. Pointed at latest it picks up the referenced prompt's newest version automatically; pinned to a version number it stays there until you change the reference.

What lands in the body is a tag, in this case: @@@InteractiveAIPrompt:name=sourcing-rules|label=latest@@@. The Tagged context and Resolved context toggle above the body switches between the tag as written and the referenced content in place, which is how you confirm a reference resolves to what you expected.

Versions and labels

Every save creates a new version instead of overwriting the current one, and the panel on the left lists them all with the author and date. Each card also carries the labels on that version and the agents using it, so you can see which revision is actually in play before you change anything. A prompt can be shared by several agents. Versions cannot be edited in place, which is what keeps the history trustworthy. New starts another version from the one you are viewing, and the commit message is what makes that history readable months later.

latest is applied automatically and always points at the newest version. Every other label is yours to create and move: the label control on a version opens Context version labels, listing the labels already in the project with a field for adding a new one.

The detail view

Five tabs sit above the content.

• Context shows the item itself, rendered for its type.

• Config holds the arbitrary JSON attached to this version.

• Linked Generations lists the observations that used this version, with the same filters, columns, and export controls as Observability. This is how you tell whether a version is actually being exercised in production, and how it performs when it is.

• Use Context gives you a ready-made Python snippet for fetching the item, either by label or pinned to a version number. Every context type is fetched with get_prompt and its full path.

• Label History is an audit log of label movement: which label changed, whether it was added or removed, the version it landed on, who moved it, and when.

Metrics, in the top right, swaps the versions panel for a table comparing every version side by side: median latency, median input and output tokens, median cost, how many generations used it, and when it was first and last used. It is the fastest way to catch a version that got slower or more expensive before you promote it.