From Business Problem to Claude Solution Design

1.Start with the business process, not the model

A business problem rarely shows up as a model specification. It shows up as a pain point: support tickets land with the wrong team, legal documents take too long to summarize, moderators can't keep up. Before you design anything, find out how the work is done today. Anthropic's ticket-routing guide is the model case. Before you automate routing, it asks how the team currently decides which SLA applies, whether routing picks the support tier or a specialist, which automated rules already exist and where they fail, how ambiguous tickets are handled, and how tickets get prioritized. Its reasoning is that the more you know about how humans handle certain cases, the better you can work with Claude to do the task.

The second question is whether an LLM is the right tool at all. For classification, the guide lists signs that Claude beats traditional ML. Traditional ML needs massive labeled datasets, while Claude can work from a few dozen examples. Claude adapts to changed or new class definitions without extensive relabeling. It handles unstructured text without heavy feature engineering, and applies rules when classes are defined by conditions rather than examples. It gives human-readable explanations for its decisions, copes better with outliers and ambiguous inputs, and classifies across languages without a separate model per language. If none of these apply, a simpler non-LLM solution may be the honest answer. The category design matters too: the guide says Claude's routing accuracy is directly proportional to how well-defined your categories are.

Sources1

2.Translate the goal into measurable success criteria

"Make support faster" isn't a requirement you can design against. Anthropic's evaluation guidance says that building a successful LLM application starts with clearly defining your success criteria and then designing evaluations to measure performance against them. Good criteria are specific, measurable, achievable and relevant. A weak criterion says the model should classify sentiment well. A strong one names an F1 score of at least 0.85 on a held-out set of 10,000 diverse posts, a 5% improvement over the current baseline.

Business problems almost never come down to one number. The guidance notes that most use cases need multidimensional evaluation along several success criteria, such as task fidelity, consistency, tone, privacy handling, context use, response time and budget. One well-formed target combines accuracy, toxicity, error severity and latency: an F1 of at least 0.85, 99.5% non-toxic outputs, 90% of errors being inconveniences rather than egregious errors, and 95% of responses under 200ms. In ticket routing, the guide tells you to work with the support team to set benchmarks. Some are specific to LLMs: classification consistency of 95% or higher, at least 80% accuracy on edge cases, and no more than a 5–10% accuracy drop in non-primary languages. Others are business outcomes that hold whether or not you use an LLM, such as routing accuracy, rerouting rate below 10%, escalation rate, and cost per ticket.

Sources21

3.Choose the simplest solution shape and a build path

Once the criteria exist, pick the least complex design that could meet them. Anthropic's agent guidance says agentic systems often trade latency and cost for better task performance, and that you should decide when that trade makes sense. A ticket router, for example, is a classification call. It isn't an autonomous agent.

The second decision is how much of the implementation you run yourself. Claude's use-case guides describe three paths. The Messages API gives you the most control: you write the agent loop and run your own tools and infrastructure. The Claude Agent SDK sits in between, providing the agent loop and tool execution in a process you operate. With Claude Managed Agents, Anthropic hosts the agent loop, tool execution and runtime for you. The trade is control against how much you offload.

Sources34

4.Map design decisions to cost, latency and quality

Every architecture decision has a business price. Anthropic frames model selection as balancing capabilities, speed and cost, and offers two ways to start. Cost-first: begin with Claude Haiku 4.5, test the use case thoroughly, evaluate against your requirements, and upgrade only where there are specific capability gaps. This suits prototyping, tight latency, cost-sensitive work and high-volume straightforward tasks. Capability-first: start with Claude Opus 5.5, tune prompts, evaluate, then lower effort or downgrade over time. This suits complex reasoning and work where accuracy outweighs cost. The guide notes that most workloads start with Claude Opus 5.5. If your evals at xhigh or max effort still fall short on demanding reasoning or long-horizon agentic work, the guide says to move to Claude Fable 5.1. A model swap isn't the only dial. Effort trades intelligence for latency and cost within a single model, and the docs say tuning it is often a better lever than switching models.

In production, cost becomes a first-class design constraint. Anthropic separates two kinds of levers. Free wins cut spend without touching quality: prompt caching, token hygiene, a prompt audit, batch processing at 50% off for work that can wait up to 24 hours, and workspace spend limits. Tradeoffs exchange cost for intelligence: model choice, effort, output caps and task budgets, an elapsed-time clock, and multi-model architectures. In Anthropic's measurements, prompt caching was the largest lever by a wide margin. So if a business asks for lower cost, look at the free wins before you accept lower quality.

Sources56

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.If a model's quality or latency is wrong for the job, the fix is always to switch to a different model.Why is that wrong?

   Effort trades intelligence for latency and cost within a single model, and the docs say tuning it is often a better lever than changing models.

   Covered in Map design decisions to cost, latency and quality

2. 2.One accuracy number is enough to define success for a business use case.Why is that wrong?

   Most use cases need several criteria at once, such as quality, consistency, latency, safety and budget, each measurable against a baseline.

   Covered in Translate the goal into measurable success criteria