Microsoft rolled out automatic Entra Agent IDs. Gartner projects the average global Fortune 500 enterprise will run over 150,000 agents by 2028, up from fewer than 15 in 2025. And only 13% of organizations believe they have the right AI agent governance in place. Those three facts, taken together, explain why every CIO conversation about agents now starts with the same question: we have the register, now what?

Our last Industry Insight argued that building a tenant-wide agent register is the first governance move every enterprise should make. It still is. But a register is an inventory. An inventory is not a lifecycle. The organizations that will absorb a 10,000-fold expansion in agent counts without accumulating audit, cost, and security debt are the ones treating AI agent lifecycle management as a continuous operating discipline, not a one-time deployment review.

This article lays out the five-stage operating model, the stage specs, the RACI, the maturity rubric, the retirement runbook, and the 90-day roadmap. If you have a register, this is what comes next.

TL;DR

AI agent lifecycle management is the operating discipline that governs every agent from design through retirement, with explicit gates, owners, and artifacts at each stage. Having an agent register tells you what exists. A lifecycle tells you how to govern it. The organizations that get this right in 2026 will not spend 2028 cleaning up orphaned agents the way IT spent the 2010s cleaning up orphaned service accounts.

Key Takeaways

A register is a static artifact. A lifecycle is a continuous operating model. Treat them as sequential disciplines, not substitutes.

Five stages, four gates. Design, Build, Deploy, Operate, Retire. Each stage has entry criteria, required artifacts, an owner, a decision gate, and exit criteria.

Retirement is the differentiating stage. Every competing framework names it. Almost no enterprise operationalizes it. Retirement cadence is the leading indicator of CoE maturity.

ALM is an operating discipline, not a product category. Tools help. They do not replace governance.

The economic driver is now on the invoice. Microsoft Copilot Credits turn every unretired agent into a measurable P&L line.

A 90-day roadmap is realistic for any organization that already has a register in place.

Why Having a Register Is Not Having a Lifecycle

The register answers one question: what agents exist in our tenant, who owns them, and what data do they touch. That is the right first question. It is not the last.

The questions a register cannot answer are the ones auditors, CFOs, and CISOs actually ask. Who approved this agent's business case? What evaluation did it pass before it reached production? When was its owner last confirmed? What triggers its retirement? Who revoked its credentials when its business purpose ended? None of those answers live in an inventory. They live in a lifecycle.

This is familiar territory. IT learned the same lesson with service accounts in the 2010s. An inventory of service accounts, even a good one, did not prevent the orphaned-account problem that defined the next decade of IAM remediation. Only lifecycle discipline did. AI agents are reproducing that pattern, faster, and with the added twist that agents take autonomous action. The window to prevent orphaned-agent debt is open now and narrower than most IT leaders think.

The Five-Stage Agent Lifecycle Operating Model

Competing frameworks converge on the same operational truth. Microsoft's Copilot Studio guidance hub organizes around five stages: Plan, Implement, Manage, Improve, Extend. AvePoint's model uses six: Assign Owner, Provision, Deploy, Monitor, Recertify, Retire. Both are useful. Neither is the operating-level abstraction a CIO can draw on a whiteboard.

The BabyBots model collapses the shared logic into five stages a steering committee can memorize: Design, Build, Deploy, Operate, Retire. Four gates sit between them. Every stage has an owner, an artifact, and an exit criterion. The retirement stage is terminal and produces its own audit artifact.

Stage 1: Design

Entry criteria: A business sponsor and a documented problem statement.

Required artifact: Agent charter covering business case, intended users, data scope, decision authority, and risk tier.

Owner: Business sponsor, co-signed by CoE lead.

Decision gate: Business Case Approved. The agent cannot be built until the charter is signed and the risk tier is set, per our risk-tiered LLM deployment framework.

Exit criteria: Charter approved, risk tier assigned, grounding sources identified, HITL requirements specified.

Most common failure mode: Skipping the charter and starting in the maker studio. The agent exists before the business case does, and nobody can later explain why it was built.

Stage 2: Build

Entry criteria: Approved charter from Design.

Required artifact: Build record capturing grounding sources, tools and connectors, prompts, HITL checkpoints, and test results.

Owner: Maker, under CoE build standards.

Decision gate: Deployment Readiness. Includes grounding validation, prompt-injection testing, HITL design review, and evaluation against the acceptance test set.

Exit criteria: All build artifacts complete, security review signed, grounding source choice justified against our knowledge grounding framework.

Most common failure mode: Treating prompt engineering as the whole build. Grounding, HITL, and evaluation are not optional.

Stage 3: Deploy

Entry criteria: Deployment Readiness gate passed.

Required artifact: Deployment record with environment, Entra Agent ID, permission scope, cost tier, and rollback plan.

