Skip to main content
Agentic Architecture Skills.
Start hereUse casesArchitectureIntelligence ladderKnowledge & memoryResearchSkills
Architecture

The agent lifecycle: register to retire

The nine stages every agent passes through, from registration to retirement. A registry entry and a named sponsor come first, before any credential, and retiring is more than switching off.

By Murali SidLinkedInPublished Updated

An agent gets an identity and goes live. A year later its owner has left. It has gathered access that no one remembers granting. It still runs on an approval given to an older version of itself. Microsoft's own agent registry shows a standing count of "Agents without owners" [vendor]. The answer is a lifecycle. Every agent gets a registry entry and a named sponsor before it holds any credential. Then it passes through nine stages, from register to retire.

The registry is the official list of agents. The sponsor is the business person who answers for an agent. The owner is the technical person who keeps it running. With those in place, the company's existing rules can reach the agent. They are security policy, access control, change management and approval to production.

Each stage calls on the seven capabilities an agent platform provides. The registry sits in identity and policy. Evaluations run at the evaluate and change stages. Traces from observability feed the periodic review. People fill the sponsor, approve and review stages. Build and pilot sit before stage 1, and their test results feed the evaluate stage.

The nine stages

Nine stages run in order: register, sponsor and owner, entitle, evaluate, approve, operate, change, periodic review and retire. Each stage carries a badge. Shipped means a product does it. Guidance means published guidance asks for it. No standard yet means only practitioners describe it. Eight change triggers send a running agent back to evaluate. They are model, prompt, tools, permissions, data sources, memory policy, autonomy level and sponsor. A review loop checks purpose, access, budget and need every quarter, or every year for Tier 1. Retire opens out into five steps: disable, revoke, redirect, remove and keep. The registry record sits in the centre in four groups. When a sponsor leaves, a successor must be named.
Nine stages, one registry recordNo agent runs without a registry entry and a named sponsor. Retiring is more than switching off.Open image at full size ↗

How the stages line up with industry lists

Every major source has its own list. This table puts the nine stages beside the closest names in three of them.

Five stages map cleanly: register, evaluate, operate, periodic review and retire. Three map in part. Elsewhere, sponsor and owner is a role, approve is a gate, and change is a version step. Entitle is a control in every other source, not a stage.

Build and pilot sit before stage 1. AWS calls them Development and Pilot. Microsoft Foundry calls them create and test. NIST calls them plan and design, and build and use model.

The AWS lens has two state lists. AGENTOPS03-BP01 has five: Development, Pilot, Production, Deprecated and Decommissioned. AGENTSUS03-BP04 has four: Active, Under review, Deprecated and Decommissioned. The registry record on this page uses the second list, with retired in place of decommissioned.

How existing controls reach the agent

Security policy. Policy targets the agent's own identity, its template and its registry labels, such as risk tier. One policy on a template covers every agent built from it, including later ones. Microsoft's Conditional Access works this way [vendor]. It can target one agent, its template (Microsoft calls it a blueprint) or a label. It cannot protect resources reached with an API key, a fixed secret that grants access (Microsoft Learn, 7 October 2026). So the agent holds no keys. The tool gateway adds credentials at the moment of use, as the delegation chain sets out.

Access control. The template sets the baseline. Extra access is a narrower grant for a stated task, and every grant expires. In Entra, the sponsor can renew an expiring grant or let it lapse [vendor]. When the agent acts for a person, the lesser right wins. That is either the person's rights or the agent's own grant. The highest data class the agent can reach caps every grant. Microsoft Purview governs what an agent can read. But content an Agent 365 agent creates does not inherit the source's sensitivity label [vendor].

Change management. Every change trigger is logged on the agent's registry record. A triggered change re-runs the evaluations and the risk profile before release. The sponsor is told.

Approval to production. The risk tier on the registry record picks the approval path. The sponsor and the owner sign at every tier. More people sign at Tier 2 and Tier 3.

The change triggers

