The Enterprise Agent Lifecycle: Registry, Versioning, Scaling, and Retirement

Treat every production agent as a fleet asset with a lifecycle — build, test, deploy, monitor, retire — not as a project that ends at launch. The operational spine of that lifecycle is four disciplines: a registry (what exists, who owns it, what it can touch), versioning (prompts and tools as immutable, deployable artifacts), scaling (capacity planned around provider quotas, not cluster size), and retirement (graceful shutdown, revoked access, retained audit records).

The reason to formalize this now, rather than after the tenth agent ships, is that agents accumulate differently than services. They are cheap to create — a prompt, a model selection, and a handful of tool grants — so they multiply across business units faster than any architecture review board meets. Each one holds credentials, touches data, and changes behavior whenever anyone edits its prompt. Without lifecycle discipline, the fleet becomes a set of unlisted, unversioned, unretired liabilities. All three hyperscalers have converged on the same conclusion: AWS, Microsoft, and Google each now ship an agent registry, agent versioning, and a managed agent runtime as first-class platform features, which is the clearest available signal of where enterprise agent operations is heading.

1. By the numbers

2. The lifecycle, not the launch

The five stages are familiar from software, but the artifacts differ. Each stage should produce something the next stage consumes — and the loop closes: monitoring findings feed the next build, and retirement criteria are written at intake, not improvised at the end.

Two stages get full treatment elsewhere and are only cross-referenced here: the test stage — evals, tracing, failure taxonomies — is covered at /guides/testing-and-debugging-agents, and the governance overlay that sits across every stage — approval authority, agent identity, policy enforcement, spend controls — is covered at /guides/agent-governance-guide. Vendor platforms increasingly encode this same arc natively; Microsoft's Foundry Agent Service, for instance, documents its agent support explicitly as "the full build-test-deploy-monitor workflow."^[4] This guide takes the remaining, least-glamorous ground: the registry, the version discipline, the capacity math, and the shutdown.

3. Registry and discovery: you cannot govern what you cannot list

The registry problem arrives quietly. The third team to build a customer-lookup agent doesn't know the first two exist. An agent built by a contractor who left still holds a database credential. Security asks "which agents can read HR data?" and the honest answer is a Slack archaeology exercise. A registry converts those questions from investigations into queries — and it is the precondition for everything else in this guide, because versioning, capacity, and retirement all key off a record that must exist first.

A minimum viable registry record is small. Per agent: a unique identity; a named human owner and escalation path; the model and version pins; the tools and data scopes it is granted; its data classification and business criticality; its current lifecycle state (draft, deployed, deprecated, retired); and its review and retirement dates. The schema matters less than two properties: the record is mandatory — created at build time, not backfilled — and it is queryable by security and platform teams, not buried in a wiki.

The platform vendors have validated this pattern by shipping it. Amazon Bedrock AgentCore includes a Registry service described as "a centralized catalog for discovering and managing agents, MCP servers, tools, skills and custom resources across your organization," with "a governed workflow for publishing, reviewing, and approving resources" — and it explicitly registers resources deployed on AWS, on-premises, or on other clouds.^[5] Google Cloud's Agent Registry is "a centralized catalog that lets you store, discover, and govern Model Context Protocol (MCP) servers, tools, standalone skills, and AI agents," centralizing agent metadata across projects.^[6] Microsoft's Foundry Agent Service versions agents, publishes them to stable endpoints, and distributes them through the Entra Agent Registry, with each agent able to carry its own dedicated Microsoft Entra identity.^[4]

4. Versioning: prompts and tools are deployable artifacts

An agent's behavior is the product of at least four independently changing inputs: the model, the prompt, the tool set (each tool with its own schema and implementation), and the guardrail configuration. A one-line prompt edit can change behavior as much as a code release — but in many organizations it ships with none of a code release's ceremony: no review, no version, no rollback. The fix is to treat the whole bundle as one deployable, immutable artifact.

The Bedrock agent model is the cleanest public articulation of the pattern. You iterate on a mutable working draft; deploying means creating a numbered, immutable version and an *alias* that points to it. Applications call the alias, never the version — so "you can change an alias to point to a previous version of your agent if there are changes that you need to revert quickly."^[7] The same discipline extends below the agent to its prompts: Bedrock's Prompt Management keeps a mutable draft, lets you compare variants, and cuts point-in-time version snapshots when a configuration is ready for production.^[8] Microsoft's Foundry Agent Service arrives at the equivalent design — versions are "automatically snapshotted" as you iterate, with rollback to any previous version and comparison between versions — and applies it to the tool layer too: a toolbox is versioned centrally, so you "create a new version, test it, and promote it to default," rather than rewiring every agent that shares the tools.^[4]

