- In short
- Multi concern request decomposition is the pattern of breaking a single message that raises several distinct issues into separate work items, investigating each one (often in parallel) against a shared context such as the customer record, and then synthesising one unified response that resolves every concern.
What multi concern request decomposition means
Real users rarely send tidy, single-question messages. A support ticket reads: "I was charged twice this month, I also cannot log in on my phone, and by the way can you add dark mode?" That is three different problems wearing one envelope: a billing dispute, an authentication bug, and a product request. Multi concern request decomposition is the discipline of opening that envelope, separating the contents into distinct items, and making sure each one is handled on its own terms before a reply goes out.
The pattern has three moves. First, decompose: identify every distinct concern in the message and turn it into a separate work item. Second, investigate: work each item, ideally in parallel, against a shared body of context so the findings are consistent with one another. Third, synthesise: fold the individual findings into one coherent response that speaks to all of them. Skip any move and the agent feels half-present, the way a human would if they answered only the loudest part of your email.
- Multi concern request decomposition
- A workflow pattern for messages that raise several issues at once. The agent splits the message into one item per concern, investigates each item (commonly in parallel) using shared context, and synthesises a single response that resolves every concern rather than only the first.
It helps to see decomposition as the difference between a transactional reply and a thorough resolution. A transactional agent treats the message as a single prompt to answer and moves on; a resolving agent treats the message as a bundle of commitments it owes the customer and is not finished until each one is met. That mindset shift is the real content of this knowledge point, and everything that follows, parallel investigation, shared context, synthesis, is machinery in service of it. Architects who internalise it stop asking "what did the customer ask" and start asking "how many things did the customer ask, and have I closed every one," which is exactly the lens the exam expects you to bring to a multi-part ticket.
Why agents drop concerns without it
Left to its own devices, a language model tends to anchor on the first or most emotionally charged concern and treat the response as complete once it has addressed that one. The double charge is alarming, so the model fixes on the refund, writes a confident paragraph about it, and never circles back to the login bug or the feature request. To the user it looks as though the agent simply ignored two thirds of their message.
Explicit decomposition is the antidote because it converts an implicit "answer the message" task into an explicit checklist of items that each demand a resolution. Once the concerns exist as separate items, the agent has a concrete completion criterion: every item must be addressed before the turn is done. This is the same reasoning Anthropic uses when describing why complex tasks benefit from being broken into well-defined subtasks rather than tackled as one undifferentiated blob.
Parallel investigation with shared context
Many concerns in a single message are independent of one another. The billing question does not depend on the login question, and neither depends on the feature request. When subtasks are independent like this, they can be investigated in parallel rather than one after another, which is exactly the parallelization pattern Anthropic's Academy lesson on the topic demonstrates. In an agent built on subagents, the coordinator can spawn one investigator per concern and let them run concurrently, each in its own context window, then collect the results.
The word that keeps the pattern honest is shared. Every parallel investigation must read from the same authoritative context, the customer ID, the account state, the order history, so that the findings line up. If the billing investigator and the login investigator silently assumed different customer records, synthesis would stitch together facts about two different people. Shared context is what lets you fan out for speed without fragmenting the truth, and it is why this knowledge point leans on coordinator responsibilities for the orchestration underneath.
Worked example: a three-part support ticket
The mechanics are easiest to see on a concrete ticket.
Worked example
A customer writes: I was charged twice in May, I cannot log in on my new phone, and can you add a dark mode. Walk through decomposition, parallel investigation, and synthesis.
Decomposition comes first. The agent reads the message and extracts three items: a duplicate charge to investigate and possibly refund, an authentication failure to diagnose, and a feature request to record. It pins the customer ID from the session as the shared context every item will use.
Now the investigations run in parallel. The billing investigator pulls the May invoices under that customer ID and confirms two identical charges, flagging a refund. The authentication investigator checks the same customer's login events and finds the new device was blocked by a security hold after several failed attempts. The feature investigator looks up dark mode in the roadmap tool and finds it is planned but unscheduled. Because all three read the same customer record, there is no risk of crossing wires between accounts.
Finally the agent synthesises. Rather than three disconnected replies, it writes one message: it confirms the duplicate charge and the refund, explains the device hold and how to clear it, and acknowledges the dark mode request with its roadmap status. The customer's whole message has been answered in a single coherent turn. Had the agent skipped decomposition, it would almost certainly have refunded the charge and gone quiet on the login and the feature, leaving two thirds of the ticket unresolved and a second round trip guaranteed.
Misconceptions to watch for
Misconception
If the user buries several issues in one message, it is reasonable for the agent to answer the main one and let them ask again about the rest.
What's actually true
Misconception
Investigating concerns in parallel means each investigator should gather its own context independently.
What's actually true
Dependent versus independent concerns
Parallel investigation is the default, but it is not always legal. Some concerns depend on the outcome of another, and dependent work must be serialised rather than run side by side. If a customer reports that they cannot log in and that they want to change their billing email, the email change may depend on first regaining access to the account, so investigating them in parallel would have one branch acting on state the other is still trying to establish. Anthropic's guidance on decomposition makes the same point: serialise dependent subtasks and parallelise only the independent ones.
The decomposition step therefore includes a quick dependency check. For each pair of concerns, ask whether resolving one changes the facts the other relies on. Where there is no such link, the concerns fan out concurrently for speed. Where there is, you order them so the prerequisite resolves first and its result flows into the dependent item. Getting this ordering right is what keeps a fast, parallel agent from producing self-contradictory results, and it connects this knowledge point to the broader skill of choosing a decomposition strategy.
Counting the concerns correctly
Decomposition can only succeed if you first detect how many concerns a message actually contains, and that is harder than it sounds. Concerns hide inside compound sentences, trail off as afterthoughts ("oh, and one more thing"), or sit implied beneath an explicit ask. A customer who says "my card was declined so I could not renew, and now my account shows expired" may be raising one issue or three, depending on whether the decline, the failed renewal, and the expired status share a single root cause.
A robust agent treats detection as its own deliberate step rather than a side effect of reading. It scans for every distinct outcome the customer wants changed, lists them, and resists the urge to merge two concerns just because they appear in the same sentence or to split one cause into several symptoms. Over-merging drops concerns; over-splitting wastes effort and can produce a disjointed reply. The aim is one work item per genuinely distinct outcome the user is asking for.
Synthesis is more than concatenation
The final move, synthesis, is where weak implementations betray themselves. Stapling three separate answers together is not synthesis; it reads like three different agents took turns. Real synthesis orders the concerns sensibly, usually leading with the one the customer cares most about, acknowledges each explicitly so nothing feels skipped, and draws connections where the findings relate, such as noting that the billing error and the account hold shared a single cause.
Good synthesis also reconciles any tension between findings before the customer sees it. If the billing investigator recommends a refund while the account investigator notes the account is suspended, the unified reply should resolve the order of operations rather than presenting the two facts as an unexplained contradiction. This is the payoff of having investigated against shared context: because every item drew on the same customer record, their findings can be woven into one coherent narrative instead of clashing.
How this knowledge point shows up on the exam
Task statement 1.4 lives inside the customer-support resolution scenario, and this is its most operational knowledge point. At the apply Bloom level, a question will hand you a multi-part customer message and four candidate agent designs, asking which one resolves the request properly. The trap answer handles the first or most urgent concern elegantly and stops there; the correct answer decomposes the message, works the concerns against shared context, and synthesises one reply.
Look for two tells in the stem: a message that obviously contains more than one ask, and answer options that differ in how much of the message they cover. The decomposition mindset makes the choice quick, because you simply reject any design that cannot account for every concern raised. From here it is a short step to the related question of choosing a decomposition strategy for more complex workflows, where the same fan-out and fan-in thinking scales up.
A customer messages a support agent: my subscription renewed at the wrong price, the invoice PDF will not download, and I want to change my billing email. The team must pick an agent design. Which one best fits a multi concern request?
People also ask
How should an agent handle a request that contains several different problems?
Why do agents only answer the first issue in a multi part message?
What does parallel investigation with shared context mean?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Parallelization workflows
Why watch: Splitting independent concerns to run side by side is the parallel multi-concern decomposition this KP defines.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.