Eight kinds of change make an approval out of date. Each one re-runs the evaluations and the risk profile before it goes live.

  • Model. A new model or model version, including a vendor upgrade.
  • Prompt. The system instructions or any approved prompt template.
  • Tools. A tool added, removed, or changed in what it can do.
  • Permissions. Any change to a grant, a scope or a credential.
  • Data sources. A new source, or a source with a higher data class.
  • Memory policy. What the agent keeps, for how long, and who can read it.
  • Autonomy level. Any move on the scale in the autonomy contract, from manual (A0) to governed lights-out (A5).
  • Sponsor. A new sponsor, including a hand-over when a sponsor moves or leaves.

A new tool grant changes the agent's permissions, so the risk profile is scored again. Practitioners and gateway vendors say the same. One practitioner group says an approval covers one configuration only (NHIMG). A model upgrade can pass every old test and still change which tool the agent picks (Gravitee) [vendor]. The EU AI Act's nearest term is "substantial modification" (Article 3(23)).

How heavy the re-run is depends on the tier. For a Tier 1 agent it can be an automated pipeline step. For a Tier 3 agent it goes back through the full approval path.

Periodic review

At each review, the sponsor checks four things: purpose, access, budget and continued need.

Change triggers catch what someone changed. Periodic review catches what drifted. Access goes unused. A purpose goes away. A budget creeps up. A no on any check starts a change or a retirement. Review every quarter. The CAF and the AWS lens both name a quarterly review [vendor]. The risk profile allows a yearly review for Tier 1 agents.

Retire, and the orphan problem

Stopping an agent is not retiring it. Retirement removes its access, memory and unique tools. It keeps the record of what the agent did.

  1. Disable. Stop new work and block new tokens.
  2. Revoke. Remove every credential, grant and key. Record how long it took.
  3. Redirect. Send callers and scheduled triggers to a replacement or to a person.
  4. Remove. Delete the agent's own memory and data. Remove tools that only this agent used.
  5. Keep. Keep decision records and traces in the system of record, for audit and legal retention.

The AWS lens flags idle agents by the date they last ran [vendor]. It warns to check seasonal agents first, such as one that runs only at tax time. In Entra, a sponsor can disable an agent but cannot turn it back on. Only an owner can restore it or delete it for good [vendor].

Orphans. An orphan is an agent that keeps running after its owner's account is disabled (Obsidian Security) [vendor]. People leave, and their agents stay. Entra says sponsorship should be kept up, so someone takes over when a sponsor moves or leaves [vendor]. A group can be a sponsor in Entra, which helps. Name a successor before a sponsor leaves. Check for agents with no sponsor at every review.

The registry record

One record per agent holds what the four controls need. The registry as compliance inventory sits in the governance, risk and sovereignty layer (R11). It records owner, purpose, risk tier, tools, credentials, and model and prompt versions. This record also separates sponsor from owner. It adds the highest data class and the autonomy the agent actually uses.

Who it is and why it exists

  • ID and template. The agent's unique identity and the template it was built from.
  • Purpose. What the agent is for, in one sentence.
  • Role and business area. What it does for people, from the four questions, and the area it serves.
  • Sponsor. The accountable business person.
  • Owner. The technical custodian.
  • Where it runs. Behind your own gateway, or inside a vendor product as a vendor-embedded agent.
  • What starts it. A person, an event, or the agent itself.
  • Lifecycle state. Active, under review, deprecated or retired.

What it can do

  • Permissions. What its own credentials let it do (read, write, delete, pay, send) and where.
  • Untrusted input. Whether it reads content from outside the enterprise.
  • Highest data class. The most sensitive data it can reach. This caps every grant.
  • Egress. Where it can send data out to.
  • Zones and rules. Which deterministic zones it works near. Whether the rule for decisions about people applies.

How it is governed

  • Risk tier and the factor that set it. The tier, and the factor that pushed it there.
  • Autonomy: designed, permitted and exercised. The level it was built for, the level it is allowed, and the level it actually uses.
  • Learning level. From fixed (L0) to continuous learning inside limits (L3).
  • Budget. Its spending allowance and hard caps.
  • Evaluation results. The latest results, and the version they tested.
  • Approval record. Who signed, at which tier, for which configuration.
  • Regulatory tags. The rules that apply, such as a sector regime.

How it changes over time

  • Model, prompt and tool versions. What is live now.
  • Memory policy. What it keeps, and for how long.
  • Change log. Every trigger, with its date and outcome.
  • Last review. The date and result of the last periodic review.
  • Last run. When it last ran. This flags idle agents.
  • Revoke time. How long the last revoke took.

