Catalogue › Microsoft 365 Agents › agent-lifecycle

Agent lifecycle

Manages an individual Microsoft 365 agent after release through defined states - live, under change, under review, deprecated and retired - with change control, scheduled and triggered reviews, responses to platform changes, and a retirement path that tells users and disposes of the agent cleanly. Use when a live agent needs changing, when its review date arrives, when its owner or knowledge lapses, or when it should be retired.

Department

Microsoft 365 Agents

Lifecycle

Launch, Improve, Scale

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

m365-agents, copilot-studio, power-platform

Editions

starter, scale, enterprise

Reviewers

design-authority, evaluation-quality

Status

draft

Copilot Cowork

Microsoft 365 Agents plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Releasing an agent is the start of its life, not the end of the project. This skill manages an individual agent from release to retirement: it defines the states an agent moves through, controls changes, runs scheduled and triggered reviews, responds to Microsoft platform changes, and retires agents cleanly when they are no longer needed. Agent estates usually go wrong slowly: changes are made live without testing, reviews never happen, and agents that nobody uses keep answering from knowledge that nobody maintains.

When to use

• A live agent needs a change to its instructions, knowledge, actions or audience.
• An agent's scheduled review date has arrived.
• A trigger fires: the owner leaves, a source is retired, feedback shows repeated wrong answers, or usage collapses.
• Microsoft changes a capability the agent depends on.
• An agent should be retired, or someone asks whether it can be.

When not to use

• The release gate before first sharing or widening the audience - use m365-agents:agent-release-readiness.
• Application lifecycle management, environments and pipelines for Copilot Studio solutions - use copilot-studio:studio-alm and copilot-studio:studio-agent-lifecycle.
• Running scheduled reviews across all live AI solutions in operations - use ai-operations:ai-review-calendar.
• The operational mechanics of retiring any AI solution, including data disposal - use ai-operations:ai-solution-retirement.
• Deciding to scale or stop on value evidence at portfolio level - use opportunity-management:scale-or-stop.

Questions to ask first

1. What state is the agent in now, and who is its current business owner?
2. What has changed or is proposed: instructions, knowledge, actions, audience, or the platform beneath it?
3. Does the change alter the risk tier, the audience or the data the agent can reach?
4. What does the evidence say about use, value and answer quality since the last review?
5. If retired, what replaces it for users, and what happens to its configuration and interaction data?

Required inputs

• The agent-card with owners, tier, sources and review date.
• The change log for instructions and knowledge, and the evaluation set.
• Usage, feedback and value evidence from m365-agents:agent-value-measurement.
• Relevant Microsoft change notices, checked against the source records.

Where the business owner is vacant, the agent enters "under review" automatically. Never change a live agent on the promise that testing will follow.

Decision framework

Agent states and what moves an agent between them.

Changes are classified by impact. Minor (wording, conversation starters) needs a logged reason and regression run. Significant (new source, new action, wider audience) needs the business owner's approval, a regression run and, if the tier or exposure changes, re-classification and the release gate again. Retirement triggers include no meaningful use for an agreed period, a vacant owner not filled in the agreed time, unmaintained knowledge, a better alternative, or a failed review.

Practitioner approach

Make the states visible. Record each agent's state on its agent card and in the register, so anyone can see which agents are live, changing, under review or on their way out. That alone prevents most drift.

Control change by impact. Most changes after release are small: a clearer instruction, a new conversation starter, an updated source. They still need a logged reason and a regression run through m365-agents:agent-testing, because small edits can change behaviour. Significant changes, such as a new source, a new action or a wider audience, go to the business owner for approval and back through classification if the tier or exposure changes. Widening the audience after review is the change most often made without control.

Run reviews as decisions, not status meetings. At each review, the business owner looks at usage, value, answer quality, feedback, knowledge currency and ownership, and decides: continue, change or retire. Record the decision and set the next review date. Triggered reviews follow the same pattern but happen when something breaks the agent's assumptions, such as a source being retired or the owner leaving.

