Aligning solutions to business value

What each pillar means, and how to prove it

This task statement asks you to connect a design to value in five named ways. They overlap, but each points at a different sponsor, a different metric and different architectural levers. Getting the pillar right early shapes everything from model choice to where people stay in the loop.

Efficiency and productivity are easy to confuse. Efficiency asks how much a unit of work costs; its payoff is savings. Productivity asks what people achieve; its payoff is capacity — the hours come back only if they are redeployed to something valuable, which is a management decision, not a model output. Transformation is different in kind. Rakuten, in a customer story Anthropic publishes, reports cutting time to market for new features from 24 days to 5, and deploying agents across product, sales, marketing and finance with the stated aim of turning every employee into a builder. The first is efficiency; the second changes who can build, which is the transformation argument.

Build the case on your baseline, not a headline

Published productivity figures are useful context and poor evidence. Anthropic’s own study of 100,000 anonymised Claude.ai conversations estimated that Claude sped up individual tasks by about 80%, on tasks that would otherwise take around 90 minutes. The same study is careful about its limits: it cannot see the time people spend outside the conversation checking Claude’s work, the tasks people bring are the ones they expect Claude to help with, and randomised controlled trials have typically found smaller savings, in a range of roughly 14 to 56%.

For an architect, the lesson is to measure the client’s own process. Record today’s baseline — handling time, error rate, cost per case, backlog — before the pilot. Measure the same things in the pilot, including the review time people spend checking Claude’s output. Set targets that are specific and measurable, as Claude’s guidance on success criteria puts it, and remember that its list of criteria includes latency and price alongside accuracy. The business case is the difference between the two measurements, not a number from a slide.

Cost: model the whole thing

Token cost is volume times tokens per task times price, and the architecture moves every factor. Claude’s pricing page lists the main levers. The Message Batches API halves the price of both input and output for work that can wait. Prompt caching bills a cache read at a tenth of the base input price, against a premium to write the cache (1.25 times for a five-minute cache, twice for an hour), so a large, stable instruction block pays for itself quickly. Smaller models cost a fraction of larger ones, which is why routing easy cases to a smaller model is a cost decision as much as a latency one. Output length matters too, because output tokens are priced higher than input.

Architecture can also multiply cost. Anthropic’s account of its multi-agent research system reports agents using about four times the tokens of a chat interaction and multi-agent systems about fifteen times, which is why 1.4 insists the task’s value justifies them. And the token bill is rarely the whole cost, or even the largest part: human review time, integration and maintenance, evaluation runs, monitoring and change management belong in the total cost of ownership too.

Performance SLAs you can actually keep

A service-level agreement is a promise about latency, throughput, availability or quality, and every one of them depends on the architecture. Claude’s latency guidance separates total response time from time to first token, the delay before output starts appearing; streaming makes a live interface feel responsive even when the full answer takes longer, and model choice, prompt length and a firm limit on output length all move the numbers.

Throughput is bounded by rate limits. The Claude API limits requests per minute and input and output tokens per minute, replenished continuously rather than reset each minute, so short bursts can hit the limit. For most models, tokens read from the prompt cache do not count toward the input-token limit, so caching raises effective throughput as well as cutting cost. Sudden traffic spikes can hit separate acceleration limits, so ramp up gradually. Workspace limits let you reserve capacity for a critical workload so an internal batch job cannot starve it. When a limit is hit the API returns an error with a header saying how long to wait, and the design needs a planned response.

Availability is the promise most often overstated. Standard API capacity is best effort. Anthropic’s service-tier documentation describes a Priority Tier, bought as a committed number of input and output tokens per minute for a specific model, with a 99.5% uptime target and requests above the commitment falling back to standard capacity. An end-to-end SLA to users therefore has to include fallbacks the architecture controls: queues, retries, a simpler model, a cached or static answer, or a human path.

Traps the wrong answers are built from

You should now be able to

• Distinguish efficiency, productivity, transformation, cost and performance-SLA arguments for the same solution.
• Choose KPIs that match the pillar a sponsor names, and baseline them before a pilot.
• Read published productivity figures critically, including their stated limitations.
• Build a cost model from volume, tokens and price, and apply batch, caching, routing and output limits.
• Translate a performance requirement into latency, throughput and availability design choices with fallbacks.