> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Prompt template lifecycle: concept > How a system prompt moves from the shared template library through assisted authoring and grounding instrumentation to a gated promotion review — and which prompt version an agent is actually running in production. # Prompt template lifecycle A prompt on a production agent is one version, chosen deliberately, frozen at promote time. The **prompt template lifecycle** is the five-step path that version takes: author it, ground it, get it approved, promote it, then watch what it does in run time. Until that last step, "which prompt does this agent run?" has no safe answer — the runtime only ever reads one approved, immutable prompt version. This page frames the whole lifecycle at the concept level. The hands-on walkthroughs live in the [Prompt Template Library guide](/agents/prompt-templates), the [grounding citations audit](/agents/grounding-citations), and the [version + promotion reference](/agents/agent-versions). ## 1. Authoring: start, rewrite, or port Three paths put a draft prompt on an agent. All of them end the same way — plain `system_prompt` text on the agent, saved as a new immutable version. * **The shared template library** — a centrally curated, centrally versioned catalog of starter prompts (support triage, inbound sales, scheduling, reminder outreach, tier-1 technical support, post-interaction surveys). You browse it, fill its `{{variables}}`, and fork a chosen version; the resolved text becomes your agent's prompt and stops depending on the catalog after that. Because updates append new versions instead of rewriting old ones, a fork pinned to version `1.1.0` keeps resolving the exact body you tested even after the catalog ships `1.2.0` — that pin is the first line of lineage in the promotion review below. * **AI-assisted rewriting** — the wizard's rewrite action takes your own draft prompt and returns an LLM-improved version for the agent type you picked. It never edits your prompt behind your back; it suggests an alternative you accept, reject, or keep iterating on. * **Porting an existing prompt** — contact-center operators often already have proven IVR and queue announcement text. The reuse direction runs those stock announcement lines *into* the agent prompt authoring flow as starting text — tested phrasing instead of a blank page. Whichever path started the prompt, the moment you save it the agent holds plain text. A forked template reads exactly like a hand-written one; the lineage only lives on as the audit record of which template version produced it. ## 2. Grounding: what production answers actually stand on Before a version can earn promotion, the question that matters is not "does the prompt read well?" — it is "will the answers it produces stand on retrieved knowledge?" Two instrumentation layers measure that side of the prompt: * **Per-turn grounding record** — every completed turn records the knowledge chunks retrieval found, which of them the model actually cited inline, the retrieval confidence, and the tools it called. A per-trial verdict (`ok`, `no_marker`, `orphan_marker`, `empty_retrieval`) grades whether a grounded answer stood on knowledge, slipped through uncited, or cited nothing that retrieval returned. * **The prompt-versions page points you at it** — the candidate version's runs carry exactly this record, so a promotion reviewer counts grounded versus ungrounded turns for the version under review rather than eyeballing prompt prose. High-trust agents can go further and refuse an uncited answer entirely. The [grounding citations page](/agents/grounding-citations) covers the full verdict vocabulary. Up through promotion this answers "grounded or not"; after a version goes live, the same catalog flips to *regression* mode — if grounding drifts on the running version, the monitor pages on the drop before a customer does. ## 3. Promotion: the approval gate between reviewers Promoting a version — the step that makes it the prompt an agent speaks in production — can pass through an optional **approval gate** that enforces separation of duties: when the gate is on, a request to promote is reviewed by *someone other than the operator who authored the version. An approver without authorship on the candidate* lane must then accept it. Two deliberate exceptions keep the org-level opt-in posture conservative: * An **opt-in, not a default** — an org that never enables the gate promotes versions exactly as before, so existing runbooks are untouched. * **No attributable author means no gate to fail** — versions minted automatically or carried over from pre-gating installs have no recorded author. Self-approval cannot be proven there, so the gate passes them and the audit trail still records who promoted. Where the gate fires, a self-approval attempt is rejected, and the accepted promotion names both the author and the approver in the agent's version history. The gate binds into the same promotion call either endpoint (`promote`, or the `prompt-rollback` alias) drives, so the two surfaces cannot drift apart on whether self-approval was checked. ### What a reviewer is gating against Approval is the human half; the safety half runs before the reviewer ever sees the candidate. The **regression gates** — the eval-suite correctness gate and the red-team safety gate — block a candidate that regresses your pinned safety or quality baseline, and the guardrail stack (sensitive-topic filters, PII redaction, output enforcement) constrains every turn the candidate runs in review. None of that is advisory prose: a gated regression fails the promotion outright, and the reviewer reads only candidates that already passed it. [Red-team safety gate](/agents/red-team) and [guardrail effectiveness](/agents/guardrail-effectiveness) carry the details. ## 4. Model lifecycle ties: presets hand the prompt a runtime A prompt version never runs in isolation — it pairs with the model the agent runs it on. **Model presets** bundle STT + LLM + TTS choices into one named stack (Balanced, High Intelligence, Ultra Fast, Cost Saver) with latency and cost estimates, and promote/rollback re-freezes the prompt, the model, and the temperature together. Approving a prompt change therefore also locks the preset at that corner of the version, so a reviewer reads "which prompt, on which model stack" as one unit rather than two moving targets. Re-forking a template gives you prompt text only — the preset stays the agent's call. ## 5. Cross-links: audit surfaces around the lifecycle The promotion step decides; the audit layer keeps the whole loop honest: * **[AI-disclosure ledger](/concepts/ai-disclosure-ledger)** — the tenant's signed provenance export of which agent spoke, under which model, when. Approval gates decide *which* version runs; the ledger proves *what* ran. * **[Guardrail event stream](/agents/guardrail-effectiveness)** — per-turn guardrail evaluations layered on top of the approved prompt. The concept pages differ on purpose: one asks "which prompt is live?" the other asks "which guardrail fired on this turn?". * **[Agent versions and rollbacks](/agents/agent-versions)** — the full version-history surface the lifecycle lands on once promotion finishes. ## Which prompt is in production? Read it at the agent's version history. The production version — the one the runtime serves — is the last version that either passed the approval gate (when the org enables it) or was promoted directly, whichever your deployment uses. Everything the lifecycle contributes converges on that single, immutable answer.