Separate definition versions from runs

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Two jobs reuse reviewed configuration. The teaching host supports immutable agent-a v3 and distinct run IDs with explicit version references. Latest-only or untracked per-job definitions obscure what actually ran.

Mechanism

Persist definition identity/version at setup, then create r1/r2 pinned to v3. Record runtime input/permitted overrides separately rather than mutating shared config. After v4, retain old bindings and record new selection. Verify real host version semantics.

Bad example

Create an untracked definition for every job, reference latest and omit which version/overrides actually ran.

Good example

Under the teaching contract persist agent-a v3; launch distinct r1/r2 referencing it with task inputs/overrides recorded. A v4 update does not rewrite old v3 bindings. Select/record versions for new runs. Unsupported pinning remains an explicit capability gap with actual config snapshots, not a false fixed-version claim.

Why the change matters

Definitions represent reusable config; runs represent executions. Separation preserves history through evolution and makes per-run variation inspectable rather than replacing every job with current latest.

Observable expectation

An illustrative inventory has r1/r2→v3 and r3→v4, with overrides separate. Inspect definition changes versus run state and preserved old records.

A version field alone does not prove enforcement; require actual read/run-config evidence. No real agent is created.

Limits

Pinned definitions do not freeze tools, credentials, data or environment. Frozen endpoints/CLI patterns are instances, not universal current contracts. Verify supported version/override semantics.