AI agent lifecycle management

Deleting an agent’s chat history does not necessarily revoke its credential. Pausing a scheduler does not necessarily stop accepted tool operations. A lifecycle procedure needs to identify the components whose state must change together.

Use a stable deployment ID from the inventory. Record each transition against that ID, with the configuration version and the person responsible for the decision.

Define transitions the team can operate

The following is an illustrative lifecycle, not a universal standard. Add states only when they represent decisions or behavior your system actually supports.

Transition	Required decision or evidence	Authority effect	Owner
Proposed to testing	Purpose, data boundary and test environment	Test-only identity and resources	Deployment owner
Testing to active	Accepted task and boundary evidence	Reviewed production scope	Release decision owner
Active to changed	Comparison with accepted configuration	Only explicitly approved scope changes	Change owner
Active to suspended	Reason and stop procedure	Block specified new work; inspect accepted work	Operating owner
Suspended to active	Recovery conditions and fresh decision	Deliberate restoration of selected scope	Authorized recovery owner
Active or suspended to retired	No remaining work requiring authority	Remove unused triggers, grants and credentials	Deployment and identity owners

The lifecycle worksheet provides a place to record the transition and its observed effects.

Onboard with a task and a stop path

A proposed deployment needs a purpose, owner and initial scope. Start in an environment where failures do not affect customers. Create identities appropriate to that test scope and keep production credentials unavailable.

Before release, demonstrate the useful task and the relevant forbidden cases. Include the stop procedure while the deployment is still easy to reset. A capability that cannot be suspended reliably needs an explicit decision before it is given consequential access.

AWS recommends temporary credentials for workloads. The identity guide explains how to connect changing credentials to a stable deployment record. A temporary credential still needs appropriate permissions and a defined renewal failure path.

Review changes by their effect

Different changes need different evidence. A new model or instruction can affect tool selection and task quality. A broader role changes reachable resources. A new output destination changes who receives information. A tool implementation change can alter effects without changing its name.

Compare the candidate with the last accepted deployment. List which assumptions changed, then rerun the cases that depend on them. Keep required release checks intact; a narrow code diff does not make a widened credential harmless.

Handle queued work during an update

A request created under an older tool definition may be incompatible with the new one. An approval may cover arguments whose meaning has changed. Decide whether to drain, cancel or reevaluate that work before switching versions.

For an illustrative restart tool, changing target from one instance to a service group changes the possible effect. Do not dispatch an old approval under the new interpretation. Transaction authorization principles support ensuring that execution still matches the approved details.

Keep rollback behavior equally explicit. Rolling back code does not necessarily restore revoked credentials, deleted data or a prior external side effect.

Suspend new work and inspect accepted work

A suspension record should say which entry points were disabled: scheduler, direct API, CLI route, tool server or credential. Verify the result using a test request where appropriate.

Then inspect pending approvals, queues and accepted operations. Mark each as canceled, still running, completed or unresolved. A downstream operation may continue after the agent process stops. Its owner needs a recovery path that does not rely on the stopped agent’s memory.

Routine review expiry and a confirmed security incident may both trigger suspension, but their response procedures differ. Use the incident-response guide for abnormal activity and evidence preservation.

Resume with a new decision

Resolve the reason for suspension and collect the required evidence. Reevaluate old proposals against current policy and user intent. Do not let reconnecting a credential automatically release every action that accumulated while the deployment was paused.

For a hypothetical policy-service outage, restore the dependency, verify current decisions on test resources and discard or reevaluate stale queued requests. Resume the reviewed scope with an operator able to inspect its outcomes. Record who accepted recovery and which limits remain.

Retire without losing accountability

First stop new triggers and resolve outstanding work. Remove credentials and grants that no longer serve another documented purpose. If a credential is shared, identify its other users before revoking it and remove this deployment’s route without leaving an unexplained exception.

Delete or retain memory, artifacts and audit records according to their specific purpose and retention rules. Preserve the retired deployment’s stable ID and ownership history so older events remain attributable. An inventory row can remain visible while operational authority is gone.

Verify retirement through the receiving systems. Attempt a controlled denied request with the retired route, inspect remaining scheduled jobs and review credential references. Mark retirement incomplete if a downstream session or grant remains unresolved.

NIST’s AI RMF Core treats risk management as continuing through the lifecycle. This procedure makes the operating transitions concrete; broader domain and organizational reviews may add decisions beyond this engineering scope.