The AI Agent Outlasts Its Creator

Consider an accounts-payable analyst who builds an artificial intelligence agent to sort incoming invoices. The software reads a shared mailbox, extracts the details from attachments and compares them with purchase orders. It sends discrepancies to a colleague for review. It cannot approve a payment, but it can determine which invoices reach the people who do.

At first, the analyst checks its work every morning. Over time, colleagues stop opening the mailbox and start working from the queue the agent prepares. By the time the analyst takes a job elsewhere, the software is part of the department’s routine.

On Friday, the company closes the analyst’s account. On Monday, the department still has invoices to process.

What happens next depends on how the agent was built. A connection tied to the analyst’s account might fail. An agent with its own credentials might continue working, even if no one is watching for errors. The software might still read new invoices but lose access to the system it uses to check them. To a colleague looking at a shorter queue, that last failure could resemble a quiet morning.

The example is hypothetical. The underlying problem is familiar from earlier generations of office automation. AI gives it a new form: a tool an employee can build for a narrow task can acquire access to several systems and a role in deciding what happens next. The company may come to rely on it before anyone has agreed to look after it.

The experiment that became a dependency

Businesses have long depended on spreadsheets, scripts and database queries built by the people closest to the work. That is often sensible. The analyst who handles invoices knows which suppliers use several names, which discrepancies can wait and which require a phone call. A central technology team may have the resources to build a sturdier system, but it would first have to learn how the department actually works.

An AI agent can put that local knowledge to use. In the invoice example, the analyst might instruct the software to recognize that a supplier’s trading name differs from its legal name, or to send an invoice for review when an amount appears to include a charge absent from the purchase order. Those instructions can make the tool useful long before the department has formally agreed how every exception should be handled.

That convenience can obscure a change in the way the business operates. While the analyst is double-checking every result, an error is one more thing to catch during a morning review. Once the rest of the team stops reading the mailbox, the same error can determine whether anyone sees an invoice at all. The software may have received no new permissions. What changed was the work people stopped doing around it.

A launch date is therefore a poor guide to when an experiment becomes important. A better clue is what colleagues would have to start doing again if it disappeared. If the answer is that someone would have to reopen the mailbox and reconstruct several days of work, the department has acquired a dependency. It may still be listed as a pilot.

The owner in the directory

The mechanics of a departure are already visible in conventional workflow software. Microsoft’s documentation for Power Automate explains that a shared workflow can continue after its creator leaves if an active owner remains. Individual steps can still fail, however, if they use connections belonging to the departed employee. Someone may be able to edit the workflow without being able to make every part of it run.

Microsoft’s Entra Agent ID documentation separates two roles. A technical owner administers an agent’s identity. A business sponsor is accountable for its purpose and for decisions about its access and continued use. The company also describes automatic reassignment of sponsorship to the sponsor’s manager when the sponsor leaves. These are distinct products and controls, but the distinction they illustrate is useful: keeping a name attached to a piece of software and keeping its connections working are separate jobs.

Neither settles what the agent ought to do. In the invoice example, an administrator could restore a connection to the purchasing system. The department still has to decide whether the agent should see every purchase order or only those needed to process its invoices. The analyst’s manager might know why the agent was created but have no idea why it treats invoices from one supplier differently.

A sponsor can give the company someone to call. A handover has to give that person enough information to make a decision.

What the successor inherits

Some of the work is ordinary maintenance. Someone must be able to see what the agent ran, repair its connections and receive an alert when it fails. An alert sent to a former employee’s inbox is of little use. So is a log that records a successful run when the department needs to know whether every invoice that arrived was accounted for.

Other work involves reconstructing decisions. Suppose the successor finds an instruction telling the agent to route a certain supplier’s invoices directly to a specialist. It could reflect a standing agreement. It could be a workaround introduced during a billing dispute that ended months ago. The instruction alone cannot tell the successor which. Changing it might eliminate unnecessary work or remove a control the department still needs.

The same problem arises when the company changes its own rules. If finance introduces a new approval threshold, the policy can be distributed to staff and the payment system can be updated. Someone must also check the agent’s instructions and the routes it uses to send invoices for review. A workflow can continue operating as designed after the assumptions behind that design have expired.

One useful handover would let a successor follow an ordinary invoice and an exception from the original message to their final destinations. It would show what the software can read, what it can change and what it leaves to a person. More importantly, it would explain why the exceptions exist. The point is to give the next person enough understanding to recognize when the agent is doing the wrong thing for a reason that once made sense.

That understanding has a cost. The business has to make time for someone to review exceptions, test changes and investigate odd results. Those obligations compete with other work. A department that counts the hours its analyst saved but assigns no time to the people who inherit the system has accounted for only one side of the arrangement.

When the safest choice is to stop

Sometimes the right decision will be to turn an agent off. A temporary tool may have outlived the problem it was built to solve. A new application may already do the same work. An agent may save time on ordinary cases while demanding too much attention on the exceptions. A credible owner needs the authority to weigh those facts and stop the software when it no longer earns its place.

Stopping is harder once the old process has faded. If the invoice agent is suspended, someone must still collect new invoices, find the ones it has already handled and identify the ones it left midway through the process. A department that restarts manual processing without knowing where the agent stopped can miss an invoice or enter one twice. An administrator’s ability to withdraw access is useful; a department’s ability to carry on afterward is what makes that option practical.

There is a trade-off in keeping a fallback. Maintaining a parallel process indefinitely can eat into the benefit of automation. For a tool that prepares an internal summary, the sensible fallback may be to go without it for a day. For a workflow that helps determine whether suppliers are paid on time, it may be worth rehearsing how staff would resume the work. The amount of preparation should follow the consequences of failure, rather than the novelty of the technology.

The same judgment applies to experiments. Requiring an elaborate succession plan for every personal assistant would slow the people most likely to find useful applications. The moment to ask for more is when other people depend on the output or the software gains the ability to make changes that are difficult to unwind. At that point, the business is making a decision about how it will operate, even if the decision is never put to a committee.

What the company agreed to keep

Employee departures offer a clear occasion to review these arrangements. A change in duties can matter just as much. An analyst transferred to another division may retain access and still know how the agent works, while no longer having the time or authority to maintain it. A reorganization can leave the software doing the same job for a department whose budget, policies and reporting lines have changed around it.

The practical question for management is who can make the next decision. A technology team may be able to fix a broken connection, but the business team has to judge whether the process is still useful. The business team may want to retain it, but that decision means setting aside time to support it. If the only person who can explain the workflow is its creator, the work of transferring ownership starts before that person’s last day.

The clearest test is to ask what would happen on an ordinary morning if the creator were unavailable. Could someone tell whether the work was complete? Could that person explain why an invoice was held back and correct a bad decision? Could the department carry on if the agent had to be suspended? The answers reveal how much of the process the company has actually taken on.

Back in accounts payable, Monday’s test is simple. The invoices must reach the right people, and someone must notice if they do not. The employee who built the agent has left. Whether the company can keep relying on it depends on what it agreed to take responsibility for while that employee was still there.