AI agents are being created faster than most organisations can identify, govern or evaluate them. Sustainable adoption requires a formal lifecycle that gives every agent an owner, bounded authority, measurable performance and a controlled route to change or retirement.
Three quarters of IT application leaders surveyed by Gartner in 2025 said their organisations were piloting, deploying or already using some form of AI agent. Only 13% strongly agreed that they had the governance structures needed to manage them. That gap is the clearest warning about the next phase of enterprise AI: deployment is accelerating faster than management capability.
The immediate risk is often described as agent sprawl. That is accurate, but incomplete. The deeper problem is that organisations are treating agents as features to launch rather than operational entities to manage.
Once an AI system can pursue a goal, use tools and take action across business systems, it represents delegated operating capacity. It has authority, dependencies, costs and failure modes. It can also remain active long after the team that created it has moved on.
AI agents therefore need formal lifecycle management: a controlled path from demand and design through identity, deployment, monitoring, change and retirement. The objective is not to slow every experiment. It is to prevent rapid deployment from creating an estate that nobody can fully see, evaluate or safely switch off.
The scale problem
Agent proliferation turns experimentation into an estate
Early agent adoption is naturally decentralised. A service team creates an agent to classify requests. Finance builds one to reconcile exceptions. Developers create agents to investigate incidents or generate code. Software providers add their own agents to existing applications, while employees assemble others through low-code tools.
Each decision may be rational in isolation. Collectively, they create a new technology estate.
The warning signs will be familiar to any CIO who has managed SaaS, robotic process automation or service-account sprawl: overlapping capabilities, duplicated costs, inconsistent controls, unclear ownership and dependencies that become visible only when something breaks. Agents add a more serious dimension because they can interpret context, select actions and chain activity across systems rather than simply execute a fixed script.
Walmart has offered a useful public signal of the coordination problem. After building agents across its business, it said that multiple agents could quickly become overwhelming and confusing. Its response was a unified company-wide framework built around four principal “super agents”, with specialised agents operating behind those entry points. This does not prove that every enterprise needs the same architecture. It does show that even individually useful agents can create friction unless discovery, ownership and orchestration are designed at estate level.
The management unit must therefore change. Leaders should not ask only whether a particular agent is safe or valuable. They need to know how many agents exist, who owns them, which workflows depend on them, what authority they hold and whether another agent already performs the same role.
Without that estate view, local innovation becomes enterprise opacity.
The lifecycle
Deployment is the beginning of accountability
Traditional technology governance concentrates heavily on approval and release. The project is assessed, tested and deployed. Operational processes then handle incidents and changes.
Agents make that separation harder to sustain. Their performance can drift as models change, source information is updated, user behaviour evolves, integrations fail or permissions are altered. An agent may continue to function technically while becoming less accurate, less useful or more expensive. Its failure may appear not as an outage, but as a gradual deterioration in decisions.
This is why the lifecycle cannot end at go-live. It must include at least seven connected states:
- Intake and classification: Define the business outcome, autonomy, data sensitivity and potential impact.
- Design and approval: Establish the agent's boundaries, tools, escalation rules and evaluation criteria.
- Identity and registration: Create a unique identity, record ownership and add the agent to an enterprise registry.
- Deployment: Release through controls proportionate to risk and operational criticality.
- Monitoring and evaluation: Track behaviour, quality, cost, incidents and business value in production.
- Change and reapproval: Reassess the agent when its model, data, tools, permissions or purpose changes materially.
- Retirement: Remove access, preserve required evidence and resolve downstream dependencies.
This model is not a novel compliance overlay. It extends established AI risk-management principles into an operating discipline suited to systems that act. The NIST AI Risk Management Framework applies governance across AI design, development, deployment, evaluation and use over time. More recent vendor guidance is also converging on an intake-to-retirement lifecycle, with a named owner, monitoring plan and explicit route to improvement or decommissioning.
The implication is straightforward: an agent should never be in an undefined state. It should be proposed, approved, active, restricted, suspended or retired, with evidence showing why.
Ownership and authority
Ownership must cover outcomes, authority and dependencies
A registry is necessary, but inventory alone is not governance. The more important control is named accountability.
Every production agent needs a business owner accountable for the outcome it is intended to improve and a technical owner responsible for its operation. Higher-risk agents may also need explicit risk, data and security owners. These roles should remain visible throughout the lifecycle rather than appearing only on an approval form.
Ownership matters because an agent sits across several domains at once. Its business owner may judge whether it is useful. Its technical owner may maintain its prompts, models and integrations. Security may control its credentials. A data owner may approve access to sensitive information. Operations may depend on its output. Without defined decision rights, each team can assume that another is watching the whole system.
Authority needs the same precision. An agent that drafts a response for approval is fundamentally different from one that sends it, issues a refund or updates a customer record. The governance question is not whether the system is called an agent. It is what the system is permitted to observe, decide and change.
That distinction also prevents overreaction. The UK Digital Regulation Cooperation Forum notes that current deployments remain mostly supervised and limited in the number of steps they perform. It also argues that regulation and control should reflect outcomes and degrees of autonomy rather than apply a blunt binary label.
A low-risk research assistant using approved public information may need simple registration and routine review. An agent that accesses customer data, commits expenditure or initiates operational changes requires stronger testing, approval, runtime controls and intervention mechanisms.
Formal lifecycle management should be rigorous, but not uniform.
Identity and access
Agent identity must express delegated authority
Human identities represent people. Machine identities usually represent applications, services or workloads with relatively predictable behaviour. Agent identities must represent something more complex: a system acting on behalf of a person, team or organisation within a defined context.
That creates several questions conventional access models do not answer cleanly. Whose authority is the agent exercising? Can it delegate work to another agent? Should its permissions persist between tasks? How can an investigator reconstruct the chain from human intent to agent action?
The Cloud Security Alliance argues that agentic systems introduce autonomy, ephemeral operation and delegation patterns that static identity and access-management approaches were not designed to handle. It recommends distinct agent identities, verifiable delegation, dynamic access decisions and real-time monitoring.
In practical terms, each agent should have its own identity rather than borrowing a developer's credentials or hiding behind a shared service account. Its access should be limited to the tools and data required for the current task, with short-lived credentials where possible. Delegation should preserve the origin, scope and purpose of the authority being passed.
Lifecycle management gives these controls a trigger. Permissions are provisioned when an agent is approved, reviewed when its purpose changes and revoked when it is suspended or retired. Without lifecycle integration, least privilege becomes a one-off configuration exercise and access accumulates over time.
Performance and value
Performance management must include behaviour and value
An agent can be secure and still be a poor investment. It can also complete tasks successfully while damaging the wider process through rework, inconsistent decisions or unnecessary escalation.
Performance management must therefore extend beyond uptime and response latency. Leaders need a balanced view across four dimensions:
- Outcome: Does the agent improve the business measure it was created to influence?
- Quality: Are its decisions or outputs accurate, consistent and appropriately escalated?
- Risk: Is it operating within policy, permission and behavioural boundaries?
- Economics: Does its value justify model, infrastructure, integration and support costs?
These measures should be defined before deployment and reviewed in production. Evaluation datasets and test cases can detect regressions, but they do not replace operational evidence. Teams also need to examine override rates, exceptions, complaints, downstream corrections and the frequency with which humans must rescue the workflow.
Runtime security matters for the same reason. OWASP's Top 10 for Agentic Applications reflects the emerging risks created when systems can use tools, retain context and take action. Monitoring must capture prompts and inputs where appropriate, tool calls, policy decisions, human approvals, resulting changes and anomalous behaviour across connected agents.
The purpose is not surveillance for its own sake. It is to determine whether the agent still behaves as designed and continues to earn the authority it has been given.
Retirement
Retirement is a governance control
Enterprises are better at launching technology than removing it. That imbalance will be expensive with agents.
An agent may become redundant because another capability replaces it. Its source data may no longer be maintained. Its workflow may change. Its owner may leave. It may continue consuming tokens, retaining permissions or generating outputs that nobody actively evaluates.
A dormant agent is not necessarily harmless. It can preserve credentials, data access and dependencies. It can also create false confidence when employees assume an apparently available system is still approved and supported.
Retirement must therefore be designed, not improvised. The process should revoke identities and credentials, remove tool access, archive required logs, notify dependent teams, redirect users and record why the agent was withdrawn. Temporary agents should have expiry dates from creation. Production agents should face periodic recertification of ownership, purpose, access and value.
This is where lifecycle management becomes commercially important. Retirement removes duplicated cost, reduces the attack surface and redirects investment towards agents that deliver measurable outcomes. A healthy agent estate is not the one with the highest agent count. It is the one in which every active agent has a current reason to exist.
The operating model
Sustainable management requires proportionate governance
The strongest objection to formal lifecycle management is that it could turn agent development into another slow central approval process. That risk is real. Governance that treats a summarisation assistant and an autonomous purchasing agent identically will create delay without improving control.
The answer is a federated, risk-tiered model.
A central function should define the taxonomy, minimum metadata, identity standards, prohibited uses, evidence requirements and escalation thresholds. Domain teams should remain responsible for selecting use cases, owning outcomes and managing lower-risk agents within those guardrails. High-impact agents should receive independent security, risk and business review. Low-risk experiments should move quickly inside controlled sandboxes, with automatic expiry unless promoted into the production lifecycle.
Automation should carry as much of the governance load as possible. Registration can be integrated into development platforms. Identity creation can follow approved blueprints. Deployment pipelines can enforce required tests. Monitoring can detect missing owners, excessive permissions, unusual activity or falling performance. Current enterprise platforms are beginning to expose registries, ownership records, risk signals and lifecycle workflows, indicating that agent management is becoming a distinct control plane rather than an informal spreadsheet exercise.
The leadership challenge is to create enough consistency to make agents governable without removing the local expertise that makes them useful.
The leadership agenda
The executive agenda starts with visibility
CIOs do not need to wait for a perfect standard or a major incident. The first agenda is practical:
- Create an agent inventory: Discover agents across enterprise platforms, development environments and business-led tools. Record owners, purpose, users, dependencies, data and permissions.
- Define risk tiers around capability: Classify agents by what they can access, decide and change, as well as the scale and reversibility of their impact.
- Make ownership and identity mandatory: No production agent should operate without a named sponsor, a technical owner and a distinct identity.
- Connect approval to runtime evidence: Require monitoring, evaluation, incident handling and periodic recertification as conditions of continued operation.
- Establish a retirement path: Introduce expiry, suspension and decommissioning controls before the estate becomes too complex to unwind.
The Digital Regulation Cooperation Forum's 2026 work reinforces the central accountability point: greater autonomy does not reduce the organisation's responsibility for legal compliance or real-world outcomes.
Agent lifecycle management is therefore not an administrative response to a future problem. It is the operating model required to scale delegated machine action responsibly.
The organisations that move fastest will not be those that create the most agents. They will be those that can identify which agents deserve authority, prove that they continue to perform and remove them cleanly when they no longer do.
