How to Request and Approve Changes to a Managed AI Agent

To request a change to a managed AI agent, write it as a short, specific request that names the problem, the behavior you want and how you will know it worked. The provider then reviews the impact, tests the change against agreed examples, and releases it with a named approver and a way to roll back. Use the same loop for every change, small or large, and improvements stay controlled and traceable.

Key takeaways

• Route every change through one door, with one written request and one record, instead of chat messages and hallway asks.
• A good request states the problem, a real example, the desired behavior, what must not change and a success check.
• Sort changes by risk. Wording tweaks need light approval. New tools, wider permissions and sensitive data need a named approver and a staged release.
• Test against a fixed set of reference cases before and after, so you see what the change did and what it broke.
• Keep a change log and a rollback point. If you cannot say what changed last week, you cannot run the agent responsibly.

Why do changes to an AI agent need their own process?

An AI agent is not a single setting. Its behavior comes from instructions, knowledge sources, tools, permissions, channels and the model underneath. A small edit to any of these can alter results somewhere you were not looking. A friendlier tone can make the agent over-apologize. A new document in the knowledge base can contradict an older one. A new tool can open an action nobody planned for.

The common failure is informal. Someone asks for an adjustment in a chat thread, someone applies it, and a month later the team notices the agent behaves differently without anyone knowing why. Nobody is careless here. The company simply never agreed on how change happens.

A lightweight process fixes this. It has one entry point, one classification step, one test, one approval and one record. It should feel closer to a short form than to a committee. The goal is not to slow improvement. The goal is to make each improvement something you can explain, repeat and undo. For the wider picture of what happens once an agent is live, see how to update an AI agent in production without breaking it.

What belongs in a change request?

The quality of the request decides most of the outcome. Vague requests produce vague changes, and vague changes are hard to test. A request does not need to be long, but it needs these parts:

• The problem or goal, in one sentence.
• A real example of current behavior: the input the agent received and what it produced, with sensitive details removed.
• The behavior you want, ideally with an example of a good result.
• What must not change, such as tone with key customers, a required disclaimer or an escalation rule.
• The area you think is affected: instructions, knowledge, tools, permissions or channel. A guess is fine, the provider will confirm.
• The requester and the business owner who will judge the result.
• Urgency, with the reason for it.
• A success check: how you will know in practice that the change worked.

Compare two requests. The first says: make the agent better at replying to customers. The second says: when a customer asks about delivery, the agent currently states a date that the team has not confirmed. Replace that with a message saying the team will confirm the date, and keep answering normally when the customer supplies a date. Success means a reviewer finds no unconfirmed dates in a sample of recent drafts.

The second request can be tested, approved and rolled back. The first one can only be argued about.

Who reviews and who approves, and how much review is enough?

Not every change deserves the same scrutiny. Treating a wording tweak like a permission change wastes time, and treating a permission change like a wording tweak creates risk. Sort requests into tiers and agree in advance who signs off on each. This is a decision guide you can adapt:

• Low risk: wording, tone, formatting, corrections to existing knowledge content. The agent owner approves after a check against reference cases. Released in the regular window.
• Medium risk: a new knowledge source, a new routine task, a changed escalation rule, a new channel, any change to customer-facing messages. The agent owner and the relevant department lead approve. The provider reviews what data the change touches.
• High risk: a new tool, any action that writes or sends, wider permissions, access to sensitive data, a change of model or provider. The agent owner plus IT, security or legal as relevant must approve. A permission review is part of the work, and release is staged to a small group first.
• Urgent restriction: stopping or limiting behavior right now, such as disabling a tool that is misbehaving. Any authorized person can request it and the provider acts immediately. The review happens afterward and is recorded.

Two rules keep this honest. First, when the tier is unclear, choose the higher one. Second, narrowing what the agent can do is usually safer and faster than widening it, so treat expansions with more care than restrictions.

Write the approvers down. A short responsibility table helps, and a RACI for company AI agents shows how to assign who is responsible, accountable, consulted and informed. For anything that widens access, follow the steps in how to run a permission review for your AI agents. Authorization guidance such as the OWASP Authorization Cheat Sheet supports the same principle: grant the least access needed and review it when it changes.

How should a change be tested before it goes live?

Testing a change means comparing the agent before and after on the same inputs. The tool for this is a set of reference cases: real or realistic tasks, each with a description of what a good result looks like. Start small. A modest set that covers your main tasks is more useful than a large set nobody maintains.

A useful reference set includes four kinds of case:

