An agent version is useful only when it identifies the entire releasable behavior, its parent, its evidence, and the environment that resolved to it.
Capture content and relationships
Store the release identifier, parent version, component identifiers or digests, creation time, author, change reason, and target environment. Prompts may be inline in a protected store while code, tool schemas, and policy files point to immutable repository commits. Retrieval configuration should name the collection or index revision and its build receipt rather than a mutable display name.
A version record should be append-only after publication. Corrections create a new candidate linked to the prior record. This preserves the state that actually ran and prevents a later edit from rewriting incident evidence. NIST's Secure Software Development Framework recommends preserving release files and supporting provenance so software can be acquired, deployed, and maintained with integrity.
Keep secrets and personal data outside the record
Store secret names, credential owners, and rotation references, not raw values. Avoid copying production conversations or customer payloads into release notes. Test fixtures should be synthetic or explicitly approved and carry their own retention rule. If a provider response contains sensitive data, preserve a redacted assertion and a protected receipt location rather than widening access through the version system.
The record should also identify external dependencies that cannot be frozen, such as a hosted model alias or provider-managed retrieval service. State the observed provider version or response metadata when available and label the remaining uncertainty. Immutability of the local record does not make an external service immutable, but it makes that dependency visible during comparison and incident review.
Connect versions to decisions and evidence
Link each version to the diff from its parent, completed task tests, failures, accepted exceptions, approver, publish event, deployment receipt, verification result, and rollback target. Environment labels remain mutable pointers with their own history. That distinction lets production move back to a prior immutable version without editing either record or pretending the reverted release never happened.
Release Rail implements the schema through Reality Contact, LLC. The buyer decides which components must be captured, who may approve a release, how long records remain, and which data can enter test evidence. The ledger supports reproducibility and accountability; it is not a certification that the agent is safe, compliant, correct, or suitable for every decision.
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: NIST Secure Software Development Framework version 1.1; LangSmith prompt commit and environment-tag documentation.