Structured Stakeholder Discovery.

Discovery for a Claude-based solution is not a generic software requirements pass. It has to surface things traditional SDLC discovery skips entirely: whether the task is a fit for a nondeterministic system at all, what "good enough" output looks like (eval criteria), and which of the workflow/agent architecture patterns the problem actually needs. This is deliberately the STAKEHOLDER-FACING elicitation motion, not the written output that comes out of it - producing the actual requirements spec (functional requirements, infrastructure requirements, constraints, a success metric) is a separate, later step (see "Translating Business Requirements into Claude Solutions"). This concept is about how an architect runs the sessions, in what sequence, and what an architect must not skip while running them.

Anthropic's own enterprise playbooks frame this as the first phase of a "start small, evaluate thoroughly, scale gradually" methodology, not a big-bang requirements document: "Successful implementation of AI is iterative. Enterprises that are leading the way in AI transformation start small, evaluate thoroughly, and scale gradually before achieving their best results." A senior architect runs discovery to convert a vague business ask into a scoped pilot with success criteria attached, before any model or architecture decision is made.

Fit-for-nondeterminism is the first gate, not an afterthought. Anthropic's own planning guidance frames the right first use case as one "well suited to current generative AI capabilities, such as understanding text and sentiment, classifying intent, generating content, or solving a repetitive problem or task." If the stated ask doesn't clear that bar, that is a discovery finding to surface immediately, not a problem to discover later when the architecture doesn't work.

Discovery elicits the inputs that model and architecture selection will need, WITH the stakeholder - but the selection itself is a downstream, design-time activity, not something discovery decides. Anthropic names three levers a business stakeholder can reason about directly: Capabilities (does the task complexity fit), Cost and Speed, and Safety and Security. Discovery's job is surfacing which of these the stakeholder actually weighs most, so that the later architecture-selection step isn't an architect quietly picking a model tier alone and presenting it as a done deal. The weighting comes out of discovery; the actual pattern and model decision gets made afterward, once the elicited requirements and constraints are in hand.

Governance and stakeholder alignment come before pilots, not after. Anthropic's enterprise transformation guidance names "lay your AI foundation with clear governance and stakeholder alignment" (executive alignment plus an AI steering committee) as the first stage, ahead of launching targeted pilots. An architect who schedules executive buy-in only after a pilot already exists has the sequence backwards relative to Anthropic's own blueprint.

Discovery gathers non-functional requirements alongside the functional ask, not instead of it. Real deployments Anthropic cites (Coinbase's Claude-powered support handling thousands of messages per hour while maintaining 99.99% availability) show discovery outputs that include concrete NFR commitments - accuracy thresholds, latency, escalation policy - not just a functional "handle support" user story. A discovery session that only maps tool/API integrations has skipped this half.

Eval criteria get defined before build starts, not evaluated into existence afterward. Defining what "correct" output looks like up front is standard discipline for LLM applications, though the specific facilitation technique for eliciting it isn't itself a named, published Anthropic methodology - treat any specific elicitation script as something to verify against your own org's practice, while the principle (define success before you build) is well-grounded in Anthropic's own "establish specific, measurable success metrics" planning guidance.