Prompts in production aren’t just text files; they’re living, breathing code artifacts that need rigorous management.

Let’s see what that looks like with an example. Imagine you’ve got a customer support chatbot that uses a prompt to summarize user issues.

# prompt_v1.yaml
name: summarize_customer_issue
version: 1.0.0
description: Summarizes a customer's reported issue for internal routing.
template: |
  The customer has reported the following issue:

  {{ customer_input }}


  Please summarize this issue in one sentence, focusing on the core problem and any requested action.
  For example, if the customer says "My internet is down and I can't connect to any websites",
  the summary should be "Customer reports internet outage and inability to connect to websites."
context:
  model: gpt-4-turbo
  max_tokens: 100
  temperature: 0.3

This prompt_v1.yaml defines a prompt named summarize_customer_issue, version 1.0.0. It includes the actual template text, along with metadata like description, context (which specifies the LLM model, token limits, and temperature), and importantly, a version.

Now, you need to deploy this. A common pattern is to use a prompt registry or a version control system integrated with your LLM deployment platform. Let’s say you’re using a hypothetical tool called promptctl.

# Uploading the prompt to the registry
promptctl push prompt_v1.yaml

# Verifying the prompt is registered
promptctl list --name summarize_customer_issue

The output of promptctl list would show:

Name: summarize_customer_issue
Versions:
  - 1.0.0 (latest)
  - description: Summarizes a customer's reported issue for internal routing.
  - context:
      model: gpt-4-turbo
      max_tokens: 100
      temperature: 0.3

This prompt is now available for your application to reference by its name and version. Your application code might look something like this (using a hypothetical LLM client library):

from llm_client import LLMClient

client = LLMClient(api_key="YOUR_API_KEY")

customer_message = "My internet is down and I can't connect to any websites. What should I do?"

# Fetching and executing the prompt
response = client.generate_text(
    prompt_name="summarize_customer_issue",
    prompt_version="1.0.0",
    variables={"customer_input": customer_message}
)

print(response.text)

This would output:

Customer reports internet outage and inability to connect to websites.

Now, imagine you want to improve the prompt. Perhaps you notice the summaries are sometimes too generic. You decide to refine it to include the customer’s sentiment.

# prompt_v2.yaml
name: summarize_customer_issue
version: 1.1.0
description: Summarizes a customer's reported issue, including sentiment.
template: |
  The customer has reported the following issue:

  {{ customer_input }}


  Please summarize this issue in one sentence, focusing on the core problem, any requested action, and the customer's sentiment (e.g., frustrated, confused, neutral).
  For example, if the customer says "My internet is down and I can't connect to any websites. This is so frustrating!",
  the summary should be "Customer reports internet outage and inability to connect to websites, expressing frustration."
context:
  model: gpt-4-turbo
  max_tokens: 120 # Increased token limit for potentially longer summaries
  temperature: 0.3

Notice the version is now 1.1.0. This is a minor version bump, indicating a backward-compatible change. You’d push this new version:

promptctl push prompt_v2.yaml

Your application can now choose to use this new version. A common deployment strategy is to gradually roll out new prompt versions. You might update your application configuration to point to 1.1.0 for a small percentage of users first.

# Application configuration update (example)
PROMPT_CONFIG = {
    "summarize_customer_issue": {
        "name": "summarize_customer_issue",
        "version": "1.1.0", # Now using the new version
        "variables": ["customer_input"]
    }
}

# ... later in your code ...
prompt_info = PROMPT_CONFIG["summarize_customer_issue"]
response = client.generate_text(
    prompt_name=prompt_info["name"],
    prompt_version=prompt_info["version"],
    variables={"customer_input": customer_message}
)

If you encounter issues with 1.1.0, you can easily roll back by changing the version in PROMPT_CONFIG back to 1.0.0 and redeploying your application. This versioning allows for A/B testing of prompts, safe experimentation, and quick rollbacks.

The real power comes when you consider how prompt versions interact with your LLM deployment. You’re not just deploying code; you’re deploying a specific configuration of parameters and instructions that directly influence model behavior. The context block, with its model, max_tokens, and temperature settings, is as critical as the template itself. Changing these parameters can have as significant an impact as rewriting the instructions. For instance, increasing temperature from 0.3 to 0.8 might make the summaries more creative but less factual, and this change would be captured by incrementing the version number.

The next challenge you’ll face is managing prompt drift and ensuring that prompts remain effective as user input patterns or underlying LLM models evolve.

Want structured learning?

Take the full Prompt-engineering course →