Owner: Platform admin, with security sign-off for high-risk tiers.

Decision gate: Production Acceptance. Business sponsor signs that the agent meets charter intent in a controlled release.

Exit criteria: Agent registered, permissions provisioned at least-privilege, cost tier applied, observability instrumented.

Most common failure mode: Over-provisioning permissions during pilot and never reducing them before scale.

Stage 4: Operate

Entry criteria: Production Acceptance gate passed.

Required artifacts: Observability telemetry, incident log, model-update change record, recertification record.

Owner: Business sponsor for recertification, platform admin for telemetry, security for incident response.

Decision gate: Recertification Pass, run on a scheduled cadence (quarterly for high-risk tiers, semi-annually otherwise).

Exit criteria: Recertification passed, or agent routed to Retire.

Most common failure mode: Treating observability as monitoring. It is also change control. Our Observability CIO Playbook argues observability is the third leg of the AI operating model. ALM is where that leg carries weight.

Operate is also where change control for model updates lives. Microsoft's own guidance is explicit: "Upgrading to every new model risks silent regressions. Avoiding all model changes guarantees an emergency when a retirement arrives." Treat model updates as release events, not background changes.

Stage 5: Retire

Entry criteria: Failed recertification, superseded capability, or business owner departure without reassignment.

Required artifact: Retirement record with decommission timestamp, credential rotation log, access revocation log, archived telemetry, and reusable-asset catalog entry.

Owner: CoE lead, executed by platform admin and security.

Decision gate: None. Retirement is terminal, but it is a controlled process, not a deletion.

Exit criteria: Audit evidence package complete, register updated, portfolio metrics refreshed.

Most common failure mode: Deleting instead of retiring. The agent disappears from the maker studio. Its credentials, permissions, and telemetry do not.

Your retirement cadence, not your deployment velocity, is the leading indicator of your agent portfolio health.

Retirement: The Stage Nobody Operationalizes

Every lifecycle framework names retirement. Almost none specify what it means to execute it. That gap is where orphaned agents live, and it is the single sharpest ownable discipline in enterprise agent governance today.

Retirement is not deletion. Deletion removes the agent from the maker studio. Retirement is the complete process around that removal: a controlled sequence that revokes access, rotates credentials, archives telemetry, and preserves audit evidence. Skipping it is worse than skipping any other stage, because an unretired agent is not just unreviewed. It is actively still running, with credentials that were never rotated and permissions that were never revoked, indefinitely.

The decommissioning runbook has a specific order. Reversing it creates the exact exposure retirement is meant to close.

Step 1: Freeze the agent. Pause invocations without deleting the registration. If an incident surfaces, the agent is recoverable for forensic review.

Step 2: Notify stakeholders. Business sponsor, downstream integrators, and any humans in the loop receive formal retirement notice with a cutover date.

Step 3: Export telemetry and audit history. Archive invocation logs, evaluation records, model-update history, and recertification records to retention storage per policy.

Step 4: Revoke downstream access. Remove the agent's permissions from every connected system in order: data sources first, then tools, then outbound connectors. This order prevents the agent from attempting partial writes to systems it can no longer read.

Step 5: Rotate credentials. Rotate any API keys, service principals, or managed identities the agent held. Rotation, not deletion. If a credential was shared, deletion breaks other services. Rotation forces the shared users to surface.

Step 6: Harvest reusable assets. Catalog prompts, tool definitions, grounding configurations, and evaluation sets that other agents can inherit. Retirement without harvest leaves institutional learning on the floor.

Step 7: Deregister. Remove the Entra Agent ID binding, update the register, and close the lifecycle record.

Step 8: Record the audit artifact. A retirement attestation signed by the CoE lead, containing the full chain of custody.

Enterprises that run this sequence will discover something uncomfortable in their first wave: a non-trivial share of their inventoried agents cannot be cleanly retired because nobody can confirm who the current owner is, what the original business case was, or which downstream systems depend on it. That discovery is the point. It is cheaper to find it during a planned retirement than during an incident.

The Retirement Cadence Index: A Portfolio-Health Metric

Most dashboards track agents built. Few track agents retired. The absence is the signal.

The Retirement Cadence Index (RCI) is a single ratio: agents retired in the trailing 90 days divided by agents in production for at least 180 days. An RCI near zero means the portfolio is accumulating. An RCI in a predictable, non-trivial range means the portfolio is being managed as a lifecycle.

Treat RCI as a leading indicator, not a lagging one. A CoE with a healthy RCI is almost certainly doing the other four stages well, because retirement discipline requires every upstream stage to have produced the artifacts retirement depends on. A CoE with a zero RCI is almost certainly skipping stages upstream, whether leadership knows it or not.

