From requirements to architecture

Requirements arrive as a paragraph from someone who does not know what a token is. Turning that into an architecture is a real sub-skill with real marks attached, and the good news is that it decomposes far better than it looks like it should. Three questions do most of the work.

Three questions, in this order

How big is the input, in tokens? Not pages, not megabytes. Tokens, because that is the unit both the context limit and the bill are denominated in. This answer picks your model id, since context window is a model property you cannot configure your way around. A 400-page contract does not fit in a 200k window no matter how clever the prompt is.

Is a human waiting? If yes: synchronous, streamed, and Batches is impossible. If no: Batches takes 50 percent off and you have just halved a line item by asking one question. The trap is work that sounds interactive because it appears in a UI but is actually generated overnight.

What happens when it is wrong? This is the requirement everybody forgets to write down and it is the one that determines whether you need citations, approval gates, strict tool use, or a human in the loop at all. "It writes a draft the user edits" and "it emails the customer" are wildly different systems built from the same API.

The order is load-bearing rather than stylistic. Question one fixes the model, and the model determines which features are even available. Question two fixes the transport, and the transport determines the interaction design. Answer them the other way round and you will design an interaction for a workload that turns out to be a nightly batch.

Non-functional requirements are where the design lives

The functional part of most Claude integrations is a paragraph. Everything expensive is non-functional: throughput, cost ceiling, latency budget, data residency, auditability, and what the failure mode looks like.

Map requirements to features, not to vibes

A short lookup table that covers most of what you will be asked:

"Must show where the answer came from" maps to citations. Not to a source field you invent.

"Must be valid JSON we can insert into a database" maps to structured outputs on a 4.5-or-later model. Not to a stern prompt and a retry.

"Must approve before acting" maps to owning the tool loop. No harness that hides the loop can satisfy it.

"The same 30k of policy documents go into every request" maps to prompt caching, and immediately to checking your model's cache minimum.

"We have sixty tools" maps to tool search, because sixty tool definitions is a context problem before it is anything else.

"It runs overnight over 50,000 records" maps to Batches, and to noticing that Batches is not available on any third-party platform, which may in turn decide where you deploy.

The systems life cycle bit nobody enjoys

Two lifecycle facts belong in every design document. Model ids retire on published dates, so a hardcoded dated id is a dependency with an expiry, and claude-opus-4-1-20250805 retires on 2026-08-05. And beta headers are versioned by date, so a feature you enabled today is pinned to a contract that will eventually be superseded.

Write both into the design as maintenance commitments rather than discovering them when a request starts failing. A system that cannot survive its own dependencies expiring was never finished.