Principle:Arize ai Phoenix Prompt Creation
| Knowledge Sources | |
|---|---|
| Domains | Prompt Engineering, LLM Observability, AI Asset Management |
| Last Updated | 2026-02-14 00:00 GMT |
Overview
Prompt creation is the practice of defining and persisting LLM prompts as structured, versioned assets within a centralized management system, enabling teams to treat prompts as first-class software artifacts rather than ephemeral strings embedded in application code.
Description
In modern LLM application development, prompts are the primary interface between application logic and model behavior. Prompt creation refers to the process of authoring a prompt definition -- including its message template, target model configuration, invocation parameters, and optional tool definitions -- and registering it in a prompt management system so that it can be retrieved, versioned, and shared across environments.
Without a formal creation workflow, prompts tend to be scattered across codebases as hard-coded strings. This makes it difficult to track which prompt text produced a given model output, to roll back to a previous version when a regression is detected, or to coordinate prompt changes across development, staging, and production environments. A prompt management system addresses these problems by providing an explicit creation step that assigns each prompt a unique name, stores its full configuration, and returns a server-assigned identifier that can be referenced throughout the application lifecycle.
The key elements of a prompt asset are:
- Template -- the text or structured message sequence sent to the model. Templates may contain variable placeholders (e.g.,
{{question}}) that are resolved at runtime. - Model configuration -- the target model name (e.g.,
gpt-4o) and provider (e.g.,OPENAI,ANTHROPIC,GOOGLE). - Invocation parameters -- provider-specific settings such as temperature, max tokens, top-p, and stop sequences.
- Tools and response format -- optional tool definitions for function-calling models and JSON schema constraints for structured output.
- Description and metadata -- human-readable context that helps collaborators understand the prompt's purpose and lineage.
When a prompt is created, the system either registers a brand-new prompt under the given name or appends a new version to an existing prompt with that name. This upsert semantic means that the creation operation is idempotent with respect to the prompt name: calling it repeatedly produces a linear version history rather than duplicate entries.
Usage
Prompt creation should be used in the following scenarios:
- Initial authoring -- when a developer writes a new prompt for a feature such as summarization, classification, or retrieval-augmented generation.
- Programmatic registration -- when prompts are generated or transformed by automated pipelines (e.g., prompt optimization loops) and need to be persisted for evaluation.
- Multi-provider support -- when the same logical prompt must target different model providers. The creation API accepts provider-specific configuration, and helper constructors (
from_openai,from_anthropic,from_google_generativeai) allow converting native SDK objects into prompt versions. - Collaboration -- when multiple team members need a shared, authoritative source for prompt definitions instead of copy-pasting strings across repositories.
Theoretical Basis
Prompt creation draws on established software engineering principles:
Configuration as Code
Treating prompts as declarative configuration objects -- rather than inline strings -- enables the same workflows used for infrastructure-as-code: version control, code review, automated testing, and audit trails. A prompt version captures a snapshot of the full configuration at a point in time, ensuring reproducibility of model behavior.
Immutable Artifacts
Each created prompt version is immutable once persisted. Immutability guarantees that a version identifier always resolves to the same template and model configuration, which is essential for debugging production incidents and for reproducible evaluation benchmarks.
Separation of Concerns
By decoupling prompt definition (creation) from prompt consumption (retrieval and rendering), teams can update prompts without redeploying application code. The prompt management system acts as an intermediary that isolates the authoring workflow from the serving workflow.
Pseudocode
The conceptual flow of prompt creation can be expressed as:
function create_prompt(name, template, model_name, model_provider, options):
version = build_prompt_version(template, model_name, model_provider, options)
if prompt_exists(name):
append_version(name, version)
else:
register_new_prompt(name, version)
return version_with_server_id