Maintaining AI agents after the builder moves on

An account research agent can spread as colleagues share it and other regions start using it before customer calls. If the builder moves to another role, those users still need someone to fix it when it goes wrong. The original builder may know the tool best, but supporting it now takes time away from their new role. Their manager needs to agree to that work, or someone else needs to take it over.

A seller questioning a brief needs help from someone who can check both the data and the recommendation. That person needs access to the relevant systems and time to investigate. They also need to be able to stop the tool from issuing recommendations if they find a serious problem. Keeping the builder's name on a support page doesn't tell users whether any of that is still possible.

Investigating a misleading account brief

Suppose a contract moves to a new subsidiary record in the CRM. An agent might report falling revenue because it compares the old record with a period when the revenue sits elsewhere. The query can run without errors, and the brief can cite the CRM, while giving the seller the wrong impression. Someone familiar with the account hierarchy needs to explain how the records changed before a developer can fix the comparison.

After fixing it, the team should add that example to the tests so a later model or prompt change doesn't bring the mistake back. They also need to check where the brief was used. If another agent used it to recommend a change in account coverage, correcting the original brief may leave that recommendation in place. Seeing the same claim in several tools could make it seem well supported even when all of them copied it from the same source.

Taking over a tool another team built

Before another team starts depending on the agent, its manager should agree who will handle problems like this. The adopting team might maintain it itself or pay another team to do so. Either way, someone needs time to learn the code, understand the tests and work through questions with the original builder. Users should know where to report a problem and what support is available after the handoff.

The amount of support depends partly on what the agent is allowed to do. When only one seller sees a draft, the owner can contact that person to correct a mistake. An answer saved to the CRM may already have been used by several other tools. If the agent can approve a discount, its owner also needs to understand the pricing rules and know how to respond when it approves something it shouldn't. Shared help with testing and releases could make it easier for local builders to support their tools. I worry that leaving them to work this out alone will lead to failures that prompt the company to require approval for every small experiment.

The person taking over also needs a list of the teams using the agent, including those running their own copies. Another region may have copied an older version, so switching off the original won't stop everyone from using it. Before retiring the tool, its owner needs to contact those teams and help them move their work.