2 posts tagged with "prompt-management"

The first edit to a shared system prompt feels like good engineering. Three teams all paste the same eighteen-line safety preamble at the top of their agents, someone notices, and an internal platform team says the obvious thing: let's centralize it. A prompts.common.safety_preamble@v1 lands in a registry. Thirty teams adopt it within a quarter because it's the path of least resistance — and because security is happy that one team owns the wording. For two quarters, this looks like a clean DRY win.

Then the security team needs a small wording change. Maybe a new compliance regulation tightens what an assistant is allowed to volunteer about a user's account. Maybe a red-team finding requires a one-sentence addition to the refusal clause. The platform team makes the edit, ships v2, and within a day the support queue fills with messages from consumer teams: our eval dropped, our format broke, our tool-call rate halved, our tone changed, our latency went up because the model started reasoning more. Each team wants the edit reverted. The security team needs it shipped. Nobody can roll forward without a re-eval, and nobody owns the re-eval. Welcome to the shared-prompt flag day.

A one-sentence change to a system prompt sat in production for 21 days before anyone noticed it was misclassifying thousands of mortgage documents. The estimated cost: $340,000 in operational inefficiency and SLA breaches. Nobody could say who made the change, when it was made, or why. The prompt lived in an environment variable that three teams had write access to, and no one considered it their responsibility to review.

This is the prompt ownership problem. As LLM-powered features proliferate across organizations, prompts have become the most consequential yet least governed artifacts in the stack. They control model behavior, shape user experience, enforce safety constraints, and define business logic — yet most teams manage them with less rigor than they'd apply to a CSS change.