What belongs in an agent release besides the container image?

A healthy rollout can leave behavior unidentified

The deploy system knows an image digest. The application also loads a prompt from a configuration service, selects a model through a mutable route, and asks a registry which tools are available. A task’s behavior depends on all of them. Reverting the image cannot reconstruct the earlier behavior if those other inputs changed without retained revisions.

Kubernetes Deployments track changes to the Pod template. That mechanism does not automatically turn externally edited prompts or retrieval settings into an application release. The platform must define and enforce its own release boundary.

Resolve a manifest into usable assets

A list of version names is useful only when a worker can retrieve the corresponding bytes or establish the relevant service contract. Before accepting work, resolve the manifest against the asset registry, verify digests where available, check access, and determine whether the worker supports its state schema.

Distinguish three outcomes: fully resolved, explicitly dynamic, and invalid. An intentionally dynamic evidence source may be acceptable with a captured query and observation time. A missing prompt revision is invalid. Treating both as “use latest” destroys the distinction the manifest was meant to preserve.

One image, two ticket-writing behaviors

In a hypothetical deployment, build 42 runs for a week. On Tuesday, an administrator changes a tool description from “prepare a ticket draft” to “submit the ticket.” On Wednesday, an incident review finds different outcomes from tasks that report the same image.

A complete release record assigns Tuesday’s change a new identity, retains the prior tool definition, and shows which tasks received each revision. It does not imply that a description alone may authorize submission. The tool’s actual effect contract and permission enforcement must still agree with the published revision.

Copy the release resolution ledger

Use this ledger in a release review; values below describe fields to fill, not a provider-neutral executable schema.

Asset	Required identity	Resolution check	Dynamic limit to disclose
Worker executable	Image digest and source revision	Registry object exists; provenance verifies	Runtime or host dependencies
Instructions	Content digest and template revision	Rendered template inputs accounted for	User input remains variable
Model configuration	Provider, model reference, route, parameters	Route resolves to intended deployment	Provider may change an alias
Tool contract	Server revision and schema/behavior record	Expected implementation available	Unversioned downstream behavior
Policy	Bundle revision and decision interface	Enforcement service accepts bundle	Authority still checked when required
Retrieval	Index build and retrieval configuration	Index and transformations identifiable	Live sources and freshness
State and evidence	Reader/writer compatibility and gate record	Candidate supports active state versions	Environment cannot always be replayed

Assign one release identifier to the completed ledger and record it at task acceptance. Sensitive credentials should be referenced through their governed identity, never copied into this artifact.

Make resolution failure visible before admission

Introduce an admission check that reports missing or mismatched assets with a stable reason. Keep known-good capacity available while a candidate cannot resolve its inputs. A worker becoming ready proves only its configured readiness check; include release resolution in that check when it is a prerequisite for serving work.

Record the resolved manifest in a durable location. Later incident analysis should not depend on the current registry still mapping a name to its earlier contents. SLSA provenance helps trace artifact origin; the broader behavior ledger here is an author-created extension for application attribution.

Connect the manifest to evidence without inventing a score

Attach the evaluation evidence identifier and its evaluated manifest. Reject a candidate whose evidence describes different controlled assets unless the difference has an explicit reviewed disposition. This article does not select task portfolios or pass thresholds: the evaluation release gate owns that decision.

For environment-level reproducibility, record fixtures and dependency behavior using the reproducible agent test environment. Release packaging and experiment reconstruction are connected but distinct tasks.

Attribution survives where exact replay does not

An external model revision may disappear, or a live search result may no longer exist. Preserve the observed revision metadata and authorized evidence available at execution, then state the gap. A manifest is valuable when it shows the limits precisely. Continue with active-task revision rollout or the full deployment method in AI Agent Platform Engineering.