What you will be able to do
- Name the five support lifecycle phases — discovery, design, handoff, monitoring, iteration — and map them onto the vendor's published Skill lifecycle (Plan, Create and review, Test, Deploy, Monitor, Iterate or deprecate)
- Run a discovery conversation that ends in measurable success criteria rather than a feature list
- Package a solution for handoff so another team can own it: registry entry, pinned version, rollback plan
- Decide from monitoring evidence whether a deployed workflow should be updated or deprecated
1.The lifecycle the documentation actually publishes
The clearest lifecycle Anthropic publishes for a deployed AI capability is the enterprise Agent Skills rollout. It is written for Skills, but it is the concrete worked example the documentation gives, and its stages line up one-for-one with the phases this objective names. Plan is discovery. Create and review plus Test is design. Deploy is handoff. Monitor is monitoring. Iterate or deprecate is iteration — with sunset treated as a first-class outcome rather than an afterthought.
Read the stages as gates, not as a schedule. Each one has an exit condition that must hold before the next begins: an approved evaluation suite before deployment, a passing evaluation run before a version is promoted. A solutions architect supporting a customer through this lifecycle is mostly enforcing those gates on behalf of a team that would rather skip them.
Sources1
2.Discovery: find the workflow, then define what good looks like
Discovery is not a demo. The Plan stage asks you to identify candidate workflows by a specific test — repetitive, error-prone, or demanding specialised knowledge — and then map those workflows to the organisational roles that perform them. That mapping matters later, because it is what stops a deployment from being one giant capability nobody can own.
The second half of discovery is agreeing what success means numerically before anything is built. The ticket routing guide models this well: it defines criteria such as routing accuracy, assignment time, first-contact resolution and rerouting rate, and it is explicit that these criteria are worth having whether or not a model is involved. Criteria chosen here become the thing monitoring watches in phase four, so a vague discovery guarantees a useless monitoring phase.
3.Design: build it, review it, and prove it under test
Design in this lifecycle covers two stages. Create and review is where the capability is authored against best practices, put through a security review, and made to arrive with its own evaluation suite before anyone approves it. The governance rule embedded here is worth memorising: authorship and review are separated, so a Skill author does not sign off on their own work.
Test is where the design claim is falsified. The documentation asks for two conditions — the capability alone, and the capability alongside everything already running — because a well-behaved unit can still degrade its neighbours by stealing their triggers. What you verify is triggering accuracy, output quality, and the absence of regressions across the whole active set. Testing in isolation only is the classic incomplete answer.
Phasing applies to rollout as well as to build. The Claude Design admin guidance gives the pattern in miniature: a small group validates the shared foundation first, and access widens only after a checkpoint is met.
A solutions team is scoping a new internal tool that must run long, asynchronous multi-step investigations across several backend systems, and the customer explicitly wants to avoid operating any agent-loop or sandbox infrastructure themselves. During the discovery phase, which approach should the team recommend?
Correct answer: B — Adopt Claude Managed Agents, since Anthropic operates the sandbox and session infrastructure needed for long-running asynchronous work
- A. Plausible for teams wanting full control, but requires the customer to build and operate orchestration infrastructure, which conflicts with the stated goal.
- B. Correct - Managed Agents runs the agent loop and sandbox on Anthropic-managed infrastructure, matching the requirement to avoid operating that infrastructure.
- C. The Agent SDK is a library that runs inside the customer's own process, so the customer would still be operating the runtime infrastructure.
- D. The Files API and prompt caching manage documents and context costs; neither provides the orchestration loop the tool needs.
4.Handoff: make someone else able to own it
Deployment is the handoff phase, and the documentation treats it as a documentation task as much as a technical one. Distribution through the Skills API makes the capability available workspace-wide; what makes it supportable is the registry entry recorded alongside it, carrying purpose, owner and version, plus dependencies and the date of the last evaluation. Without an owner recorded, the monitoring phase has nobody to route a regression to.
Two handoff details carry real operational weight. Production pins to specific versions, because omitting the version means whatever anyone uploads next immediately becomes what production runs. And the previous version stays available as a fallback, so a failed promotion is a revert rather than an incident.
Requests silently follow the latest upload. Anyone in the workspace publishing a new version instantly changes what production agents run — with no evaluation gate and no deliberate promotion. The documentation's rule is to pin production to a specific version and treat each update as a new deployment requiring full review, keeping the previous version as a rollback fallback.
Before any prompts are written, a consulting team meets with a client to scope a document-classification assistant. Which activity most correctly belongs in the discovery phase of the engagement?
Correct answer: A — Defining the use case, measurable success criteria, and an evaluation set for later validation
- A. Correct - discovery establishes what problem is being solved and how success will be measured before any design work starts.
- B. Locking a model and prompt is a design-phase activity, and doing it before requirements are defined skips discovery entirely.
- C. Cost optimization through caching and batching is a monitoring/iteration concern that comes after the solution exists.
- D. A deployment runbook is a handoff-phase artifact, produced only after the solution has been designed and tested.
Sources1
5.Monitoring: usage, feedback, and re-running the evidence
Monitoring has two halves. The passive half is tracking usage patterns and collecting user feedback. The active half is re-running the original evaluation suite on a schedule, because drift comes not only from the system but from the world around it — workflows change, and the underlying models change. A capability that passed at deployment is not thereby passing today.
This is also where the discovery-phase numbers earn their keep. A support-routing deployment measured against its rerouting rate has a standing signal that initial routing has degraded, expressed in the same units the stakeholder agreed to at the start.
One practical gap to know: usage analytics are not available through the Skills API, so tracking which capabilities are being invoked requires application-level logging you build yourself.
6.Iteration and deprecation: the phase that is allowed to end
Evaluation results are framed as signals for action, and the action depends on the pattern. A specific, diagnosable failure — declining trigger accuracy, conflicts with a neighbouring capability, weak output quality — points to an update: revise the description, narrow or consolidate scope, rewrite instructions, add validation steps. Every revised version goes back through the full evaluation suite before promotion, which is what makes iteration a loop back through design and handoff rather than a hotfix.
Retirement is the other branch, and the documentation states it plainly rather than treating it as failure. A capability is deprecated when its evaluations consistently fail across updates, or when the workflow it supported no longer exists. The second reason is the one teams forget: nothing is wrong with the system, the business reason for it has simply gone. Naming deprecation as a normal phase during discovery makes it far easier to reach later.
The lifecycle also shapes what you build early. Start narrow and workflow-specific, then consolidate related capabilities into broader role-based bundles once real usage shows the pattern — and only once evaluations confirm the merged version performs equivalently. Consolidating on intuition skips the gate.
A development team is designing an internal agent that must autonomously read repository files, run shell commands, and edit code without the team writing their own tool-execution loop. Which design choice fits this requirement?
Correct answer: B — Build on the Claude Agent SDK, which provides the built-in tools, agent loop, and context management out of the box
- A. The Client SDK gives direct API access, but the team would still need to implement the tool loop themselves, which the requirement explicitly avoids.
- B. Correct - the Agent SDK ships with built-in tools, the agent loop, and context management so the team does not implement tool execution from scratch.
- C. Calling the Messages API once per file without a tool loop cannot autonomously read files, run commands, or edit code as required.
- D. The Usage and Cost Admin API reports token usage and spend; it has no role in executing tools or orchestrating an agent.
Sources1
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Require the full evaluation suite to pass before promoting new versions.”
↩︎ The lifecycle the documentation actually publishes“Require an evaluation suite before approval.”
↩︎ The lifecycle the documentation actually publishes“Identify workflows that are repetitive, error-prone, or require specialized knowledge.”
↩︎ Discovery: find the workflow, then define what good looks like“Map these to organizational roles and determine which are candidates for Skills.”
↩︎ Discovery: find the workflow, then define what good looks like“Establish separation of duties: Skill authors should not be their own reviewers.”
↩︎ Design: build it, review it, and prove it under test“Verify triggering accuracy, output quality, and absence of regressions across your active Skill set”
↩︎ Design: build it, review it, and prove it under test“Document the Skill in your internal registry with purpose, owner, and version.”
↩︎ Handoff: make someone else able to own it“Production: Pin Skills to specific versions.”
↩︎ Handoff: make someone else able to own it“Rollback plan: Maintain the previous version as a fallback.”
↩︎ Handoff: make someone else able to own it“Track usage patterns and collect feedback from users.”
↩︎ Monitoring: usage, feedback, and re-running the evidence“Rerun evaluations periodically to detect drift or regressions as workflows and models evolve.”
↩︎ Monitoring: usage, feedback, and re-running the evidence“Evaluation results signal when to act”
↩︎ Iteration and deprecation: the phase that is allowed to end“Update Skills when workflows change or evaluation scores decline.”
↩︎ Iteration and deprecation: the phase that is allowed to end“Deprecate Skills when evaluations consistently fail or the workflow is retired.”
↩︎ Iteration and deprecation: the phase that is allowed to end“consolidate related Skills into role-based bundles”
↩︎ Iteration and deprecation: the phase that is allowed to end - 2.
“Here are some common success criteria that may be useful regardless of whether an LLM is used”
↩︎ Discovery: find the workflow, then define what good looks like“The rerouting rate indicates how often tickets need to be reassigned after initial routing.”
↩︎ Monitoring: usage, feedback, and re-running the evidence - 3.https://support.claude.com/en/articles/14604406-claude-design-admin-guide-for-team-and-enterprise-plansOfficial docs
“design system setup first, then broader access”
↩︎ Design: build it, review it, and prove it under test