One agent through the stages

Take a billing-exception agent at an energy retailer. It works on meter reads that look wrong before a bill goes out. The four questions place it at Tier 3.

The retailer registers it and gives it its own identity. The billing operations manager is the sponsor. A platform engineer is the owner. The grant lets it read meter data and customer accounts, and propose bill changes through the billing system. Personal data is its highest class. Evaluations replay last year's exceptions. A red team plants instructions in customer notes. At Tier 3, a security architect, the AI risk council, architecture review, second-line risk and an executive sign. It runs with a budget and a tested kill switch.

Six months in, the vendor upgrades the model. That is a change trigger, so the evaluations and the risk profile run again before release. Each quarter, the sponsor checks purpose, access, budget and need. Two years on, the billing system's own exception engine takes over the work. The agent is retired in five steps, and its decision records stay with the bills.

Evidence and limits

The strongest evidence here is Microsoft's own documentation. It is vendor material, describing one vendor's design. Five of the nine stages match industry lists. Where no product or standard covers a stage, this guide recommends the design on this page. Sponsor, owner, registry and retire follow Microsoft's and AWS's usage.

Four gaps matter. No vendor documents data class or risk tier as a registry field. No standard defines which change forces a new approval. No vendor-neutral data exists on orphan rates or time to revoke. No incident data exists to test any stage against. The clearest public orphan case is Moltbook, reported by Wiz on 2 February 2026. It was a hobby platform, not an enterprise system.

Three regulators already ask for parts of the registry record: MAS in Singapore, and the DTA and APRA in Australia. None names agent risk tiers or a field list.

Agent identity has shipped at Microsoft, AWS and Google. Much of the lifecycle around it is still preview, summary-only or guidance, as of 14 October 2026. The status table is in the research block below.

The DTA pages timed out and were read through search summaries. Several product dates came from summaries or trade press. Re-check every date before relying on it.

Next step

See where the rules are enforced on enforcement outside the model. Then score a new agent with the four questions.

Explore this topic

What has shipped and what has not, as of 14 October 2026

Regulators. The Monetary Authority of Singapore (MAS) issued guidelines on 7 October 2026. They want an AI inventory that carries identifiers, tools and guardrails. Australia's Digital Transformation Agency (DTA) policy v2.0 applies from 15 December 2025. It wants a named owner for each AI use case, and a register shared every six months. APRA, Australia's bank and insurance regulator, wrote on 30 April 2026. It expects an inventory, and ownership "from design and development through to deployment". It named decommissioning of AI as a weak area.

Orphans. Wiz reported on 2 February 2026 that the Moltbook database exposed about 1.5 million agent API keys. They belonged to about 17,000 human owners. Moltbook is a social network where AI agents post. It was a hobby platform, not an enterprise system.

Words. Microsoft uses "sponsor" for the accountable business person. The DTA's register uses "executive sponsor". Okta, Ping, SailPoint and others use "owner" for the accountable person, so read their owner as the sponsor here. The AWS lens says decommission. The CAF says retire.

Crosswalk sources. The ISO 42001 and ISO/IEC 22989 stage lists were read through secondary summaries. ISO/IEC 22989 lists re-evaluation and retirement as stages. NIST AI RMF 1.0 has no retirement stage.

Sources:

Cite this page

Written by Murali Sid, Founder and AI Systems Architect, last updated 15 October 2026. Licensed CC BY-SA 4.0, so quote it freely with attribution.

Murali Sid (2026). The agent lifecycle: register to retire. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/architecture/agent-lifecycle

Machine-readable version of this page: /architecture/agent-lifecycle.md

The delegation chain: trace every action to the person who asked

How every action an agent takes stays traceable to the person who asked, from the agent's own identity, through the gateway, to the system of record.

Enforcement outside the model

A rule written in a prompt is a request. The same rule checked by a separate system is a control. Three places enforce outside the model: the gateway, the policy decision point, and fixed rules promoted from what the agent learned.

On this page

The nine stagesHow the stages line up with industry listsHow existing controls reach the agentThe change triggersPeriodic reviewRetire, and the orphan problemThe registry recordOne agent through the stagesEvidence and limitsNext step