Watch the platform. Microsoft changes agent capabilities, settings and limits frequently. Assign someone, usually the technical owner or the CoE, to check change notices against the source records and assess whether each agent is affected. Test affected agents before the change reaches users where possible.

Retire deliberately. Agree retirement criteria at release, so retirement is routine rather than contentious. When an agent is to be retired, mark it deprecated, tell its users when and why, and point them to the alternative. On the retirement date, stop sharing it, disable or delete it in line with the organisation's retention policy, decide with records management what happens to its interaction data, and update the register. Hand the operational mechanics to ai-operations:ai-solution-retirement where that service exists.

Learn from each retirement. Record why the agent was retired and what that teaches about future opportunity assessment, knowledge ownership or scope.

Outputs

• The agent's state and lifecycle history on the agent-card and in the solution register.
• Change records classified by impact, with approvals and regression results.
• Review decisions (continue, change, retire) with evidence and the next review date.
• Deprecation notices and a retirement record covering users, configuration and data.

Microsoft platform considerations

How agents are versioned, unshared, disabled and deleted differs between Agent Builder, declarative agents and Copilot Studio, and between governance zones. Inventory and governance tooling such as the CoE Starter Kit and Managed Environments features can support reviews and retirement; see ms-copilot-studio-guidance, ms-agent-builder, ms-coe-starter-kit and ms-managed-environments. These change often; check the current records before relying on a specific control.

Adoption considerations

Users need notice before an agent changes significantly or retires, and a clear alternative. Silent retirements and unannounced behaviour changes erode trust in every agent, not just the one affected.

Knowledge considerations

Knowledge currency is the most common reason an agent fails review. Link review dates to knowledge owners' review cycles, and treat a retired or unmaintained source as a trigger for review.

Security and privacy considerations

Significant changes can widen exposure; re-run security-privacy:data-exposure-review when sources, connectors or audience change at tier 2 and above. At retirement, remove access, connectors and credentials, and agree the handling of interaction data with records management and the data protection lead.

Responsible AI considerations

From tier 3, reviews confirm that human oversight arrangements still operate as designed. A change that moves the agent closer to decisions about people triggers re-classification and the responsible-ai gate.

Evaluation requirements

Every change is followed by a regression run of the evaluation set, and each review checks current answer quality against the threshold agreed at release. From tier 3, evaluation-quality checks regression evidence for significant changes.

Value measures

Track at estate level the share of agents within review date, changes made with logged regression runs, and agents retired against criteria rather than abandoned. The CoE lead owns estate measures; business owners own each agent's value measures.

Scale notes

Starter

A state column and review date on a simple register, a change log per agent, and a review conversation with the owner every few months.

Scale

Lifecycle states in the solution register, change classes with approvals, a review calendar run through the CoE, and platform change checks as a standing task.

Enterprise

Lifecycle management federated to business-unit agent product owners under common states and change classes, with estate reporting, automated reminders and links to operations and the portfolio.

Hand-offs

• To m365-agents:agent-testing for regression after each change.
• To m365-agents:agent-release-readiness when a change widens audience or raises the tier.
• To ai-operations:ai-solution-retirement for retirement mechanics.
• To opportunity-management:scale-or-stop when a review raises scaling or stopping at portfolio level.

Reviewer gates

From risk tier 2, significant changes are assessed by design-authority through design-authority:ai-change-impact-review, and from tier 3 regression evidence by evaluation-quality; each finding is blocking or advisory, and blocking findings stop the change.

Failure modes

• Live edits are made without regression, and behaviour drifts unnoticed.
• Review dates pass with no decision, and unused agents accumulate.
• A Microsoft platform change alters behaviour, and nobody checks the agents that depend on it.
• An agent is deleted without notice, and users lose a tool they relied on without an alternative.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Change a live agent without a logged reason and a regression run.
• Widen an agent's audience without passing the release gate again.
• Let a review date pass without a recorded decision.
• Retire an agent without telling its users and handling its data under policy.