> ## Documentation Index
> Fetch the complete documentation index at: https://to11.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Prompt Management
> What prompt management is, why prompts belong outside your application code, and how to11 versions, reviews, and releases them.
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:
```ts TypeScript theme={null}
// 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 });
```
```python Python theme={null}
# 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:
```ts TypeScript theme={null}
// 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?" },
});
```
```python Python theme={null}
# 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](/docs/platform/prompts/rendering) for the full runtime side.
## How to11 models a prompt
A **prompt** is a named, versioned template that a [project](/docs/platform/projects) 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](/docs/platform/prompts/authoring#blocks). |
| **Variables** | The `{{ placeholders }}` your application fills in at render time. Each is [renderable](/docs/platform/prompts/authoring#renderable-variables) or, when renderable is off, used only in conditions and never shown. See [Variables](/docs/platform/prompts/authoring#variables). |
| **Tools** | The tool definitions the model may call, plus a tool-choice directive. See [Tool definitions](/docs/platform/prompts/authoring#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](/docs/platform/prompts/versions-and-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](/docs/platform/prompts/authoring#blocks) page describes what each role is for; how a `developer` block reaches a model that doesn't accept that role is covered under [Rendering](/docs/platform/prompts/rendering#the-developer-role).
## 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](/docs/deploy/overview)) 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
1. **Author.** Build the version's blocks, variables, tools, and config in the editor. See [Authoring](/docs/platform/prompts/authoring).
2. **Publish.** Freeze the draft into an immutable version. See [Versions & releases](/docs/platform/prompts/versions-and-releases#versioning-and-publishing).
3. **Review.** A reviewer approves, rejects, or requests changes before the version reaches production. See [Reviewing](/docs/platform/prompts/versions-and-releases#reviewing-a-version).
4. **Release.** Point an [environment](/docs/deploy/environments) at a version: one version for all traffic, or a weighted split for an experiment. See [Releasing](/docs/platform/prompts/versions-and-releases#releasing-to-environments).
5. **Render.** Your application renders the version live for the environment it runs in. See [Rendering prompts](/docs/platform/prompts/rendering).
## Next steps
Blocks, variables, conditions, tool definitions, and model config.
Publish immutable versions and release them to environments.
Render a released prompt from your application at runtime.
The targets you release prompt versions to.