Prompt Management
Treat prompts as versioned configuration: separate them from code, store in a registry with performance metadata, A/B test changes, and roll back instantly when a prompt change degrades quality.
Quick Reference
- →Prompt as config: prompts should be deployable independently from code — no code deploy to change a prompt
- →Prompt registry: versioned storage with author, description, eval results, and production performance metrics
- →A/B testing: route traffic to prompt variants, measure quality, promote the winner automatically
- →Rollback: instant revert to the previous prompt version when quality drops — under 60 seconds
- →Templates: parameterized prompts with typed variables for reusable, testable prompt components
Prompts as Configuration, Not Code
In a production agent, the prompt changes 5-10x more frequently than the code. Embedding prompts in source code means every prompt tweak requires a full CI/CD cycle: PR, review, build, deploy. Separating prompts from code lets you iterate in minutes instead of hours.
| Approach | Deploy Speed | Version Control | Rollback Speed | Best For |
|---|---|---|---|---|
| Hardcoded in source | Hours (full CI/CD) | Git history | Minutes (redeploy) | Early prototyping only |
| Environment variables | Minutes (config change) | None built-in | Minutes | Simple, single-prompt agents |
| Prompt registry (DB) | Seconds (API call) | Full versioning + metadata | Seconds | Production multi-prompt agents |
| Feature flag platform | Seconds (flag toggle) | Platform-dependent | Seconds | A/B testing prompts at scale |
A prompt registry stores prompts as versioned configuration objects, similar to how a model registry stores model versions. Each prompt version has metadata (author, description, creation date), linked eval results, and production performance metrics. The agent fetches the active prompt version at runtime, enabling instant updates without code changes.