What you need to know
Decomposition is the step between "here is the business process" and "here is the architecture". Done well, it makes every later decision easier: each piece can be given to the right owner, tested on its own and replaced without disturbing the rest.
First cut: who owns each piece
Every solution has three possible owners.
| Owner | What it should own | Examples |
|---|---|---|
| Claude | Language work: reading, extracting, classifying, summarizing, planning, drafting | Read a free-text complaint and identify the product and issue |
| Existing systems | Deterministic logic and authoritative data the business already trusts | Account balances, eligibility rules, pricing, the record of truth |
| People | Judgment, exceptions, approvals, decisions where being right matters more than being fast | Approving a large refund, deciding an unusual claim |
The most frequent mistake is to give everything to Claude because it can attempt everything. Over-assigning makes the system more expensive, slower, harder to audit and less accurate on precisely the tasks existing systems already do well.
Second cut: how to split Claude's share
Once you know what Claude owns, split that work along natural seams. Each seam maps to a workflow shape from lesson 1.3.
- By stage: when one result feeds the next (extract, then classify, then summarize). This becomes a chain, and you can test each stage separately.
- By input type: when different kinds of request need different handling. This becomes a router.
- By independent unit: when the same task applies to many separate items, such as one per document or one per region. This becomes parallel work or subagents.
- By draft and check: when quality can be verified but one attempt is not reliable enough. This becomes an evaluator-optimizer loop.
Check each piece against the model's limits
For every piece Claude owns, ask the four feasibility questions from lesson 1.1:
- Does it need precise values? Then the value comes from a system or from code, and Claude only works with it.
- Does it need current or specialized knowledge? Then bring that knowledge in through retrieval or a tool.
- Does the input fit in the context window? If not, split it further or load it progressively.
- Is the instruction concrete and checkable? If not, sharpen it, or move the logic into code.
Put people where the stakes are
Human steps are part of the decomposition, not a patch added at the end. Place approval at the point where a decision becomes consequential or irreversible, such as issuing money, changing a record of truth, or sending something on the company's behalf. Routine, low-risk outputs can flow without review, which keeps reviewers focused on what matters.
In the exam
Decomposition questions usually describe a business process and ask which division of responsibilities is best. The right option gives language tasks to Claude, authoritative data and rules to existing systems, and consequential approvals to people, often with low-confidence cases routed to review. Watch for options that send authoritative checks to the model, remove a required human approval for speed, or make a person retype work that Claude could safely prepare.
Check your understanding
In a claims process, which task should stay with the existing policy administration system?
Show answer
Answer: D. Whether a policy was in force is an authoritative fact held by the system of record. The other three are language tasks that suit Claude.
A lending assistant must quote the monthly repayment for a given rate and term. How should the figure be produced?
Show answer
Answer: C. Exact figures belong to deterministic code or the system that owns the calculation. Claude adds value by explaining the result, not by being the calculator.
Which way of splitting Claude's work naturally becomes a routing workflow?
Show answer
Answer: B. Different kinds of input needing different handling is the cue for routing. The others map to parallel work, an evaluator-optimizer loop and a chain.
Apply it: Decide who owns each step
St. Aldric wants Claude to help with discharge summaries. Take the seven steps of today's process from the case and decide who should own each one: Claude, an existing system, or a person.
- Assign an owner to each of the seven steps, with a one-line reason.
Why: over-assigning to the model is the most common decomposition mistake. - List the values that must come from a system of record, never from the model.
Done when: every value a wrong guess could harm a patient with is on the list. - Place the human checkpoint and say what the physician sees when they review.
Show model answer
1. Owners
| Step | Owner | Reason |
|---|---|---|
| Gather the stay's notes | EHR (FHIR API) | Retrieval of records is a system task |
| Write the hospital course, list diagnoses and procedures | Claude drafts | Summarizing long notes is a language task |
| Discharge medication list | Pharmacy system | The reconciled list is authoritative; Claude copies it in, never edits it |
| Pending results | EHR query | A live fact, not something to infer |
| Follow-up instructions and appointments | Claude drafts the instructions; scheduling system books | Plain-language writing suits Claude; booking is a transaction |
| Review and sign | Physician | Clinical accountability, required by policy |
| Assign codes | Certified coders, using the coding system | Coding is a regulated professional task |
2. Values from systems of record: patient identity, medications and doses, allergies, pending results, appointment dates and times, and the signing physician.
3. Checkpoint. The physician reviews before anything is sent. The review screen shows the draft next to the source notes, with each statement in the hospital course linked to the note it came from, the medication list marked "from pharmacy, not editable here", and a clear "Sign" action that records who signed and when.