• One release bundle, one version number. Prompt text, pinned model identifier, tool schemas and tool versions, guardrail and policy config, and the eval baseline that version passed — captured together, because they only make sense together.
• Config-as-code in Git, even on a managed platform. The platform's version store is the runtime record; Git is the review surface. Pull requests, required reviewers, and CI evals apply to prompt changes exactly as they do to code. Foundry's own docs recommend the code-first path — defining agents via SDK or REST in the deployment pipeline — precisely because it enables "version control, code review, and automated rollout."^[4]
• Staged rollout via the pointer, not the artifact. An alias or stable endpoint is a routing decision you can move gradually: point a canary alias at the new version, watch eval and production metrics, then move the production alias. Rollback is repointing, which takes seconds and requires no rebuild.
• Semantic versioning for tools. Tools are consumed by many agents; a breaking schema change is a coordinated migration, not an edit. Version tool contracts independently and record which tool versions each agent version depends on.

5. Scaling: the ceiling is the provider quota, not your cluster

Scaling an agent fleet from ten users to ten thousand looks like a standard horizontal-scaling exercise — stateless workers, externalized session state, autoscaling — and those patterns do apply. But the binding constraint is usually upstream: every agent invocation resolves to model API calls, and model APIs are rate-limited per organization, not per agent. Your entire fleet, across every business unit, draws down one shared quota pool per provider per model.

The mechanics are worth knowing precisely, because they shape architecture. Anthropic enforces limits per model class on three dimensions — requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM) — using a token-bucket algorithm that replenishes continuously; exceeding any dimension returns a 429 error with a `retry-after` header, and organizations move up usage tiers automatically based on usage history.^[2] OpenAI's model is similar in kind: limits are measured across requests per minute and per day, tokens per minute and per day, and other dimensions, whichever is hit first; six usage tiers advance automatically as paid spend accumulates, and exceeding a limit likewise returns a 429 with a Retry-After header.^[3] The design consequence is the same for both: capacity is a function of account maturity and negotiated tier, so a launch plan that assumes day-one throughput must be validated against the tier you will actually hold on launch day.

Three levers matter most once the quota is the ceiling. First, caching as capacity. On the Claude API, cached input tokens do not count toward ITPM for most models — Anthropic's own worked example: a 2,000,000-ITPM organization with an 80% cache hit rate effectively processes 10,000,000 input tokens per minute — and cache reads are billed at 10% of the base input-token price.^[2] Agents are unusually cacheable workloads: the system prompt, tool definitions, and shared context are identical across thousands of invocations, so structuring prompts for cache stability directly multiplies fleet throughput. Second, queueing and backpressure. Put an internal queue in front of provider calls, enforce per-team or per-agent admission control so one runaway agent cannot starve the fleet, honor `retry-after` on 429s with jittered backoff, and shed or defer low-priority work under pressure rather than retrying it into a thundering herd. Third, segregating offline from interactive traffic. Batch endpoints exist for exactly this: Anthropic's Message Batches API carries its own separate rate limits and accepts up to 100,000 requests in a single batch,^[2] so nightly enrichment jobs and bulk agent runs need never compete with a user waiting on a response.

Below the quota layer, the compute architecture follows well-worn patterns: keep agent workers stateless, externalize session state and memory to a shared store, and scale the serving tier horizontally. This is precisely what the managed agent runtimes productize — AgentCore Runtime is described as "a secure, serverless runtime" providing "fast cold starts for real-time interactions, extended runtime support for asynchronous agents, [and] true session isolation,"^[5] and Foundry's runtime autoscales both prompt agents and hosted-agent container instances with request volume.^[4] The build-vs-buy question at this layer is honest on both sides: the managed runtimes remove undifferentiated infrastructure work, at the price of coupling your fleet's operational model to one vendor's lifecycle — a coupling whose risk the retirement section makes concrete.

6. Retirement: the stage nobody budgets for

