1.1 · Lesson 1 of 6
Translate business problems into Claude-based AI solutions
What You Need to Know
Translating a business problem into a Claude-based solution starts with the problem — not the model card, the vector store, or a system prompt. Professional architects map goals, constraints, owners, and success metrics first, then decide where language judgment beats deterministic software. Vague asks like "AI on our CRM" are incomplete requirements, not architectures.
Claude fits judgment-heavy language work: drafting, summarizing, classifying ambiguous text, and guiding users through policy-shaped answers. Sorting rows, enforcing schemas, and applying fixed rate tables belong in code. Feasibility constraints (data access, latency, risk) shape what is possible; they are not the same as the solution shape you choose once the problem is clear.
What a solution brief must name
- Business problem and primary outcome owner
- Inputs, outputs, and explicit non-goals
- Measurable success criteria (not demo applause)
- Where Claude judgment applies vs where code is authoritative
- Hard constraints: data, latency, risk, and compliance
Decision rules
- Start from the business problem, not the model or stack.
- Capture inputs, outputs, owners, non-goals, and measurable success criteria before build.
- Claude fits judgment-heavy language work; keep deterministic ops in code.
- Separate feasibility constraints (data, latency, risk) from solution shape.
- Refuse vague "AI on X" asks until outcomes and non-goals are explicit.
Why framing comes before stack
Stack choices without a framed problem optimize for demos and vendor familiarity. On the exam, stems that name a vague AI ask key on reframing — owners, metrics, Claude-vs-code fit — not on picking the largest model or buying retrieval infrastructure first. Framing also prevents scope creep: non-goals stop the CRM assistant from becoming an unbounded write agent overnight.
Review checklist
- Is there a named outcome owner and a success metric they accept?
- Are inputs, outputs, and non-goals written down?
- Which tasks need Claude judgment vs deterministic code?
- What data, latency, and risk constraints bound the design?
- Would shipping a prompt-only demo satisfy the metric — or only impress a meeting?
Exam distractors push you toward models, RAG, or prompts while the problem is still vague. The professional move is a solution brief stakeholders can accept or reject before any implementation work.
Exam application
Vague stakeholder asks → frame problem, constraints, owners, and outcomes first. Prefer answers that separate Claude judgment from deterministic code and that refuse demo metrics as production success. Distractors: largest model, buy vector DB first, ship a system prompt without non-goals.
Exam traps
Jumping to stack before the problem is framed
Model, RAG, and tool choices are premature when goals, owners, and success metrics are undefined. Exam items reward framing first.
Assuming Claude for deterministic ops like SQL sorts or fixed field updates
Claude fits judgment-heavy language work. Keep deterministic transforms, sorts, and rule checks in code.
Skipping non-goals
Without explicit non-goals, scope expands into every CRM surface. Architects must say what the system will not do.
Conflating demo delight with production success criteria
A polished demo is not a metric. Production needs owners, latency/risk constraints, and measurable outcomes stakeholders accept.
Practice scenario
A VP asks for "AI on our CRM" with no success metrics, no owner for outcomes, and no statement of what should stay deterministic. What should the architect do first?
Build exercise
Frame a support-copilot business problem into a Claude solution brief
35 minutes
What you'll learn
- Interview for problem, owners, and constraints
- Split Claude judgment from deterministic code
- Define inputs, outputs, non-goals, and real metrics
- Ship a stakeholder-ready solution brief before build
Step 1
Interview for problem, owners, and constraints
Capture who owns the outcome, what pain exists today, data/latency/risk constraints, and what "done" means in measurable terms. Refuse to pick a model until this brief exists.
Why: Exam stems reward starting from the business problem, not the stack. Owners and constraints separate feasibility from wishful design.
You should see: A one-page brief: problem statement, primary owner, constraints, and draft success metrics.
Step 2
Separate Claude-shaped work from deterministic software
List candidate tasks. Mark language judgment (summarize, draft, classify ambiguous text) vs fixed transforms (sort, validate schema, apply a published rate table). Keep the latter in code.
Why: Claude vs code fit is a core architect decision. Using the model for SQL-style determinism is a classic trap.
You should see: A two-column table: Claude-fit tasks vs code-fit tasks, with one sentence rationale each.
Step 3
Define inputs, outputs, and non-goals
Specify allowed inputs, required outputs, and explicit non-goals (e.g. no direct CRM writes, no legal advice). Name success metrics that are not "users liked the demo."
Why: Inputs/outputs/non-goals bound scope. Demo applause is not a production criterion.
You should see: IO contract plus a non-goals list and 2–3 measurable metrics with owners.
Step 4
Write the Claude solution brief
Combine problem, Claude-vs-code split, IO/non-goals, and metrics into a short solution brief a stakeholder can accept or reject before build.
Why: Architects ship decisions, not vibes. The brief is the artifact exam-style scenarios imply you produce first.
You should see: A stakeholder-ready brief ready for design review — no model SKU required yet.
Sources
- Claude docs overview — docs.anthropic.com — start from capabilities before stack
- Build with Claude — docs.anthropic.com
- Models overview — docs.anthropic.com — choose models after the problem is framed