A RACI Mapping for the Five Stages

Competitor content under-specifies ownership. The result is agents whose nominal owner is the maker who built them, which is to say an agent with no durable owner at all. The RACI below assigns each stage to real roles.

Enterprise RACI (full CoE structure)

Design. Responsible — Business sponsor. Accountable — CoE lead. Consulted — Security, risk, data governance. Informed — Platform admin.

Build. Responsible — Maker. Accountable — CoE lead. Consulted — Security, grounding owner. Informed — Business sponsor.

Deploy. Responsible — Platform admin. Accountable — CoE lead. Consulted — Security, FinOps. Informed — Business sponsor.

Operate. Responsible — Business sponsor (recertification), platform admin (telemetry). Accountable — CoE lead. Consulted — Security, model risk. Informed — CIO, CISO.

Retire. Responsible — CoE lead. Accountable — CIO. Consulted — Security, compliance, FinOps. Informed — Business sponsor.

Mid-market RACI (collapsed roles)

Most mid-market enterprises run 10 to 50 agents without a dedicated CoE. The lifecycle still applies. The roles collapse.

Design and Build. One accountable owner, usually the IT director or applied-AI lead, with the business sponsor as responsible for the charter.

Deploy and Operate. The platform admin absorbs security review for standard-risk agents. High-risk agents escalate to a named security contact.

Retire. The IT director runs the decommission runbook personally for the first wave, then codifies it.

The collapsed variant works if, and only if, the artifacts and gates remain. Removing the roles is acceptable. Removing the discipline is not.

The ALM Maturity Model

Use the four-tier rubric below to self-assess current state and identify the next investment. Realistic 2027 targets are Managed for most mid-market organizations and Optimized for enterprises with mature CoEs. Autonomous is a 2028-plus horizon.

Ad-hoc. No formal lifecycle. Agents built in maker studios without charters. No retirement cadence. RCI effectively zero.

Managed. Charters required. Build and deploy gates enforced. Recertification scheduled but inconsistently executed. Retirement runbook exists but is run manually.

Optimized. All five stages enforced with tooling-assisted gates. RCI tracked at the portfolio level and reported to the steering committee. Reusable-asset harvest is routine.

Autonomous. Gates and retirement sequences are largely automated. Portfolio-level KPIs drive CoE investment decisions. Lifecycle discipline is self-reinforcing.

The Economic Case: What Lifecycle Gaps Actually Cost

Lifecycle discipline used to be a compliance argument. Consumption pricing makes it a CFO argument.

Microsoft lists Pay-As-You-Go Copilot Credits at $0.01 per credit, and heavy agent tasks consume more than 700 credits per invocation. An unretired agent running a modest workload is no longer a background cost. It is a line item.

Multiply by Gartner's trajectory. The 150,000-agents-per-Fortune-500 projection by 2028, against the finding that only 13% of organizations believe they have the right agent governance, means the base case for most enterprises is tens of thousands of agents accumulating consumption cost against no corresponding recertification discipline.

Regulators are closing the other side of the vise. EU AI Act high-risk obligations that took binding effect in August 2026 require risk management, record-keeping, human oversight, and accuracy controls across the full lifecycle, not at deployment alone. NIST AI RMF's four functions map naturally onto the five-stage model. ISO/IEC 42001 does the same. The frameworks disagree on terminology. They agree on lifecycle.

The CFO case writes itself. Standing up ALM in two quarters costs less than one audit remediation cycle, and the Copilot Credit savings from a single retirement wave typically fund the first year of CoE investment.

A 90-Day Implementation Roadmap

This sequence assumes an organization that already has a functioning register. If the register does not exist yet, build it first.

Days 1 to 30: Codify Design and Deploy gates

Publish the agent charter template and require it for every new agent. Define the risk-tier taxonomy and tie it to the charter. Codify the Deployment Readiness gate: grounding validation, HITL design review, evaluation test set, security sign-off thresholds. Enforce the gate on new agents immediately. Do not retrofit existing agents in month one.

Days 31 to 60: Stand up Operate telemetry and recertification

Instrument observability on all production agents, prioritizing high-risk tiers. Define the recertification cadence and populate the first quarter's schedule. Establish the model-update change control process. Treat every default-model change as a release event requiring regression test. Begin recertifying the highest-risk agents in the existing inventory.

Days 61 to 90: Run the first retirement wave

Identify the first retirement cohort: agents whose owners cannot be confirmed, whose business purpose is unclear, or whose recertification has failed. Execute the full decommission runbook on the cohort. Expect friction on the first run. That friction is diagnostic. Publish the first RCI reading to the steering committee. Codify what the first wave taught into the standard runbook, and schedule the next quarterly cycle.

