Agent Operations

The Five Lifecycle Events That Decide Whether Your AI Agents Survive

Ryan Carmichael

Managing Partner, Orienteer AI

Every AI agent in production passes through the same five trigger events on the way to either becoming part of how the business runs or quietly turning into shadow infrastructure. The events themselves aren't optional. What's optional — and what determines which side of that line your fleet ends up on — is whether each event fires a deliberate response, or fires nothing at all.

The thing nobody is watching

Walk into a company that's been shipping AI agents for eighteen months and ask one question: what happens to your agents when the person who built them leaves the company? The honest answer, almost always, is nothing. HR offboards the human. The agent keeps running. The first time anyone notices it's unowned is the day it breaks — usually in front of a customer, sometimes in front of a regulator.

This isn't a failure of the agent. It's a failure of the workflow surrounding the agent. The same company has a thirty-step process for offboarding an employee. It has zero steps for offboarding the things the employee built. So the agents accumulate, the ownership decays, and the institutional knowledge required to operate them walks out the door on people's last day.

The fix is unglamorous: five lifecycle events, each with a defined response, each wired into the systems where the trigger actually originates. That's the whole discipline. Get the triggers right and most of the other AI governance debates become small.

The five events

For each event, two columns: what should happen in a company that operates its agent fleet with discipline, and what usually happens in one that doesn't. The gap between those two columns is the size of your operational risk.

Event 1

Agent built and deployed

The first time the agent runs against real data or a real workflow — not a sandbox.

Should:: The agent gets a registry entry the day it ships: name, scope, data sources, decision authority, system it touches. A named business owner is assigned and signs off in writing. The builder is recorded but isn't the owner of record.
Usually:: The agent goes live because it works. Nothing gets documented. The only person who knows it exists is the engineer who built it, and the only place its scope is written down is the Python file containing the system prompt.

Event 2

Builder transferred to a new team

The engineer who shipped the agent moves to a different team, a different product, or a different reporting line.

Should:: The transfer fires a review. Business ownership is re-confirmed or reassigned, the registry is updated, and the new builder-of-record is introduced to the agent in writing. If no successor builder exists, that fact is logged — not papered over.
Usually:: The transfer happens in HR. Nothing fires for the agent. The original builder remains the de-facto fix-it person, taking pings about a system that's no longer in their job description. Nobody picks it up because nobody knows they were supposed to.

Event 3

Builder leaves the company

The engineer who built and maintained the agent resigns, is laid off, or otherwise becomes unreachable.

Should:: Offboarding the human fires an offboarding workflow for every agent they built. Each one gets a decision: transfer ownership to a named successor, formally decommission, or accept the agent into Agent Ops' inventory. Knowledge capture happens before the builder is gone, not after.
Usually:: HR offboards the human on a Friday. Their laptop is wiped. The agent keeps running on Monday with no owner. The first time anyone notices is when it breaks — six months later — and there is nobody left who knows how it works.

Event 4

Agent breaks or drifts

Accuracy degrades, error rate climbs, latency breaches threshold, or the agent starts producing outputs nobody can defend.

Should:: Monitoring catches it. The named owner is paged. A fix is dispatched against a defined runbook. The incident is logged, the root cause captured, and the lesson feeds back into the next agent's onboarding checklist.
Usually:: A customer surfaces the failure. Or an auditor does. By the time it reaches anyone with authority to fix it, the agent has been wrong for weeks. The conversation is about damage control, not engineering — because no engineer has been assigned to the agent in months.

Event 5

Agent becomes obsolete

The workflow it supports changes, the data source it depends on goes away, or a better alternative exists.

Should:: A formal decommission process fires: revoke permissions, archive logs and decision history, capture lessons learned, communicate to downstream users, mark the registry entry archived (not deleted). The retirement is dated and signed off.
Usually:: The agent keeps running because no one is empowered to turn it off. Its cost is small enough to escape the budget review. It becomes a piece of background noise nobody questions — until it's the answer to the question 'how did we miss this?'

Why each event needs a system, not a memo

The reason “what should happen” almost never happens is that each of these events fires somewhere that has nothing to do with the AI team. Builder transfers live in JIRA reassignments and Slack channel changes. Builder departures live in Workday. Drift lives in the monitoring stack. Obsolescence lives in a quarterly business review nobody invited the agent to.

A governance memo telling people to “remember to update the agent registry when someone leaves” will not survive contact with a Friday afternoon offboarding meeting. The triggers have to be wired into the systems where the events actually originate — HRIS, ticketing, monitoring, the quarterly planning cycle — so the response is the path of least resistance, not an additional task someone has to remember.

This is operations, not policy. The companies doing this well aren't the ones with the best-written AI strategy. They're the ones whose offboarding checklist now includes a line item that says “list every agent this person built and assign each one a new owner” — and whose HR coordinator can't close the ticket until that field is filled in.

Shadow infrastructure or governed fleet

The cumulative effect of getting these five events right isn't glamorous. It's a list of agents you can defend in front of an auditor, a registry where every entry has a living human owner, and an offboarding process that doesn't leave a trail of orphan systems on every employee's last day.

The cumulative effect of getting them wrong is the state most enterprise AI footprints are already in: nobody can produce an accurate count of production agents, nobody can name the owner of half of them, and the cost of getting the answer right grows every quarter the discipline isn't installed.

The first step is the registry. The second step is wiring these five triggers into it. Everything else is downstream.

Keep going

The Agent Operating Model

Six disciplines for running an agent fleet in production — the framework these lifecycle events sit inside.

Read the model

Talk to us

If you're looking at the agents you have today and wondering which of these triggers are wired up and which aren't, let's have a conversation.

Get in touch