A controlled agent release begins when draft is a real state, publish is an explicit event, and production resolves only to an accepted immutable version.
Define the complete behavior-bearing object
List every component that can change observed behavior: system and task prompts, examples, tool names and schemas, model and parameters, retrieval sources, routing rules, safety policies, memory configuration, code adapters, and dependency versions. A prompt version alone is incomplete when the deployed tool schema or retrieval collection changed at the same time.
Give the assembled definition one immutable release identifier. Store references or digests for components that must remain elsewhere, and record who assembled the candidate, from which prior version, for which environment, and why. Sensitive text stays in the approved private store. The release record needs enough information to reconstruct the state without exposing secrets in logs or public interfaces.
Make draft and publish different operations
Editing a draft should create recoverable history without changing the production pointer. Publishing should require a named candidate, completed checks, an authorized person, release notes, and a recorded change to the environment label. If the platform autosaves, place a controlled configuration or deployment layer between its mutable workspace and the definition production resolves.
Portkey documents separate update and publish behavior, immutable versions, version history, restoration, and labels for prompt management. LangSmith documents commit history, diffs, tags for environments, and rollback. These provider features demonstrate established release concepts. The implementation still needs to cover every behavior-bearing component and the buyer's actual runtime, not only the prompt text.
Verify what production resolved
After publication, query or inspect the runtime and record the release identifier, environment label, deployment result, and smoke-test output. A successful API response from the deployment command does not prove that the serving path loaded the intended definition. Verification should reach the same path customers use with approved synthetic or test data and preserve a correlation identifier.
Release Rail installs this workflow through Reality Contact, LLC. The buyer controls production credentials, release authority, product policy, and final publication. The release record establishes which candidate was deployed and checked at a named time; it does not guarantee that an agent will behave identically across all inputs, model-provider changes, or untested downstream conditions.
Where the service stops
Reality Contact, LLC installs and tests release controls but does not certify agent safety, guarantee behavioral consistency, decide product policy, approve production releases, operate incidents indefinitely, or assume authority over customer data, credentials, model choices, or consequential agent actions. The buyer names release and rollback authorities, approves the version schema and top tasks, controls production credentials, decides whether each candidate is published, and can require repair or restoration after reviewing the evidence. This release-engineering service does not replace the buyer's product, security, legal, privacy, model-risk, or production-readiness review. The buyer controls production credentials and decides whether to publish, repair, hold, or restore every release.
Sources: Portkey documentation for prompt versioning; LangSmith documentation for managing prompts.