At the end of 90 days, the organization has moved from inventory to lifecycle. The register is still the system of record. It is now the input to an operating model, not a substitute for one.

What ALM Is Not

Three common misconceptions derail ALM programs. All three are worth naming before a steering committee commits budget.

ALM is not a tool category. Vendors sell ALM platforms. Platforms help. They do not create the discipline. The organizations that stand up ALM successfully define the operating model first and select tooling against it, not the other way around.

ALM is not the same as having a register. The register is a static artifact. The lifecycle is a continuous process. An enterprise with a perfect register and no lifecycle has solved the first governance question and none of the next five.

ALM is not a one-time setup. Every stage has a cadence. Recertification is quarterly or semi-annual. Retirement is continuous. Model-update change control runs whenever Microsoft ships. An ALM program that is finished is an ALM program that has already failed.

Frequently Asked Questions

What is AI agent lifecycle management?

AI agent lifecycle management is the operating discipline that governs every agent from design through retirement, with defined entry criteria, required artifacts, owners, decision gates, and exit criteria at each stage. It extends an agent register, which is a static inventory, into a continuous operating model.

How is agent lifecycle management different from an agent register?

A register is an inventory: it answers what agents exist, who owns them, and what data they touch. A lifecycle is a process: it governs how each agent is designed, built, deployed, operated, and retired, with gated transitions between stages. The register feeds the lifecycle. It does not replace it.

Why is retirement the differentiating stage?

Every lifecycle framework names retirement. Almost none specify what executing it requires. Retirement is a controlled sequence, not a deletion: freeze, notify, archive telemetry, revoke access in order, rotate credentials, harvest reusable assets, deregister, and record the audit artifact. Skipped retirement produces agents that are not just unreviewed but actively still running with un-rotated credentials and un-revoked permissions.

Who owns each stage of the agent lifecycle?

Design is owned by the business sponsor, accountable to the CoE lead. Build is owned by the maker. Deploy is owned by the platform admin. Operate splits recertification to the business sponsor and telemetry to the platform admin. Retire is owned by the CoE lead and accountable to the CIO. Mid-market organizations without a dedicated CoE can collapse these roles as long as the artifacts and gates remain.

What does an agent lifecycle gap actually cost?

With Microsoft Copilot Credits at $0.01 each and heavy agent tasks consuming more than 700 credits per invocation, unretired agents are a measurable P&L line. At the scale Gartner projects, 150,000 agents per Fortune 500 by 2028, undisciplined portfolios accumulate consumption cost, incident risk, and audit exposure in parallel. Regulatory frameworks including the EU AI Act now require lifecycle-based controls, not point-in-time deployment reviews.

How do I start if I only have 90 days?

Days 1 to 30: codify the Design charter and the Deployment Readiness gate, and enforce both on new agents. Days 31 to 60: instrument observability on production agents, define the recertification schedule, and establish model-update change control. Days 61 to 90: run the first retirement wave on agents with unclear ownership or failed recertification, and publish the first Retirement Cadence Index reading to the steering committee.

Sources

Gartner, Gartner Identifies Six Steps to Manage AI Agent Sprawl, April 28, 2026.

Gartner, Gartner Predicts AI Agents Will Outnumber Sellers 10 to 1 by 2028, July 28, 2026.

Microsoft Learn, Manage the AI model lifecycle for Copilot Studio agents.

Microsoft Learn, Establish an application lifecycle management strategy.

Microsoft Copilot Blog, Guidance hubs to help you plan, build, and operate enterprise-ready agents.

AvePoint, AI Agent Lifecycle Management: From Deployment to Retirement, August 28, 2026.

Microsoft Learn, Usage-Based Billing and Cost Management for Copilot Credits.

Cloud Revolution, Microsoft Copilot Credits: The Complete Guide for 2026.

GAICC, Global AI Governance Comparison 2026: EU AI Act vs NIST AI RMF vs ISO/IEC 42001, July 8, 2026.

The Executive Takeaway

The agent register answers what exists. The lifecycle answers how it is governed, from the moment a sponsor proposes it to the moment its credentials are rotated and its telemetry archived. Those are different questions. They need different disciplines.

Enterprises that stand up the five-stage model in the next two quarters will absorb the 10,000-fold agent expansion ahead of them with the same discipline IT eventually applied to service accounts, releases, and employee onboarding. Those that treat the register as the finish line will spend 2028 doing agent remediation at Copilot Credit prices. The window to choose which organization you will be is open now, and it is not open for long.

Build the lifecycle. Then watch the Retirement Cadence Index. It will tell you, more honestly than any dashboard, whether you are managing a portfolio or accumulating liability. BabyBots works with enterprise teams to operationalize this discipline. The hardest part is not the framework. It is the first retirement wave, and the discoveries it forces.