The four parts of every Claude solution
- Inputcapture, clean, check, add context
- Processingprompt, Claude, tools, code
- Outputstructure, validate, review, deliver
- Feedbackmeasure, capture corrections, learn
Production failures become eval cases → prompt or design change → regression test → release
Input: what reaches the model, and in what state
Enterprise inputs are messy: email threads with signatures and disclaimers, scanned PDFs, call transcripts, web forms, records spread over three systems. The input stage decides what Claude sees. It has four jobs. Capture the input from its channel (webhook, queue, scheduled pull, user interface). Clean it — strip boilerplate, split attachments, convert formats. Check it — size limits, required fields, language, whether it contains data this system is not allowed to process. Assemble context — add the customer record, the relevant policy passages, the template.
Context assembly deserves the most thought. Anthropic’s context-engineering guidance frames the goal as the smallest set of high-signal tokens that makes the desired outcome likely: more context is not better if most of it is irrelevant, because recall degrades as the window fills. Retrieval that brings in the three relevant policy sections usually beats pasting the whole policy manual into every request. Retrieval pipeline design is covered in 3.5 and 3.6.
Processing: Claude plus deterministic code
Processing is where the pattern chosen in 1.3 lives: a single call, a fixed workflow of calls, or an agent choosing tools in a loop. Whatever the pattern, the same rule holds — let Claude do the reading, judgement and writing, and keep calculations, lookups, business rules and permission checks in ordinary code or in tools that code controls. A quote, a refund limit or an eligibility threshold should come back from a system of record, not be generated.
Grounding belongs here too. Claude’s guidance on reducing hallucinations lists techniques that are really design choices: give the model explicit permission to say it does not know, restrict it to the supplied documents, have it extract direct quotes before analysing a long document, and require a citation for each claim so answers can be audited. None of them eliminates errors, which is why the output stage still checks.
One claim, end to end
check_cover(policy, peril)Output: structure, validate, gate, deliver
If the output goes to a person, prose may be fine. If it goes to another system, it needs a contract. Claude’s structured outputs feature constrains the response to a JSON schema you supply — through output_config.format for the response, or strict: true on a tool definition — so the downstream parser always receives valid, correctly typed fields. The documentation is clear about the edges: a refusal or hitting the token limit can still produce something unusable, and structured outputs cannot be combined with citations. So the output stage still validates business rules: totals add up, dates are plausible, the chosen category exists.
| Output concern | Design choice | Why |
|---|---|---|
| Another system consumes it | Schema-constrained JSON, then rule checks | Parsers need a contract; the schema cannot check business logic |
| A person must be able to verify it | Citations or quoted sources per claim | Reviewers check evidence faster than they re-read sources |
| Being wrong is costly | Human approval gate before release | Judgement and accountability stay with a named person |
| The user is waiting | Streaming to the interface | Perceived latency drops even when total time does not |
| Nobody is waiting | Batch processing | Half the price when the result can wait |
How should results be delivered?
- A customer, liveReal time, streamedtight latency budget
- An employee, within minutesQueued, asyncworker picks up, notifies
- No one until tomorrowMessage Batches50% discount, up to 24 h
The Message Batches API is the lever most often missed. Anthropic documents a 50% discount on standard prices, with most batches finishing in under an hour and a 24-hour limit. Nightly re-classification of a catalogue, bulk summarisation of the day’s calls, or running an evaluation set are natural fits; a live chat is not.
Feedback loops: how the system gets better
A system without a feedback loop is frozen on launch day while its inputs keep changing. Good designs have loops at three speeds. The inner loop runs inside one request: validation fails, the error goes back to Claude, it retries once; or an evaluator step checks a draft against criteria. The operational loop runs daily: people correct outputs, reviewers flag problems, low customer ratings trigger a look at the transcript. The improvement loop runs per release: failures from production become evaluation cases, the prompt or design changes, and a regression suite proves nothing else broke before rollout.
Open loop versus closed loop
Open loop
- Prompt tuned once before launch
- Human edits overwrite the draft and vanish
- Quality known only from complaints
- Prompt changes shipped on a hunch
Closed loop
- Edits and ratings stored with the original output
- Production failures added to the eval set
- Every change runs the regression suite first
- Metrics tracked against the success criteria
Anthropic’s guidance on agent evaluation describes this as layers, none sufficient alone: automated evals for fast, repeatable checks; production monitoring for real behaviour; A/B tests for real outcomes; user feedback for problems nobody anticipated; and manual transcript review to keep the graders honest. It recommends starting with 20 to 50 realistic tasks drawn from manual testing and user-reported failures — the feedback loop and the eval set are the same asset. Metrics, datasets and A/B testing are taught in Domain 4; observability in 3.4 and 4.6.
Traps the wrong answers are built from
| Tempting but wrong | Do this instead |
|---|---|
| Passing raw, unchecked input straight to the model | Clean, validate and reject bad input before the call; never ask Claude to invent missing facts. |
| Loading every document into every request “to be safe” | Retrieve the few high-signal passages the task needs. |
| Parsing free text from Claude into a downstream system | Constrain the output to a schema, then validate business rules in code. |
| Letting the model compute prices, limits or eligibility | Get those from systems of record through tools or code. |
| Launching with no way to capture corrections | Log outputs with human edits and ratings, and feed failures into the eval set and regression suite. |
You should now be able to
- Lay out an end-to-end design across input, processing, output and feedback for a business process.
- Decide what belongs to Claude and what belongs to deterministic code or systems of record.
- Choose output contracts, validation and human gates to match the consumer and the risk.
- Match delivery mode — streamed, queued or batched — to who is waiting for the result.
- Design feedback loops at request, operational and release speed that turn production failures into tests.