AI Agent Change Control Process: 7 Steps for Safe Updates

What is an AI agent change control process?

Drawing on Midpoint’s AI Agent Change Management: Release Control Guide, an AI agent change control process is a documented workflow for proposing, testing, approving, deploying, monitoring, and reversing changes to an agent’s behavior or access. Review effort should match the risk. Connect the approved configuration to its permitted scope, evidence, decision owners, and recovery instructions.

This is production release control, not an employee adoption program. Teaching staff to use an assistant and authorizing that assistant to access payroll are different decisions. Keep them separate. Require explicit approval before turning a demonstration into production access.

What changes belong in agent change control?

Midpoint’s release-control guide includes any modification that can alter an agent’s decisions, access, external actions, supporting evidence, or user experience. Application code is only part of that boundary. Model settings, prompts, tools, permissions, knowledge sources, memory, workflow logic, evaluators, and escalation paths all count. Define the affected release unit before anyone starts editing.

Midpoint notes that a stable model can behave differently when its tools or retrieval sources change. For example, replacing an expense policy can change answers without a prompt edit. Expanding a permission changes the access boundary even when answers look identical. Include an agent access control checklist in the review rather than limiting it to code.

Approve the configuration that will run, not just the code that will ship.

How does the seven-step change control process work?

Register the change, classify risk, assemble a versioned manifest, test separately, obtain approval, deploy within scope, and monitor with recovery instructions ready. These seven steps are a practical synthesis of Midpoint’s release-control guidance and Sendbird’s governance controls, not an externally mandated standard. Keep the sequence consistent; scale the review effort to what the agent can affect.

1. Register the change and release unit. Name the owner, intended outcome, current configuration, and affected agent or workflow. Write down both what changes and what must stay unchanged. Updating expense-policy retrieval, for example, must not silently expand reimbursement approval authority. Assign a release ID and carry it through testing, approval, deployment, and recovery records.
2. Classify risk before implementation. Choose the standard, normal, or emergency path before building. Examine access, sensitive data, money, legal commitments, and autonomy. Use an AI agent risk assessment to identify the business owners who need to participate. A small implementation is not necessarily a low-risk change. Classify the consequences, not the editing effort.
3. Assemble the release manifest. Record component versions, permissions, affected routes, test plan, rollout scope, and rollback target. Give the manifest a revision. If someone changes a prompt, permission, or knowledge source after review, revise the manifest and decide which tests and approvals must run again. Do not approve a moving target.
4. Test in a separate development environment. Compare the candidate with the current release using normal cases, boundary cases, forbidden actions, and escalation cases. Check the complete workflow, not just whether an answer sounds right. Use an agent acceptance testing checklist to connect each requirement to evidence and an acceptance decision. Keep failures and exceptions visible to reviewers.
5. Obtain appropriate review and approval. Have someone other than the implementer assess release safety. Include the relevant risk owner when the change affects their area. Attach approval to the release ID and manifest revision, with conditions, expiration, permitted scope, and excluded routes. “Looks good” in a chat thread is not a usable definition of production authority.
6. Deploy only within the approved scope. Compare the deployment candidate with the approved manifest before promotion. Restrict production access, preserve unchanged components, and start with the authorized users or routes. Stop at the approved boundary. An initial pilot decision does not authorize every later rollout stage, even when the pilot appears to be working.
7. Monitor and preserve recovery evidence. Connect the deployed configuration, test results, decisions, rollout observations, and recovery instructions to the release ID. Assign an incident owner and explicit stop conditions. Close the change only after checking the approved scope and recording the outcome. Carry unresolved exceptions and follow-up work into the record rather than losing them at closure.

What belongs in an agent release manifest?

Midpoint describes the release manifest as the bridge between human approval and the deployed configuration. Record exactly what reviewers are approving and operators are deploying: component versions, affected users and routes, risk classification, test evidence, approval conditions, rollout stages, and recovery instructions. Attach its revision to every release decision so an approval cannot drift onto a different configuration.

