What You Need to Know
A business value pillar is the kind of return a Claude solution is built to deliver. There are five: efficiency, transformation, productivity, cost and performance SLAs (service level agreements). The request path is the work done while a user waits.
Take a used car dealer whose staff write every listing by hand and answer buyer enquiries on its website. Each project it weighs serves one pillar.
The Five Pillars, Precisely
- Efficiency: the same outcome with less input, by automating toil, compressing cycle times and reducing manual touches per case. Automating an existing process is efficiency, whatever the vendor deck calls it. The dealer already writes listings, 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. It changes the business itself, beyond how fast it runs today's process.
- Productivity: people ship more and better with AI assistance. It is measured as output per person, quality per review and faster time-to-competence for new staff, such as a new salesperson answering enquiries with Claude's help.
- Cost: unit economics, meaning cost per task against the human or legacy baseline. Model right-sizing, caching and batching drive it. For the dealer, that is the cost of each listing against the staff time it replaces.
- Performance SLAs: contractual latency, availability and quality targets that the architecture is engineered to meet, such as a response time for the dealer's enquiry assistant.
One question separates efficiency from transformation: does the capability already exist in the business? Speeding it up is efficiency. Making it newly possible is transformation. Productivity attaches to people assisted, not processes automated.
Every Decision Names Its Pillar
Professional-grade architecture ties each major design choice to the pillar it serves and how that will be measured.
- Model selection is a cost and performance decision per task, not a prestige decision. Establish capability, speed and cost criteria, benchmark against your own evaluation set, and right-size. The smallest model that meets the quality bar wins the cost pillar without losing the quality one. Anthropic's model-selection guidance supports starting either efficiency-first or capability-first. It never supports defaulting to the largest model without criteria. If a small model writes listings that pass the dealer's own checks, it wins.
- Prompt caching cuts cache-read cost by roughly 90% and improves latency when static content (system prompt, policy documents, tools) leads the prompt and dynamic content follows. The static part repeats on every request, so it is the part caching reuses. The dealer puts its warranty policy and tools first and the buyer's question last. Caching then serves cost and the latency SLA at once.
- Batch processing halves the cost of work that tolerates asynchronous completion. It serves the cost pillar and sacrifices request-path latency, because nobody is waiting for the result. Rewriting every listing in stock overnight suits a batch. A buyer waiting on the website does not.
- Multi-agent architectures carry a roughly 15× token multiplier (objective 1.4). Name the pillar that pays for it, or the design is speculative.
Key Concept
The two cost levers are directional opposites on latency. Caching helps repeated static prefixes on the request path. Batching helps asynchronous volume off the request path.
SLA Engineering
An SLA is engineered, not accepted on faith.
- Latency: a p95 budget (the time 95 in every 100 requests must finish within) decomposes into per-stage budgets across the pipeline (objective 1.2). Stage times sum, so a 3-second p95 with two sequential large-model calls in it does not add up. Tight budgets rule long chains and multi-agent hops off the request path. The dealer's enquiry assistant fits its budget with one call.
- Availability: targets force fallback design. Degraded modes, queuing and human fallback keep the service inside its SLA when the model call or a dependency fails. If the model call fails, the dealer's enquiry can queue for a salesperson.
- Quality: accuracy floors require evaluation machinery (Domain 4) wired into the feedback loop. A quality SLA nobody measures is fiction, because nothing shows whether it is met.
The Value Case
Baseline before build: measure the current cost, time and quality of the process being improved. State the value hypothesis before building (which pillar, which metric, what target, measured how) and verify it after. The dealer times a hand-written listing 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 an initiative serves, and making design decisions that respect a stated cost or SLA constraint. Four patterns recur.
- Which-pillar questions plant adjacent pillars as distractors. Apply the existing-capability test.
- Distractors swap the two cost levers. Offering batch processing for an interactive use case is the classic.
- The batching trade, lower cost for lost request-path latency, is one the exam expects you to spot instantly. Caching serves cost and the latency SLA together, which is why it appears in the guide's own sample questions.
- An architecture that cannot name its pillar and its measurement is speculative. At Professional level, speculative 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 quality bar wins the cost pillar without losing the quality one.
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. The exam plants adjacent pillars as distractors — apply the discriminator.
Offering batch processing for an interactive use case, or caching for one-off asynchronous volume
The levers are directional opposites on latency. Caching serves repeated static prefixes on the request path; batching serves asynchronous volume off it, at half cost. Swapping them fails the stated constraint.
Accepting a latency or availability target without decomposing it into per-stage budgets and fallbacks
An SLA is engineered: tight p95 budgets rule out certain architectures outright, and availability targets demand designed degraded modes. Hope is not a compliance mechanism.
Practice Scenario
A bank wants a customer-email drafting assistant for its relationship managers, with a p95 latency of 3 seconds and a strict per-email cost ceiling. 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 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 a slogan; 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 makes the levers concrete.
You should see: A small table: baseline cost per task and monthly total, then the same with each applicable lever 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 is where infeasible architectures reveal themselves before they are built.
You should see: A per-stage budget line for input handling, context assembly, model call, output validation, and delivery — summing inside the target.
- Design the fallback chain 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 its SLA set by 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 closes the loop the hypothesis opened. 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 trigger a rethink.
Sources
- Define success criteria and build evaluations — Anthropic
- Choosing the right model — Anthropic
- Prompt caching — Anthropic
- Batch processing — Anthropic