The Problem Behind the Problem: From Business Ask to Claude Solution

An architect’s first deliverable is not a diagram. It’s a clear statement of the problem worth solving, written before anyone reaches for a model. Most projects that fail technically were doomed at this step. They built a competent solution to the wrong problem, or automated something that never needed a language model at all. So take a sentence like “we want an AI assistant for customer support” and turn it into a design decision you can defend to the person paying for it.

The stated problem is rarely the real one

A business ask arrives compressed. “Customers wait too long for support” is a symptom, a budget line, and a half-formed solution all fused into one sentence. Your job is to pull them apart and find the problem underneath.

Start by refusing the solution embedded in the request. “We want a chatbot” is a proposed mechanism, not a problem. Ask what would be true if the mechanism worked: fewer tickets reaching a human? Faster first response? Lower cost per resolved issue? Each of those is a different system. A chatbot that deflects simple questions optimizes ticket volume; a chatbot that drafts replies for agents optimizes handle time; a chatbot that resolves refunds end to end optimizes cost per resolution and carries far more risk. The word “chatbot” hides all three.

The technique is to keep asking why until you reach something measurable and owned. “Support is slow” — why does that matter? “Customers churn and cancel.” How much, and which customers? “Enterprise accounts, and each one is worth six figures a year.” Now you have a problem with a number attached and a stakeholder who feels it. That number tells you how much system the problem can justify. Later, it tells you whether the system worked.

Watch for the problem that is really a data problem, a process problem, or an org problem wearing an AI costume. If support is slow because the knowledge base is three years stale, no assistant will save you: it will confidently retrieve wrong answers faster. If refunds are slow because three teams have to approve each one, the bottleneck is the approval chain, not the drafting of the reply. An honest architect names these out loud, because building a Claude system on top of a broken process just makes the breakage harder to see.

When Claude is the right tool, and when it plainly isn’t

The most valuable thing you can say in a design review is sometimes “this doesn’t need a model.” Reaching for Claude on every problem is the mirror image of the over-engineering trap from multi-agent orchestration. It’s sophistication for its own sake, paid for in latency, cost, and unpredictability you didn’t need.

Language models earn their keep on tasks with three properties: the input is unstructured natural language (or images, or documents), the task needs understanding, generation, or judgment rather than a lookup, and the space of inputs is too varied to enumerate as rules. Answering a customer’s freely-worded question against a corpus of policies fits all three. So does summarizing a long complaint, classifying a fuzzy intent, or drafting a reply in the right tone.

Now the honest counterweight. Several classic tools beat a model on their home turf:

• A rules engine wins when the logic is known and finite. “Refunds over $500 need a manager; refunds on final-sale items are denied” is a decision table. Encoding it as if statements is faster, free per call, perfectly auditable, and it never hallucinates an exception that doesn’t exist. Handing that decision to a model trades determinism for risk and gets nothing back.
• Classic ML wins when you have labeled data and a narrow, repeated prediction. Fraud scoring on structured transaction features, churn prediction, demand forecasting — a gradient-boosted model on tabular data is cheaper, lower-latency, and more accurate than prompting an LLM to reason about rows of numbers. Use the LLM where language is the input, not where a spreadsheet is.
• Plain search or a database wins when the task is retrieval, not reasoning. If the user wants their order status, that’s a SELECT, not a generation. Wrapping it in a model adds cost and a failure mode for no benefit. (Retrieval feeding a model is different; that’s RAG, and the model earns its place by phrasing and grounding the answer.)
• Deterministic code wins for anything that must be exactly repeatable — tax math, unit conversion, sorting, formatting. Give the model the tool; don’t ask it to be the tool.

The strongest architectures are usually hybrids: a model for the language-shaped parts, deterministic components for everything with a known-correct answer. In the bookshop platform, the model reads and phrases; a rules engine decides refund eligibility; a database returns order facts. Drawing that boundary well is most of the design.

Aligning the solution to business value

Once Claude is genuinely the right tool for part of the problem, you have to say which kind of value the design is chasing. You cannot maximize all of them at once. Think in terms of value pillars:

• Efficiency — doing the same work with less human time or fewer steps (deflecting tickets, auto-drafting replies).
• Cost reduction — lowering the dollar cost per unit of work (cheaper per resolved ticket).
• Productivity — making each person produce more (an agent that handles the routine so humans take the hard cases).
• Performance and SLAs — meeting hard targets on latency, availability, or resolution time.
• Transformation — enabling something the business simply could not do before (24/7 multilingual support, or personalized help at a scale no headcount could reach).

These pull against each other, and that’s the point. The cheapest design (a small model, aggressive caching, no human review) may miss the quality bar. The fastest, highest-quality design (a large model, no caching, generous retries) blows the cost SLA. Choosing which pillar leads is the architectural decision. It drives everything downstream: model selection, whether you add a human-in-the-loop gate, how much you spend on evaluation, how hard you optimize latency. An architect who can’t name the lead pillar can’t defend a single tradeoff. Every tradeoff is only right or wrong relative to what you’re optimizing for.

Name it explicitly, and get the sponsor to agree. “This design optimizes cost per resolved ticket, accepting p95 latency of three seconds and routing anything low-confidence to a human” is a defensible position. “This design is good” is not.

The bookshop platform, decided

Run the method on our running system, the customer knowledge-and-support platform. The stated ask: “build an AI support assistant.” The real problem, once you dig: enterprise customers churn when support is slow, and each account is worth six figures. Meanwhile the support team is drowning in repetitive questions that pull them off the hard, relationship-saving cases. The measurable target is resolution time and the share of tickets resolved without a human, weighted toward the high-value accounts.

Is Claude the right tool? For the language-shaped core, yes, decisively: understanding a freely-worded question and answering it against policies, catalog, and help articles. Nothing else reads unstructured questions and grounds answers in a corpus. But not for the whole thing. Refund eligibility is a rules engine, not a model judgment. Order status is a database read exposed as the lookup_order tool. The model orchestrates and phrases; the deterministic parts decide and fetch. That boundary is why process_refund is a tool with its own guardrails rather than something the model is trusted to reason through unaided.

Which pillar leads? Efficiency and productivity: free the humans from the repetitive tail so they focus on the accounts that churn. Two constraints bound that goal — a hard latency SLA so the assistant feels instant, and a cost ceiling so deflection actually saves money rather than moving it to the API bill. Transformation (always-on, every language) is a welcome second-order effect, not the thing we optimize. That single choice already tells us to favor a smaller model where quality allows, to cache the stable policy corpus aggressively, and to gate refunds behind human review rather than chase full autonomy. We haven’t drawn a box yet, and the design is already taking shape — because the problem, not the technology, is driving it.

What the exam is really checking

Domain 1 items in this area read as short business scenarios: a stakeholder wants X, here are the constraints, what do you do? The trap answers are the ones that skip this chapter. They jump straight to a model when a rules engine or classic ML is the better fit, they solve the stated problem instead of the real one, or they optimize a pillar nobody asked for. The credited answers do what you just did: find the underlying problem, check honestly whether an LLM is warranted, and tie the design to a named business value. If you can articulate the problem behind the problem and the pillar the design serves, these items stop being guesswork.

Next: the architectural patterns and how to choose — augmented LLM, workflow, and agent, and which shape fits which part of the platform.