• Typical tasks the agent handles every day.
• Difficult tasks where it has failed before.
• Boundary cases where it should refuse, ask for help or escalate to a person.
• Cases unrelated to the change, included to catch side effects.

Run the set before the change to get a baseline, and again after. Have a person who knows the work review the differences, since not every difference is a regression and not every pass is a real success. Where an outcome is clearly checkable, such as a required phrase or a forbidden action, automated checks save effort. Published guidance on agent evaluation, such as Anthropic's overview of evals for AI agents, makes the same point: grade what you can with clear rules, and use human judgment for the rest.

Every fix adds to the set. When a mistake reaches a user, turn it into a reference case so the same mistake is caught next time. Over months, the reference set becomes a record of what your company expects from the agent. The same set also helps when you define what a pilot must prove, as covered in how to define success criteria for an AI agent pilot.

What does the flow look like from request to release?

Here is a step-by-step plan that works for most companies. It can run through a shared form, a ticket queue or a dedicated channel, as long as it is one place.

• Step one, submit: the requester fills in the request with the parts listed above and sends it to the single agreed channel.
• Step two, triage: the provider confirms receipt, asks clarifying questions and assigns a risk tier. The requester is told the tier and who will approve.
• Step three, impact check: the provider lists which instructions, knowledge, tools and permissions the change touches and which users or teams will notice it.
• Step four, build in a copy: the change is made in a separate working version, never directly on the live agent.
• Step five, test: the reference cases run before and after. Results, including anything that got worse, are written down.
• Step six, approve: the named approver for the tier reads the request, the impact and the test evidence, then approves, requests rework or declines with a reason.
• Step seven, release: the change goes live with a saved rollback point. High-risk changes go to a small group first and widen only after review.
• Step eight, observe and close: for an agreed period, the team watches for problems and checks the success measure. Then the request is closed in the log.

The change log is the lasting product of this flow. Each entry should hold what changed, why, who requested it, who approved it, when it was released, what the tests showed and where the rollback point is. Observability practices, such as those described in the OpenTelemetry primer, are useful here too: a change is easier to judge when you can see the agent's behavior before and after it.

Declined and deferred requests belong in the log as well. A request that was reasonable but postponed, with the reason, saves the next person from asking again blindly.

What does this look like in practice? An illustrative scenario

This scenario is illustrative, not a real case. A services firm uses an agent to draft replies to customer inquiries. The support lead notices that drafts sometimes promise delivery dates the team has not confirmed. She submits a request with two example drafts, the desired wording and a success check: a reviewer should find no unconfirmed dates in a sample of recent drafts.

The provider triages it as medium risk, because the change affects customer-facing messages. The operations manager is named as co-approver. The change is made in a working copy and run against the reference cases. One result is unexpected: the agent now also avoids repeating dates that customers give in their own messages, which is not what the team wants. The instruction is narrowed and the cases run again.

The operations manager reviews the evidence and approves. The change goes live for a single inbox first, with a rollback point saved. After the observation period, the support lead confirms the success check, and the entry is closed in the log with the test results attached.

Nothing in this story is complicated. Each step simply leaves evidence, which is what makes later questions easy to answer.

How does Be Human handle change requests in a managed setup?

In a managed engagement, Be Human takes change requests through one agreed channel, assigns a risk tier with the client's named approvers, and builds the change in a separate working version rather than on the live agent. The change is checked against reference cases, released with a rollback point after sign-off, and recorded in a log the client can read. Changes that widen access follow a permission review, and permissions remain under the client's control throughout. Controlled improvements are one part of the recurring work described in what managed AI services include.

Frequently asked questions

Who in our company should be allowed to submit change requests? Anyone who uses the agent can describe a problem, but it helps to have one or two named requesters, usually the agent owner and department leads. They turn raw feedback from the team into complete requests. This keeps the queue clear and prevents conflicting asks from reaching the provider.

What if a change is urgent and we cannot wait for the full flow? Use the urgent restriction path: any authorized person can ask to stop or limit a behavior, and the provider acts at once. Write the request and complete the review afterward. Urgent expansions of capability should still go through the normal tier, because speed is a poor reason to widen access.

What if a change makes things worse after release? Use the saved rollback point to return to the previous version, then record what happened and add the failing case to the reference set. Rolling back first and investigating second keeps users safe. The same request can be reopened with the new evidence.

Do changes the provider makes on its own, such as a model update, need approval too? Yes. Provider-side changes can alter behavior just as much as your own requests, so they should be announced, classified into a tier and tested against the same reference cases. If your agreement does not say how this works, ask for it to be written down, for example in the statement of work.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.