Agent Lifecycle Management for Copilot Studio and Microsoft Foundry

Built-in stages for draft, test, approved, published, monitored, and retired

In Microsoft’s ecosystem, agent lifecycle management works best when authoring and governance are split across the tools that are strongest at each job. Copilot Studio is where many teams design agents, manage conversation logic, package changes, and promote solutions across environments, while Microsoft Foundry adds deeper evaluation, observability, tracing, and model lifecycle controls. Microsoft’s own Copilot Studio guidance frames agent delivery as an iterative lifecycle, and its ALM guidance recommends moving agents through development, test, and production environments rather than treating deployment as a one-click event.

That makes a six-stage operating model especially practical: draft, test, approved, published, monitored, and retired. These stages are not official Microsoft labels used everywhere in the product UI, but they map cleanly to how Copilot Studio and Foundry are actually run. Draft aligns to discovery, experimentation, and build; test aligns to pre-production validation and evaluation; approved aligns to administrative and governance review; published aligns to channel or organizational release; monitored aligns to operational steady state; and retired aligns to model and agent decommissioning when the solution is no longer fit for use.

The key design choice is to make these stages explicit in the platform and in process. In Copilot Studio, that means separating development, test, and production environments, packaging changes in solutions, and using deployment tooling such as Azure DevOps, GitHub Actions for Power Platform, or Power Platform Pipelines. In Foundry, it means attaching evaluations, traces, monitoring, and retirement planning to every production-grade agent so that release is evidence-based instead of informal.

Draft: build safely before anyone depends on the agent

For Copilot Studio, the draft stage should live in a low-risk development environment where makers can explore instructions, topics, actions, knowledge sources, and orchestration patterns without exposing unfinished behavior to production users. Microsoft recommends secure, lightweight, low-audience environments for building before agents are deployed more broadly, which is exactly the right shape for a draft stage. The goal here is not just creativity; it is controlled experimentation with clear ownership and version history.