Agents get retired for mundane reasons — superseded by a better version, usage fell to zero, the owning team dissolved, the cost stopped justifying the outcome — and for sharp ones: a compliance finding, a security incident, a behavior that can't be fixed forward. The policy questions (who can order termination, at what thresholds, with what escalation) belong to the governance overlay at /guides/agent-governance-guide. What belongs here is the mechanism: how an agent stops without leaving orphaned tasks, live credentials, or an evidentiary gap.

1. Stop admissions first. Flip the agent's endpoint to reject new work before touching anything else. This should be a routing-layer switch, not a redeploy — Bedrock models it directly: setting an agent alias's invocation state to `REJECT_INVOCATIONS` pauses it without IAM changes, and setting it back resumes it.^[7] A pause switch you have rehearsed is also your containment control for incidents.
2. Drain in-flight work cooperatively. Long-running agent tasks should check a cancellation signal at tool-call boundaries and checkpoint or hand off cleanly. Set a drain deadline; after it, cancel forcibly and record which tasks were killed mid-flight so their side effects can be reviewed.
3. Clean up what the agent held. Release compute, close connections, delete scratch data, and reconcile partially completed work — idempotent or transactional tool designs pay for themselves here, because a half-finished multi-step task is otherwise unrecoverable state.
4. Tombstone, don't just delete. Revoke the agent's identity and every tool and data grant, and mark the registry entry retired rather than removing it. The tombstone is what lets you answer, a year later, "what could this agent access, and when did it stop?" — and it prevents a re-created agent from silently inheriting the old name's reputation or grants.
5. Retain the audit record. Archive the final version bundle (prompt, model pin, tool schemas), the decision log or traces, and the decommission record itself, under your normal records-retention schedule. Regulated workloads may need to reproduce an agent's decision process long after the agent is gone; the archive, not the running system, is what makes that possible.

Retirement also arrives from below, on your vendors' schedule. Model providers retire models continuously: Anthropic's published lifecycle runs active → legacy → deprecated → retired, with at least 60 days' notice before retiring a publicly released model — and "requests to retired models will fail."^[1] Whole platforms churn too: Amazon Bedrock Agents — the original managed agent service, now "Bedrock Agents Classic" — is "no longer open to new customers," with AWS pointing new builds at AgentCore.^[9] An agent fleet with pinned models and a real registry absorbs both kinds of churn as scheduled migrations; a fleet without them discovers a vendor deprecation as a production outage.

7. Honest objections

"We have six agents. This is process for a problem we don't have." Mostly fair — at six agents the registry is a spreadsheet and the review is a conversation, and it should stay that lightweight. The counterpoint is sequencing: the cheap moment to institute registration-before-credentials and versioned prompts is when there are six agents, because retrofitting inventory and version history onto sixty undocumented agents is an archaeology project. Adopt the discipline early and scale the tooling later.

"The platforms will do this for us." Substantially true at the mechanism layer, and this guide cites the evidence: registries, immutable versions, rollback, pause switches, and autoscaling runtimes are now stated platform features at AWS, Microsoft, and Google.^[5][4][6] But three things stay yours regardless: the organizational metadata (ownership, criticality, data classification, retirement criteria) that no vendor registry knows; the cross-platform view, because a real enterprise fleet spans more than one vendor plus in-house frameworks; and the vendor-churn risk itself — the platform that manages your lifecycle has a lifecycle of its own, as Bedrock Agents Classic customers can attest.^[9]

"Version ceremony will kill iteration speed." The experience from ordinary CI/CD argues the opposite: teams ship faster when rollback is instant and cheap, because each release carries less fear. The alias-repoint rollback model means an experiment that regresses is undone in seconds. What genuinely kills speed is the alternative — untracked prompt edits that turn every production anomaly into a forensic search for what changed.

8. The read

For a CIO or platform lead, this reduces to four decisions. Decide the system of record now: one registry — vendor-provided or a simple internal catalog — wired as the credential gate, holding every agent regardless of which framework or cloud runs it. Decide that prompts are artifacts: versioned bundles, Git-reviewed, deployed by pointer, rolled back by repoint; no in-place edits to production agents. Decide capacity against tiers, not hardware: know your organization's current tier and limits per provider, engineer prompts for cache stability, queue with backpressure, and push offline work to batch endpoints. Decide retirement at intake: every agent enters production with a named owner, a review date, and a rehearsed pause switch — so that stopping an agent, for any reason, is an operation and not an incident. Teams that make these four decisions early spend their agent budget on new capability; teams that defer them spend it on archaeology.