Model and agent change management
Decide which changes require reassessment and what evidence should travel with them
When changes to models, prompts, tools, or data alter agent behaviour, this area becomes relevant. For the AI platform release and governance owner, the concern is specific: a prompt or retrieval update bypasses review because it is not treated as software change. The governance implementation design starts from that consequence and follows the relevant evidence through the customer workflow. Change management should follow behavioural dependencies. The proposed method should identify material configuration changes even when no application code changes, and should preserve the configuration to which prior evidence applied.
Connect the operating question to inspectable evidence
- AI platform release and governance owner
- Owns the bounded decision and the consequence of acting.
- Component and configuration inventory
- Defines the starting context for the proposed work.
- Impact classification
- Exposes the first material uncertainty to examine.
- Approval and rollback workflow
- Carries unresolved conditions into an accountable next action.
Decision at stake
Decide which changes require reassessment and what evidence should travel with them
Make the decision explicit
- AI platform release and governance owner
- Changes to models, prompts, tools, or data alter agent behaviour.
- Decision
- Which changes require reassessment and what evidence should travel with them.
- Impact classification
- Use component and configuration inventory to establish the relevant starting condition.
For the AI platform release and governance owner, this becomes relevant when changes to models, prompts, tools, or data alter agent behaviour. The immediate decision is which changes require reassessment and what evidence should travel with them. The scope should be narrow enough that the governance owners can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that a prompt or retrieval update bypasses review because it is not treated as software change. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Coverage
Examine impact classification alongside regression evidence
Keep the review distinctions visible
- Impact classification
- Classify the changed behaviour and authority, not just the edited component.
- Regression evidence
- Rerun requirements affected by the specific configuration change.
- Approval validity
- Bind approval to the candidate that is deployed and its rollback route.
Impact classification
For this scope, impact classification should be examined alongside component and configuration inventory. Classify changes by their possible effect on behaviour and control boundaries. Prompts, memory rules, retrieval sources, tools, and model configuration may all matter. The process should identify which changes can use existing evidence and which need new review without assuming that only application code is consequential.
Regression evidence
For this scope, regression evidence should be examined alongside change categories. Require evidence appropriate to the changed assumptions and affected workflows. A broad regression suite may be useful, but the proposed process should also include targeted cases for the specific change. Combined changes need care when they prevent the team from explaining the cause of a new failure.
Approval validity
For this scope, approval validity should be examined alongside release and rollback process. Preserve the approval conditions, release configuration, and rollback or recovery route. A previous approval should not automatically cover expanded authority. The decision record should state what was accepted and what would reopen review, while leaving release and residual-risk authority with the customer.
Prerequisites
Start with component and configuration inventory
Give each input a specific job
- Component and configuration inventory
- Defines the operating boundary.
- Change categories
- Examine regression evidence.
- Release and rollback process
- Shows conditions affecting approval validity.
- Policy or risk owner
- Confirm access and a reviewer who can resolve gaps.
The starting material is component and configuration inventory, change categories, and release and rollback process. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include an accountable policy or risk owner, relevant system owners, and qualified legal or domain reviewers when interpretation is needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Follow the requirement into an accountable operating practice
Follow the evidence through the work
- Impact classification
Use component and configuration inventory to define the decision criteria.
- Regression evidence
Inspect change categories and retain observations that challenge the expected result.
- Approval validity
Use release and rollback process to identify unresolved conditions and a responsible owner.
- Approval and rollback workflow
Link the recommendation to its evidence, remaining limits and next validation condition.
Create change categories based on possible behavioural effects rather than repository location. A modified tool description, new retrieval corpus, or altered memory policy may warrant review even without code changes. The proposed process should also handle combined changes whose interaction prevents a simple attribution of observed regressions.
A practical first slice would focus on impact classification and then follow its consequences into regression evidence. Keep approval validity visible as a separate review question rather than assuming it is satisfied by the first result. The governance owners should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefacts
Use approval and rollback workflow to make the next action explicit
Every artefact needs an operating use
Illustrative working format
- Agent change policy
- Boundary — component and configuration inventory.
- Impact and evidence checklist
- Findings about regression evidence.
- Approval and rollback workflow
- Action on approval validity.
Indicative outputs include agent change policy, impact and evidence checklist, and approval and rollback workflow. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Two simultaneous changes: narrow or retest
Examine the constructed decision boundary
Illustrative scenario
- Two simultaneous changes
A release replaces the model and alters tool descriptions.
- Separate comparisons
Inspect each changed assumption before judging the combined candidate.
- Narrow or retest
If interactions remain unresolved, narrow release or collect evidence instead of inheriting approval.
Consider an illustrative situation in which a team replaces a model and changes tool descriptions in the same release. This is a constructed example, not a client engagement or an observed Softlander outcome.
For the simultaneous model and tool-description update, an illustrative review could recommend separate comparisons before approving the combined release. The evidence pack would identify configuration versions, changed assumptions, and unresolved findings. The owner should be able to choose a narrower release or additional testing rather than inherit approval from the previous system.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves approval validity unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and authority
Governance evidence supports decisions within defined professional limits
Keep analytical work separate from decision authority
- Operating requirements and evidence mapping
- Can include agent change policy.
- Policy or risk owner
- Authorised policy owners decide; qualified specialists interpret professional requirements.
- Legal conclusions and certification decisions
- Cannot be inferred from impact and evidence checklist.
This work supports governance preparation and operating evidence. It does not provide legal advice, determine regulatory compliance, award certification, or replace a formal audit. Authorised customer owners retain policy, release, and residual-risk decisions.
Ways to engage
Related engagement scopes
AI Privacy Engineering Review
Trace personal data through your agent workflow. Examine collection, memory, retrieval, tool access and retention against your agreed requirements.
AI Governance Operating System
Make AI oversight part of daily operations. Connect inventories, accountable owners, change decisions and evidence into a workable governance process.
Continue exploring
Related insights and resources
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Protecting agent data and memory
An agent's information footprint extends beyond the conversation. Map the copies, derived records and retrieval paths that influence future actions, then connect each to purpose, access, retention and verifiable handling.
AI agents in legal operations: assistance without invented authority
Legal agents can organize evidence and prepare work, but professional judgement, client authority and verified legal positions cannot be delegated by interface.