What You Need to Know
A business value pillar is the kind of return that a Claude solution is built to deliver. There are five pillars: efficiency, transformation, productivity, cost and performance SLAs (service level agreements). The request path is the work that happens while a user waits.
This lesson uses one made-up example throughout: a hotel chain. Its staff write every room description by hand and answer guest questions on its website. Each project that the hotel chain evaluates serves one pillar.
The Five Pillars, Precisely
- Efficiency: the same outcome with less input. It comes from automating repetitive work, shortening cycle times (the time that each case takes from start to finish) and reducing the number of times that a person handles each case. Automating an existing process is efficiency, whatever name the vendor's sales slides give it. The hotel chain already writes room descriptions, so drafting them automatically is efficiency.
- Transformation: capabilities that were not previously possible, such as new products, services, or decision speed that changes how the business operates. Transformation changes the business itself, beyond the speed at which the business runs today's process. An assistant that plans each guest's stay is a service the hotel chain has never offered, so it would be transformation.
- Productivity: people deliver more and better work with AI assistance. It is measured as output per person, quality per review and how fast new staff become competent. An example is a new member of the reservations team who answers guest questions with Claude's help.
- Cost: unit economics, meaning the cost per task compared with the human or legacy baseline. Model right-sizing (choosing the smallest model that meets the required quality), caching and batching control this cost. For the hotel chain, unit economics is the cost of each room description compared with the staff time that the description replaces.
- Performance SLAs: contractual latency, availability and quality targets that the architecture is engineered to meet, such as a response time for the hotel chain's guest assistant.
One question separates efficiency from transformation: does the capability already exist in the business? Making an existing capability faster is efficiency. Making a capability newly possible is transformation. Productivity applies to assisted people, not automated processes.
Every Decision Names Its Pillar
Professional-grade architecture ties each major design choice to the pillar it serves and to how that choice is measured.
- Model selection is a cost and performance decision for each task, not a decision about prestige. Set criteria for capability, speed and cost. Benchmark against your own evaluation set (test cases from your own task), and choose a model of the right size. The smallest model that meets the required quality serves the cost pillar without losing quality. Anthropic's model-selection guidance supports starting either efficiency-first or capability-first. The guidance never supports using the largest model by default without criteria. If a small model writes room descriptions that pass the hotel chain's own checks, that small model is the right choice.
- Prompt caching makes cached input tokens at least 90% cheaper to read than normal input tokens, and it improves latency. Lesson 2.5 gives the read price for each model. These benefits apply when static content (system prompt, policy documents, tools) is at the start of the prompt and dynamic content follows it. The static part repeats on every request, so it is the part that caching reuses. The hotel chain puts its cancellation policy and tools first and the guest's question last. Caching then serves cost and the latency SLA at the same time.
- Batch processing halves the cost of work that tolerates an asynchronous result. It serves the cost pillar, but the result arrives later. That is acceptable because nobody is waiting for the result. Rewriting every room description overnight suits a batch. A batch does not suit a guest who is waiting on the website.
- Multi-agent architectures multiply token use by roughly 15× (objective 1.4). Name the pillar that justifies this token cost, or the design is speculative.
Key Concept
The two cost-saving methods have opposite effects on latency. Caching helps repeated static prefixes (the static content at the start of each prompt) on the request path. Batching helps large amounts of asynchronous work outside the request path.
SLA Engineering
You design the system to meet an SLA. You do not assume that the system meets it.
- Latency: a p95 budget is the time within which 95 in every 100 requests must finish. The p95 budget divides into a budget for each stage of the pipeline (objective 1.2). The total time is the sum of the stage times. So a 3-second p95 with two sequential large-model calls in it does not fit. Tight budgets exclude long chains of model calls and steps that pass work between agents from the request path. The hotel chain's guest assistant uses one call and stays within its budget.
- Availability: targets force fallback design. Degraded modes (reduced service that still works), queuing and human fallback keep the service inside its SLA when the model call or a dependency fails. If the model call fails, the guest's question can queue for a member of staff.
- Quality: minimum accuracy targets require evaluation tools (Domain 4) that are connected to the feedback loop. A quality SLA that nobody measures means nothing, because nothing shows whether the system meets it.
The Value Case
Before you build, set a baseline: measure the current cost, time and quality of the process being improved. Before building, state the value hypothesis: which pillar, which metric, what target, and how it is measured. Verify it after the build. The hotel chain times a hand-written room description now, so automation has a figure to beat.
In the exam
The Professional credential exists because businesses pay for Claude solutions. The exam guide names the five pillars. This objective tests two things: naming the pillar that an initiative serves, and making design decisions that respect a stated cost or SLA constraint. Four patterns recur.
- Questions that ask which pillar applies offer similar pillars as wrong options. Ask whether the capability already exists in the business.
- Wrong options confuse the two cost-saving methods. The classic example is a wrong option that offers batch processing for an interactive use case.
- Batching lowers cost, but in exchange its results are too slow for the request path. The exam expects you to recognise this trade instantly. Caching serves cost and the latency SLA together. That is why caching appears in the guide's own sample questions.
- An architecture that cannot name its pillar and its measurement is speculative. At Professional level, a speculative architecture is a failing answer.
Exam Traps
Defaulting to the most capable model for every task in the system
Model choice is a per-task cost/performance decision made against criteria and your own benchmarks. The smallest model meeting the required quality serves the cost pillar without losing quality.
Classifying the automation of an existing process as transformation
Speeding up or automating what the business already does is efficiency. Transformation means a capability that was not previously possible. If you cannot choose between the two, ask whether the capability already existed.
Offering batch processing for an interactive use case, or caching for one-off asynchronous volume
The two cost-saving methods have opposite effects on latency. Caching serves repeated static prefixes on the request path. Batching serves large amounts of asynchronous work outside the request path, at half cost. Using one in place of the other does not meet the stated constraint.
Accepting a chain of sequential large-model calls against a tight p95, or an availability target with no fallback
Stage times sum, so a 3-second p95 with two sequential large-model calls in it does not fit. Sum the stage budgets first, then move model calls off the request path. For availability, design queuing or human fallback.
Practice Scenario
A bank wants a customer-email drafting assistant for its relationship managers, with a p95 latency of 3 seconds and a strict maximum cost per email. Which design best fits the constraints?
Build Exercise
Write the Value Case and SLA Budget
What you'll learn
- How to name the pillar a solution serves with a metric, baseline, and target
- How to build a unit-economics model including caching and batching effects
- How to decompose a p95 latency target into per-stage budgets
- How to design the fallback chain (the ordered steps that the service takes when the model call fails) that keeps a service inside its availability SLA
- Take a proposed Claude solution and name the primary pillar it serves, with a metric, baseline, and target
Why: The value hypothesis comes before the build. A pillar with no metric is an empty claim. The exam and the business both want the measurement.
You should see: One sentence: pillar, metric, current baseline, target, and how it will be measured.
- Build the unit-economics model: tokens per task, monthly volume, model pricing, and the effect of caching or batching where applicable
Why: Cost is a pillar, and it is engineered through right-sizing, caching, and batching. The model shows the effect of each of these cost-saving methods.
You should see: A small table: baseline cost per task and monthly total, then the same with each applicable cost-saving method applied.
- Decompose the end-to-end p95 latency target into per-stage budgets and check each stage fits
Why: A p95 budget is engineered by decomposition. This step shows which architectures are infeasible before they are built.
You should see: A per-stage budget line for input handling, context assembly, model call, output validation, and delivery — whose total fits inside the target.
- Design the fallback chain (the ordered steps that the service takes) that keeps the service inside its availability SLA when the model call fails
Why: Availability targets force fallback design. A service with no degraded mode has an SLA no better than that of its least reliable dependency.
You should see: An ordered chain: retry policy, then the degraded mode (cached response, queue for human, explicit error), each with the user experience it produces.
- State what post-launch measurement would confirm or falsify the value hypothesis
Why: Verification checks the hypothesis that you stated before the build. This connects the pillar to the feedback-loop stage of the end-to-end architecture.
You should see: One sentence naming the measurement, its cadence, and the threshold that would make you reconsider the solution.
Sources
- Define success criteria and build evaluations — Anthropic
- Choosing the right model — Anthropic
- Prompt caching — Anthropic
- Batch processing — Anthropic