Prompt Management

Prompt management is the practice of treating the prompts you send to a model the way you already treat code that ships to production: keep them in one place, version every change, review before release, roll out deliberately, and roll back when something regresses. to11 does this for the prompts your project owns: you author them in the dashboard, and your application renders the published version at runtime through an SDK.

Why prompts don’t belong in your code

Most LLM features start with the prompt written inline, right next to the call to the model:

// The prompt is buried in the application.
const messages = [
  { role: "system", content: "You are a helpful weather assistant." },
  { role: "user", content: `I'm in ${city}. ${question}` },
];
const completion = await openai.chat.completions.create({ model: "gpt-4o", messages });

# The prompt is buried in the application.
messages = [
    {"role": "system", "content": "You are a helpful weather assistant."},
    {"role": "user", "content": f"I'm in {city}. {question}"},
]
completion = openai.chat.completions.create(model="gpt-4o", messages=messages)

That works until it doesn’t. The prompt is the part of an AI feature you tune most often, yet burying it in code means:

Every wording change is a code change: a pull request, a build, a deploy, all for a tweak a product manager could have made in a text box.
There’s no history. You can’t see what the prompt said last Tuesday, who changed it, or why the quality dropped after the change.
You can’t roll back a bad prompt without shipping a revert.
You can’t run two variants against each other without branching your application.
Only engineers can touch it, even though the people who understand the prompt best often aren’t engineers.

Prompt management pulls the prompt out of the binary and puts it behind a versioned, reviewable, releasable surface. The same feature now renders its prompt:

// The prompt lives in to11. The app renders the released version.
const rendered = await to11.prompts.render("weather-concierge", {
  variables: { city: "New York", user_message: "Do I need a jacket?" },
});

# The prompt lives in to11. The app renders the released version.
rendered = to11.prompts.render(
    "weather-concierge",
    variables={"city": "New York", "user_message": "Do I need a jacket?"},
)

The application no longer contains a single line of prompt text. Changing the prompt (fixing a phrasing, adding an example, tightening a rule) is now an edit-and-release in the dashboard, not a redeploy. See Rendering prompts for the full runtime side.

How to11 models a prompt

A prompt is a named, versioned template that a project owns, alongside that project’s providers, routing, and traces. It has a stable slug (weather-concierge) your application renders by, and a history of versions behind it. A version is one immutable snapshot of the template. It carries everything needed to render the messages the model sees:

Part	What it is
Blocks	The ordered messages (`system`, `developer`, `user`, `assistant`, and tool-result turns) that make up the conversation, each optionally gated by a condition. See Authoring.
Variables	The `{{ placeholders }}` your application fills in at render time. Each is renderable or, when renderable is off, used only in conditions and never shown. See Variables.
Tools	The tool definitions the model may call, plus a tool-choice directive. See Tool definitions.
Model config	The model id and generation settings (temperature, token limit) authored alongside the template.

Authoring happens on a draft. Publishing freezes the draft into a read-only version and starts a fresh draft from the same blocks, so what’s live never changes underneath you. See Versions & releases.

Message roles

Each block is a message with a role that tells the model who is speaking and how much authority the message carries. system and developer are the author’s roles, and they outrank the end user’s user messages, so a rule you set isn’t overridden by what a user types. assistant blocks and tool-result blocks stand in for earlier turns in the conversation. The Authoring page describes what each role is for; how a developer block reaches a model that doesn’t accept that role is covered under Rendering.

Two planes: authoring and serving

to11 keeps the surface you manage prompts on separate from the surface that serves them:

The control plane (the dashboard and the SDK’s prompts.* methods) is where you author, version, review, and release. It’s backed by the to11 API.
The data plane (the gateway) is where your model calls actually run. When you render a prompt you get back rendered messages, tools, and a tool-choice directive; you pass those to your provider client, pointed at the gateway, and the call is traced end to end.

The two planes share the same project and environment, so the version you released is exactly the version your application renders, and the render is stamped onto the resulting trace.

The lifecycle

Author. Build the version’s blocks, variables, tools, and config in the editor. See Authoring.
Publish. Freeze the draft into an immutable version. See Versions & releases.
Review. A reviewer approves, rejects, or requests changes before the version reaches production. See Reviewing.
Release. Point an environment at a version: one version for all traffic, or a weighted split for an experiment. See Releasing.
Render. Your application renders the version live for the environment it runs in. See Rendering prompts.

Next steps

Authoring prompts

Blocks, variables, conditions, tool definitions, and model config.

Versions & releases

Publish immutable versions and release them to environments.

Rendering prompts

Render a released prompt from your application at runtime.

Environments

The targets you release prompt versions to.

Get Started

Instrument

Deploy

Observe

Evaluate

Platform

Prompt Management

Why prompts don’t belong in your code

How to11 models a prompt

Message roles

Two planes: authoring and serving

The lifecycle

Next steps

Authoring prompts

Versions & releases

Rendering prompts

Environments

​Why prompts don’t belong in your code

​How to11 models a prompt

​Message roles

​Two planes: authoring and serving

​The lifecycle

​Next steps

Authoring prompts

Versions & releases

Rendering prompts

Environments

Why prompts don’t belong in your code

How to11 models a prompt

Message roles

Two planes: authoring and serving

The lifecycle

Next steps