AI agent lifecycle management: build, test, approve, deploy, monitor, change, retire

Agent definitions are versioned on each platform in its own way. Foundry creates a new agent version, an immutable snapshot, each time you change an agent; AgentCore Runtime creates version 1 automatically and a new immutable version on every update; Copilot Studio agents live in Power Platform solutions, and a custom solution is how an agent moves between environments. Prompts kept outside the agent have their own registries: Langfuse gives each prompt a version id and a movable production label, LangSmith a commit hash per change with movable tags, and the MLflow Prompt Registry immutable versions with movable aliases.

Models retire on the vendor’s schedule. Microsoft Foundry’s lifecycle has five stages (preview, generally available, legacy, deprecated, retired); a standard GA model lives 18 months, is deprecated for new customers at 12 and retired at 18 with a 410 Gone, while Anthropic, DeepSeek, Fireworks and Mistral AI GA models follow a 12-month lifecycle. Standard deployments auto-upgrade at retirement unless versionUpgradeOption says otherwise, provisioned deployments do not, and retirement dates are not extendable. Amazon Bedrock’s policy for models launched on or after 7 Sep 2026 has three states, active, legacy and end of life: legacy lasts six months for most models or 45 days, existing customers in legacy may lose access after 15 days of inactivity, and at end of life requests fail with no automatic migration.

Tools and knowledge change behaviour as much as prompts. Pin tool lists at approval, and treat a changed tool list, a new MCP server version or a re-indexed knowledge base as a change that re-runs the evaluation set.

On Microsoft, Power Platform pipelines deploy the same managed solution through stages so customisation cannot bypass QA environments or approvals. In Foundry’s documented (legacy) publishing experience, an Agent Application gives an agent a stable endpoint and its own Entra agent identity, and publishing a new version routes all traffic to it; Microsoft documents a newer publishing model alongside it. Permissions do not transfer on publish, so RBAC must be reassigned or tool calls fail after release.

AWS keeps AgentCore Runtime’s DEFAULT endpoint on the latest version while named endpoints stay pinned until updated, so production uses a named endpoint and rollback is repointing it to an earlier agentRuntimeVersion. A/B testing splits live traffic between versions (GA July 2026), and AgentCore Evaluations (GA 31 Mar 2026) runs the test stage.

Google’s Agent Runtime (Agent Engine until the 22 Apr 2026 rename) added agent revisions with traffic splitting in public preview on 19 May 2026, which is the canary mechanism.

Microsoft calls Agent 365 the control plane for agents (registry, Requests queue, management rules, block and soft delete, with Entra for identity); Foundry Control Plane adds fleet operations for Foundry agents (runs, error rate, cost, continuous evaluation). On AWS the equivalent is the AgentCore family: Registry, Identity, Policy, Observability with cross-account monitoring, and Evaluations; Google’s is Agent Registry, Agent Gateway and Agent Observability.

What differs from DevOps is the evidence. An agent is non-deterministic, so the test stage scores a distribution against acceptance criteria instead of asserting one result; the Foundry evaluation GitHub Action reports confidence intervals between a baseline and a candidate (preview). And forensics need more than logs: CoSAI recommends keeping prompt and response pairs, tool execution traces, system prompts and model versions so an incident can be reconstructed, while CVE-2026-15737 (July 2026) showed that raw prompts written into AgentCore telemetry are themselves a leak.