This is also the point where Foundry should begin contributing, even if the agent itself is primarily authored in Copilot Studio. Teams should already be thinking about which model they will use, what safety and quality signals matter, what telemetry they will need later, and which evaluation datasets they should start collecting. Foundry’s observability guidance explicitly treats evaluation as part of the full AI lifecycle, not something saved for the end. (

A good draft artifact in this stack includes more than the agent instructions. It should record the business purpose, owner, target audience, channels, data sources, actions the agent can invoke, environment-specific dependencies, and any constraints on security or compliance. That makes later approval easier because the review team is not reconstructing intent from scattered settings. Copilot admin guidance also stresses reviewing capabilities, knowledge, and actions before broader availability, which reinforces the value of documenting those elements early.

Test: validate quality, safety, and deployment readiness

Testing in Copilot Studio should not stop at “does the chat flow work.” Microsoft’s ALM guidance recommends a real development-to-test-to-production path, where changes are promoted into test environments and reworked if defects are found. That is the right home for validating environment variables, connection references, external systems, authentication behavior, and any channel-specific issues before users see the agent.

Foundry makes the test stage much more rigorous. Its agent evaluation tooling supports built-in evaluators for quality, safety, and agent behavior, and the Foundry portal can run evaluations against test datasets so teams can compare runs and analyze results before release. Microsoft’s observability guidance also describes pre-production evaluation as the stage where teams validate task adherence, groundedness, relevance, and safety under realistic conditions.

In practice, this means a Microsoft-specific test gate should combine both products. Copilot Studio verifies the agent as a working business application across environments and channels, while Foundry verifies the agent as an AI system with measurable behavior. An agent should not move forward simply because it appears usable in a maker test pane; it should move forward because it has passed environment testing, scenario testing, and evaluation thresholds that reflect the actual risks of the use case.

Approved: make governance a real promotion gate

Approval is where Microsoft’s platform story becomes especially useful. In the Microsoft 365 path, Copilot Studio makers can share agents for limited collaborative testing and then publish them for admin approval before they reach a wider internal audience through the organizational catalog. The Microsoft 365 admin center, through Copilot Control System, gives admins a real review point rather than forcing organizations to rely on off-platform signoff.

That approval stage should be treated as a formal promotion event. Reviewers should confirm the agent’s intended audience, channels, actions, data access, security posture, and compliance fit, along with the evidence produced during testing. Microsoft’s admin guidance specifically tells administrators to review capabilities, knowledge, actions, and security and compliance details before assigning or making agents available.

For agents that rely on Foundry-hosted models or deeper Foundry services, approvals should also confirm that evaluation results are acceptable, monitoring has been wired up, and model lifecycle risk has been considered. In other words, “approved” should mean both business approval in the Copilot layer and technical-operational approval in the Foundry layer. That keeps governance from becoming a branding exercise and turns it into a measurable control point.

Published: release deliberately, not all at once

Publication in Copilot Studio is the point where an agent becomes available on its selected channels, such as websites, Teams, mobile apps, or Microsoft 365 Copilot. Microsoft notes that every time you update the agent, you publish again, and that publishing applies the update across connected channels. That makes publication a distinct lifecycle stage: it is the controlled release of a specific version, not merely the existence of saved changes.

This stage should still be gradual. One version may be published first for a narrow internal group, then approved into the organization catalog, and later made available more broadly. Microsoft’s admin and publishing guidance supports that phased pattern by distinguishing limited sharing for collaborative testing from wider organizational publication and installation.

Where Foundry fits is in ensuring that what gets published is actually production-ready from an AI operations perspective. Publishing should happen only after pre-production evaluation is complete and the team knows what telemetry, tracing, and monitoring views will be used once real traffic starts. The release event belongs to Copilot Studio, but the confidence to release should increasingly come from Foundry.

Monitored: operate the agent as a living system

Microsoft’s Copilot Studio lifecycle guidance describes the post-release phase as “operational steady state,” where teams maintain, monitor, and continuously improve the system. That is a strong reminder that a shipped agent is not finished. It is an active service that has to be observed as user behavior, business processes, model behavior, and connected tools evolve over time. (

Foundry provides the deeper monitoring layer for this stage. Its Agent Monitoring Dashboard tracks token usage, latency, success rates, and evaluation outcomes for production traffic, and it relies on Application Insights plus tracing to make agent behavior visible. Microsoft also describes observability as the combination of evaluation, monitoring, and tracing, which is especially important for multi-step agent workflows where failures are not always obvious from the final answer alone.

A mature monitored stage should feed directly back into test and approval. Production traces can reveal tool misuse, latency spikes, brittle prompts, and failure patterns that were missed in staging. Continuous evaluation can expose safety drift or declining task completion. In a Copilot Studio plus Foundry setup, monitoring is not just for dashboards; it is the evidence engine that tells you when to tune, re-test, re-approve, or roll back an agent version.

Retired: plan the exit before it becomes urgent

Retirement is often ignored until a model is deprecated, a connector changes, or the business no longer wants the agent. Foundry makes this stage very concrete because Microsoft publishes model lifecycle states such as legacy, deprecated, and retired, and states plainly that retired models are no longer available for use. It also provides notification windows so teams can migrate deployments before service disruption.

For Copilot Studio, retirement should mean more than unpublishing an agent. It should include removing or disabling channels, withdrawing organizational availability, cleaning up solutions and dependencies, documenting any successor agent, and making sure users are not left calling actions or knowledge sources that are no longer supported. In the Microsoft 365 admin path, admins can remove or block agents that are unneeded, which makes retirement a governance action as well as a technical one.

The most resilient organizations therefore treat retirement as a first-class lifecycle stage from day one. They know which model versions the agent depends on, who receives retirement notices, what the fallback plan is, and how users will be migrated. In the Copilot Studio and Microsoft Foundry world, that is the difference between an agent program that scales cleanly and one that repeatedly gets surprised by its own dependencies.

The practical operating model

For this Microsoft stack, the cleanest pattern is simple: Draft in Copilot Studio development environments, test in Copilot Studio plus Foundry evaluations, approve through admin and governance review, publish through Copilot Studio channels and catalog controls, monitor in Foundry with telemetry and tracing, and retire with both agent and model lifecycle actions. That approach matches Microsoft’s own guidance on ALM, deployment, observability, and model retirement while giving teams a lifecycle they can actually run.

Source: Agent Lifecycle Management for Copilot Studio and Microsoft Foundry