Use the completed example below as a starting point. It is hypothetical: the identifiers, versions, and decisions illustrate the record, not a deployed system or a reported test result.

Never put “latest” in a version field. Record a snapshot, revision, or configuration export that someone can retrieve. Name the selected knowledge-source version, not just its folder. If a source updates continuously, document how updates happen and where the controls apply. Otherwise, reviewers can mistake approval of a changing source for approval of fixed content.

When should a change be standard, normal, or emergency?

Following the risk-classification approach in Midpoint’s release-control guidance, use standard changes for previously approved, repeatable patterns within defined boundaries. Normal changes need fresh assessment; emergency changes address urgent containment or restoration. Classify by consequences and context, not how quickly someone can make the edit. An emergency can compress the sequence, but ownership and records still have to survive it.

A short prompt edit can change a contractual answer. A familiar tool can acquire write access. Neither qualifies as standard merely because the team has made similar edits before. Set eligibility rules before release work starts. Midpoint explicitly calls for recording emergency rationale, the decision owner, and evidence as soon as the system is safe. Urgency is a reason to shorten the path, not erase it.

Who should approve an AI agent update?

Midpoint says the person changing a configuration should not be the only person deciding whether it is safe to release. Use the responsibility model below to apply that separation: the change owner prepares the request, a technical reviewer examines differences and evidence, and affected risk owners approve business consequences. The release operator promotes the approved configuration, and an incident owner handles failures. Combine roles for low-risk work where appropriate, but retain a separate release-safety reviewer.

In a smaller company, an operations lead can own the request and operate the release while a separate reviewer checks it. Record those combined responsibilities and any exceptions. Bring in Finance for spending authority, the data owner for sensitive-source access, and the relevant legal reviewer for commitments. A meeting invitation does not give someone decision authority.

How do you deploy, monitor, and reverse an update?

Sendbird’s agentic AI governance overview describes development–production separation, role-based access, configuration histories, rollback, and selective deployment. Combine those controls with Midpoint’s requirement for approval tied to a precise version and scope. Monitor against recorded acceptance criteria, keep a known rollback target, and plan containment and reconciliation alongside restoration.

Keep the rollout inside the approved boundary

Use separate environments, role-based access, configuration histories, and selective deployment to keep unrelated work out of a release. A knowledge-source update must not carry an unfinished tool change into production. Compare the candidate with the manifest, including settings and permissions outside the main application repository. Those controls count even when they live elsewhere.

Monitor the behavior that changed

For retrieval updates, inspect source selection and whether sources support the answers. Permission updates need checks on attempted and completed actions; routing changes need checks on destinations and escalations. Set acceptance and stop conditions before deployment. Connect observations to the release ID, and use agent monitoring to track those process-specific signals instead of relying on a generic success score.

Restore configuration and address the consequences

Treat configuration restoration and consequence management as separate recovery tasks. Alongside the rollback target, document how to suspend affected actions, preserve evidence, identify the exposure window, and reconcile changed records. Put these tasks in the agent incident response plan, and verify the restored configuration before reopening the route.

How Cogniver helps control agent update approvals

Cogniver gives release reviews a defined approval path. Build branching, merging, and multi-step approval chains in its visual workflow builder. Require document uploads before an approval proceeds, putting the release manifest and evaluation evidence in the request instead of leaving reviewers to find them across messages.

Each workflow gets its own AI agent, trained by organization admins on that workflow’s rules and configuration. It answers questions, routes requests, and chases approvers, with conversation memory isolated across workflows and companies. Groups and grades from the shared org chart drive approver resolution, so review routing uses the company’s structure.

Use an AI Router for conditional reviews. It sends each request down exactly one branch using exact amount rules or an AI-applied plain-language policy. A mandatory default branch gives uncertain requests a defined destination rather than leaving them stuck. Approvers can enter verified values during review, and later routing can use those values.

Cogniver Standard costs USD $39 per user per month. Enterprise is a separate pricing tier.