Protocol
Detect configuration drift instead of assuming sameness
'Same deployment' does not guarantee the same state.
When it fits
- Multiple instances, environments or agents are supposed to run the same configuration.
When to avoid it
- Not all divergence is drift; legitimate canaries and experiments need explicit identities so monitoring does not 'repair' them away.
Why it matters
Regularly compare the effective configuration of peers that are expected to match. Flag differences against the approved version and classify them as planned experiment, staged rollout or unintended drift. Correlate behavior anomalies with version differences before treating them as random noise.
Steps
- Define which instances or environments are expected to match.
- Collect the effective configuration version or fingerprint.
- Compare against the approved target and rollout plan.
- Classify differences as intentional or unintended.
- Remediate unintended drift and preserve evidence of the divergence.
An example
If one agent instance produces different tool behavior, check whether its policy or model configuration differs before debugging the prompt text alone.
Check your result
Unexpected behavior can be tested against an objective configuration difference rather than relying on deployment assumptions.
Keep this limit in mind
- Not all divergence is drift; legitimate canaries and experiments need explicit identities so monitoring does not 'repair' them away.
Connected ideas
Useful withStart with what changed, not with certainty about it
Evidence and sources
Current AWS Agentic AI guidance recommends detecting configuration drift across running instances and correlating behavior with configuration versions.
Not every difference is harmful drift; approved experiments and staged rollouts must remain distinguishable from unintended divergence.
AGENTREL08-BP01 Establish consistent configuration management practices · Drift detection