Quick answerCan the pre-approved range itself be widened later without a full compliance resignoff? No; widening the range is itself a human-initiated change to the agent's governance parameters and should trigger the same material-change compliance resignoff process as any other deliberate change, even though the day-to-day adjustments inside the range do not. What kinds of parameters are reasonable candidates for self-adjustment at all? Favor parameters with a clear, measurable, low-stakes signal driving the adjustment (a confidence threshold tuned against a stable accuracy metric) and avoid self-adjustment for parameters tied directly to money, safety, or legal exposure, where the cost of an unreviewed drift is highest.
Quick answer
Define the pre-approved range explicitly and narrowly before deployment, not as a vague "reasonable adjustment" concept, log every self-adjustment the agent makes within that range with the specific before and after values, and set a rolling review cadence where a human checks the cumulative drift of self-adjustments over time, not just each individual change in isolation. A single adjustment staying inside the approved band can still be a governance problem if a string of small adjustments compounds into a materially different operating posture nobody explicitly signed off on.
This is a different question than the human-initiated material-change threshold
What counts as a material change that requires re-running your AI agent's compliance sign-off sets the bar for when a human-initiated change (a new model version, a rewritten system prompt, a new tool integration) needs a fresh compliance review before shipping. This post covers a fundamentally different situation: a change the agent makes to itself, autonomously, without any human initiating it at all, within a range your company decided in advance was safe to leave unsupervised. The two thresholds should not be assumed to be the same number, since a self-initiated adjustment inside a pre-approved band carries a different risk profile than a human deciding to ship something new.
This is also different from the shipping mechanics of a human-initiated change
How to version and roll back AI agent prompts safely in production covers the deployment mechanics once a human has decided to change something: staged rollout, rollback triggers, version history. Self-adjustment within a pre-approved range is not a deployment event in that sense at all; there is no human decision moment to roll back to, which is exactly why it needs its own distinct oversight design rather than borrowing the human-initiated change process wholesale.
Define the range as specific numeric or categorical bounds, not a vibe
"The agent can adjust its escalation threshold within reason" is not a governable range; "the agent can adjust its escalation confidence threshold between 0.72 and 0.85, and nothing else, under any circumstance" is. Every parameter eligible for self-adjustment needs an explicit, written upper and lower bound decided by a human before deployment, with any adjustment outside that literal range treated as a hard stop requiring human authorization, not a soft guideline the agent can reason its way past in an unusual case.
Watch for compounding drift, not just single-adjustment compliance
A single self-adjustment landing inside the approved range is easy to verify automatically; a sequence of small, individually-compliant adjustments that cumulatively move the agent's behavior close to one edge of the range, or that oscillate in a pattern suggesting the underlying signal driving the adjustments is unstable, is a different and easier-to-miss problem. Build a rolling review, weekly or monthly depending on adjustment frequency, where a human looks at the trend line of self-adjustments over time, similar in spirit to how a canary rollout is monitored for drift even though no human initiated any single step.
What triggers pulling a parameter out of the self-adjustment pool entirely
If the cumulative-drift review or an incident investigation shows a specific parameter's self-adjustment behavior is not actually staying safely inside its intended range in practice, or is producing outcomes nobody anticipated when the range was originally set, the correct response is removing that specific parameter from the self-adjustment pool and reverting it to human-initiated-only changes, not simply narrowing the numeric range and leaving self-adjustment enabled. A parameter that already proved hard to bound safely once is a poor candidate for a second, tighter attempt at unsupervised self-adjustment.