liveBook · Manning

Prompt management

As explained in Prompt Engineering in Practice

A system for managing prompts across their production lifecycle, including collaboration, governance, and lifecycle visibility.

Prompt management treats prompts as production artifacts rather than strings to write once and forget. A prompt needs an owner, a version history, and a safe way to change it. Without those records, teams may struggle to identify which version is live or what changed before an incident. section 11.0

Use a lifecycle that makes each change traceable:

  • Draft and document the prompt, then test it before review. section 11.0
  • Approve and promote a version through a defined path to production, recording who approved it and why. section 11.2.7
  • Observe deployed behavior, improve prompts that need attention, and retire prompts that are no longer needed. section 11.0

A dedicated prompt management system (PMS) gives this workflow a shared interface, not merely a place to store prompts. Typical capabilities include visual editing, API or SDK retrieval of approved versions, role-based access, separate development, staging, and production versions, diffs, and approval records. It can also keep model-specific variants of one logical prompt and test them against the same inputs. Choose a platform by the capabilities needed, not by a product name. section 11.2.7

A production fix without provenance

A developer corrects a production prompt directly, bypassing draft and approval. The correction works, but a later incident review finds a live version with no reviewer, approval, or change summary. The team must reconstruct what changed before it can judge whether that version caused the problem. A PMS makes the missing record visible; it does not enforce good process by itself. section 11.2.8

Table 11.3 Audit log entries for two versions of the same prompt

Field

Version 7 (properly promoted)

Version 8 (bypassed)

version

7

8

drafted_by

alex.chen

—

reviewed_by

david.okafor

—

review_note

“Confirmed scope matches updated policy”

—

approved_at

2024-09-12 14:32

—

promoted_at

2024-09-12 16:05

2024-09-26 09:47

promoted_by

alex.chen

maya.patel

change_summary

“Restricted to billing queries only”

—

Compare the approved and bypassed audit-log entries to see which provenance fields make a production change easier to investigate. section 11.2.8

How Prompt Engineering in Practice covers it

How deep it goes
Details lifecycle steps, PMS capabilities, and audit gaps; leaves deployment pipelines and telemetry backends outside scope.
Examples
Contrasts audit-log entries for a properly promoted prompt and a direct production edit investigated after an incident.
What it assumes
Assumes familiarity with prompt templates and constrained prompts before addressing their maintenance in production.
What you can do after
Practice/perform it by assessing maturity, moving prompts through a lifecycle, and using process signals to prioritize improvements.
How it connects
Connects prompt templates with version history, role-based access control, approval workflows, audit logs, and multimodel variants.

Also explained in

Compare how 4 books explain prompt management →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Prompt Engineering in Practice. The section links point to the parts of the book it draws on.