When you change an agent, record the change and test the behavior it could affect before expanding use. Changes to instructions, approved sources, tools, models, access, or where the agent runs can alter the workflow. For each material change, name an owner and decide how to recover if it fails.
Update one equipment-support workflow
The service team uses an agent to compare equipment repair requests with the approved repair policy and asset record, then prepare a response draft for a technician. A revised policy now requires a condition photo before the agent may recommend repair. The agent can read the request, policy, and asset record and prepare a draft, but it cannot approve or schedule the repair.
In this fictional test, the team checks four requests: one with the required photo, one without it, one whose asset record conflicts with the request, and one outside the repair scope. The updated version cites the photo, asks for the missing photo, routes the conflict to a technician, and declines to recommend an out-of-scope repair. The completed change record is:
Repair guidance update — release decision
- Version:
repair workflow v4 → v5(illustrative configuration labels).- Change: Replace the prior repair-policy version with the approved revision.
- Behavior changed: Require a condition photo before recommending repair; request it when missing, route conflicting asset data to a technician, and refuse out-of-scope repairs.
- Owner: Service process owner; policy owner confirms the source is current.
- Approver: Service process owner accepts the test evidence after the policy owner confirms the source.
- Affected checks: Photo present, photo missing, conflicting asset data, and out-of-scope repair.
- Review result: All four cases returned the expected response, including the out-of-scope refusal; no repair was approved or scheduled.
- Recovery: Revert the technical configuration only if it still meets the current policy. Otherwise pause the agent workflow and route requests to a technician applying the current requirements.
- Decision: Release the revised policy to the existing pilot group; review new exceptions before expanding.
This sample records a decision for an invented scenario. In a real change, the team must confirm which source the agent reads and base release on its own test evidence.
Reassess limits and quality after a material change.
Keep a small versioned change record
For each change, capture:
Scroll horizontally to see all columns.
| Field | What to record |
|---|---|
| Change identity | Agent or workflow, configuration version, date, and person proposing the change. |
| Reason and owner | The need being addressed, process owner, and any source or system owner who must approve it. |
| Approval | Approver by role, evidence reviewed, decision, and date. |
| Affected parts | Instructions, knowledge sources, tools, model, audience, permissions, deployment, or review steps that changed. |
| Expected effect | The behavior expected to change and the behavior that must remain within its existing boundary. |
| Evidence | Cases run before and after, observed differences, reviewer corrections, unresolved limits, and release decision. |
| Recovery | A fallback configuration checked against current policy, owner for disabling or reverting, and how affected work will be handled. |
Match review effort to the effect of the change. A typo that cannot alter task meaning may need a light check. A new data source, action, user group, model, or policy rule may change exposure or outcomes and needs a more deliberate review. Follow the organization’s required security, privacy, legal, or subject-matter process where it applies.
Retest the cases connected to the change
- Preserve a baseline. Keep representative cases and expected outcomes from the current workflow, including exceptions and boundary checks.
- Identify affected behavior. Map the change to the source, instructions, tool, or decision step that uses it. Add cases for new or changed requirements.
- Compare results. Run the same relevant cases against the prior and proposed configuration. Review output, source use, tool activity, and handoffs; do not rely only on fluent wording.
- Release in a bounded scope. Name who accepts the evidence, which users receive the change, and what signal will trigger a pause or rollback.
- Check operation afterward. Review representative live work and exceptions, then update the record with the decision and any follow-up.
For the repair-policy change, test a request with all required evidence, one missing it, one with a conflicting asset record, and an unrelated request. The technician should see which policy and record supported the draft. If the change weakens that evidence or crosses the workflow boundary, pause use while the owner investigates unless a fallback configuration has been verified against the current requirements. A technical rollback does not authorize restoring a superseded business policy.
Review the operating record with the team governance checklist, agent evaluation guide, and observability guide.