An adoption project goes well. The consultants or the internal project team configure the AI agent, set what it may do, connect it to the systems it needs and train the first users. The project closes. Usage grows.

Six months later, someone asks why the agent is allowed to update a particular record, or why it needs access to a particular system. Nobody in the business can say. The person who knew has moved on, and the decision lives in a slide deck, a ticket or their memory. The rules still work. Nobody owns them.

Why handover is where control is lost

During a project, decisions about an agent's authority are made deliberately, with context. After handover, three things tend to happen:

  • Ownership is assumed rather than assigned. The business owns the workflow, IT owns the platform, and nobody explicitly owns the agent's permissions.
  • Rationale is not recorded with the rule. The setting survives; the reason for it does not.
  • Changes get harder, not easier. Without the rationale, people are reluctant to tighten a permission in case something breaks, and quick to widen one when something does.

A managed IT provider commenting on a LinkedIn post about this suggested a practical test: give the handover material to a colleague who missed the launch, and see whether they can explain and safely change what the agent is allowed to do. Another commenter, who runs a cybersecurity business, made the related point that high adoption means little if one owner remains a single point of failure.

The control question

Ask: if the person who set this up left today, could someone else explain and change what the agent may do, and show what it has done?

In an agent workflow, that means:

  1. Rules are explicit and owned. What the agent may do, and which actions need approval, are written as rules with a named owner, not left as configuration only one person understands.
  2. Each decision shows which way it went and why. When the agent acts, the record shows the result and the reason, so a new owner can see how the rules behave in practice.
  3. Change is controlled. Changing what the agent may do is itself a decision with an owner, not an informal edit.

What IntelXview's AI Control Plane does here

For actions routed through it, IntelXview's AI Control Plane (ACP) checks each request against the policy the agent has been given and records the decision. A paid proof of concept can test a handover on one agreed workflow:

  • Authority: the agent's permitted actions are defined as policy, not left implicit.
  • Evidence: each allowed, refused or approved action leaves a record a new owner can inspect. Our decision evidence example and signed evidence pack show what those records look like and how to check them.
  • Handover test: with the policy and the decision records in hand, can someone who was not on the project explain why an action was allowed or refused?

ACP controls only activity routed through it, and it does not replace the people who own the workflow. A proof of concept usually begins with a controlled demonstration on synthetic data; installation and integration in your environment are separate stages.

Where this comes from

This topic came from two company-page posts in October 2026 about adoption that has to survive the consultant leaving. The substantive replies came from delivery and security providers, some of whom may become partners. That shows the theme resonates with providers; it is not, on its own, evidence of what end buyers want.

Next step

If you are handing over, or have inherited, an AI agent whose rules nobody can explain, book a free scoping call to test it on one workflow. If you deliver AI adoption projects for clients, book a partner call to talk through how a handover test could fit your delivery. See what a PoC includes or how partner work is organised.