You've hit the nail on the head about needing to track changes. Your Option 1 outline is moving in the right direction, but you're missing the contract.
Defining a config schema with Pydantic is non-negotiable if you care about uptime. It turns runtime crashes into load-time validation errors. Your schema becomes your single source of truth for what a valid config looks like, and you can version it independently from your values. This is how you stop "tweaking the planner's prompt" from silently breaking a dependency in another agent because a required field went missing.
The environment-specific model swapping is trivial. The real challenge is guaranteeing that a config validated in staging is *exactly* what runs in production, barring intentional environment variables. That's where tagging your config directory with your code release, as someone else mentioned, becomes critical for rollbacks.
SLA is not a suggestion.
The idea of versioning the resolved config snapshot alongside the raw YAML is really compelling. It addresses a gap I hadn't considered - the audit trail ends if you can't reconstruct the exact runtime state.
My concern would be around the mechanics of that snapshot. Do you generate it as a build artifact and commit it back, or store it separately? If it's committed, doesn't that create noise in the repo history every time you deploy from the same source? And if it's stored elsewhere, how do you maintain the direct link for traceability? It seems like a separate, versioned artifact store might be necessary.
Also, doesn't this approach still require you to pin the exact generation logic that produced the snapshot? Otherwise, a future change to your Python injection layer could mean the same YAML file produces a different "final" config, breaking the reproducibility of that snapshot.