Systems Life Cycle Management for Claude Applications.

This objective is a general software/IT-engineering discipline applied to Claude-based systems, not an Anthropic-specific API feature. NIST describes it as "the overall process of developing, implementing, and retiring information systems" through initiation, analysis/development, implementation, and operations/maintenance phases, ending in disposal; FFIEC and NIST SP 800-64 describe the same skeleton for regulated environments. Mapped onto a plan → develop → test → deploy → operate → maintain → retire sequence, three phases have concrete, citable Claude-specific mechanics worth knowing cold: test (evals), deploy (model/agent version pinning), and operate (usage telemetry). The other phases (plan, develop, maintain, retire) apply standard engineering practice with no Claude-specific twist worth memorizing beyond what already appears elsewhere on this site (see Study Next).

The exam-relevant insight is less about the phase names themselves and more about which concrete artifact backs each phase in a real Claude deployment: a labeled eval suite backs "test," a pinned model ID plus a pinned agent version backs "deploy," and the Admin Usage & Cost API plus SDK-level request logging backs "operate." An architect who can't name the artifact behind a phase hasn't actually operationalized the lifecycle - they've just recited its name.

Test - evals as a first-class artifact, not an afterthought. Define success criteria that are specific and measurable (task fidelity, consistency, tone, latency, price), then grade test cases via exact-match, cosine similarity, ROUGE-L, or LLM-based grading (Likert or binary). Anthropic's stated best practice: "use a different model to evaluate than the model used to generate the evaluated output" - grading with the same model that produced the answer risks self-preference bias contaminating the score. The Console also ships an interactive Evaluation tool for pre-ship testing. For grading methodology and dataset design in depth, see the evaluation concept page - see Study Next.

Deploy - model IDs are pinned snapshots, not evergreen pointers, from the 4.6 generation onward. Dateless IDs like claude-sonnet-5 or claude-opus-4-8 are each one fixed weight snapshot forever: "Anthropic does not update the weights or configuration of an existing model ID. When an updated version is available, it ships under a new model ID." This is the opposite behavior from pre-4.6 models, which used dated IDs (claude-sonnet-4-5-20250929) plus a *separate*, undated alias (claude-sonnet-4-5) that silently rolls to the latest dated snapshot for that minor version - pinning the alias instead of the dated ID is a real production risk on legacy models. Every model ID, dated or dateless, carries its own independent deprecation schedule, and serving infrastructure (routers, safety classifiers, sampling logic) can shift observable behavior slightly even when the weights underneath haven't changed.

Deploy - server-side prompt/agent versioning with rollback, on Managed Agents. agents.update() requires the agent's CURRENT version as an explicit argument, not just the fields you're changing: agent = client.beta.agents.update(AGENT_ID, version=agent.version, system=V2_SYSTEM). That current-version argument is an optimistic-concurrency check - passing a stale version (someone else updated the agent since you last read it) returns a 409 conflict_error instead of silently overwriting their change; the pattern is fetch-then-update, not update-blind. Each successful call produces a new immutable version automatically, numbered sequentially (v1, v2, v3...) on the same agent ID. Production sessions pin explicitly: session = client.beta.sessions.create(agent={"type": "agent", "id": AGENT_ID, "version": N}, environment_id=ENV_ID); passing a bare agent ID string instead resolves to whatever the latest version happens to be, which is not recommended for production. Rollback requires no redeploy - it's just re-pinning the version field to a prior number, since "versions live server-side." Anthropic's own cookbook example makes the stakes concrete: a v2 prompt change dropped billing-ticket routing accuracy from 4/5 to 2/5 (a broadened routing rule over-captured billing tickets that merely mentioned API usage costs); re-pinning production sessions back to v1 immediately restored 4/5 accuracy, with zero code deployed.

Operate / maintain - usage and cost telemetry, plus request-level logging. The Admin Usage & Cost API returns token usage bucketed by minute, hour, or day, sliceable by product, model, context window, or region - the concrete artifact that lets "maintain" decisions (which model to keep running, where cost is concentrated) be data-driven rather than anecdotal. SDKs separately expose a middleware/interceptor hook that runs before a request is sent and after a response is received, for request-level logging independent of the Admin API's aggregate view.

Worked full-cycle example. A support-ticket router on Claude: plan (routing-accuracy target, latency budget) → develop (system prompt) → test (a labeled-ticket eval set, exact-match or LLM-graded, per the develop-tests methodology above) → deploy (pin the model ID, e.g. claude-sonnet-5; ship the prompt as an immutable agent version pinned by production sessions) → operate (per-model token/cost visibility via the Admin API; request logging via SDK middleware) → maintain (a PM edits routing rules to v2; v2 is evaluated against the same labeled set before any session is re-pinned to it) → if v2 regresses in production the way the cookbook's own billing example did, rollback is just re-pinning sessions to v1, no redeploy required.