- In short
- The three-bucket decomposition splits a complex problem into what Claude handles, what existing systems handle, and what humans handle. The split is determined by how the model behaves on each piece of work, not by what is easiest to build first, and it comes before choosing an architecture pattern. A design that skips this step risks asking Claude to do work an existing system already does more cheaply and reliably.
Three owners for the pieces of a problem
Complex problems are rarely all one kind of work, and the first move in solving them is to split the problem into pieces and assign each piece an owner. The Claude Certified Architect - Professional (CCAR-P) exam treats the three-bucket decomposition as a remember-level skill because it is the step that precedes and shapes every pattern decision. The three buckets are what Claude handles, what existing systems handle, and what humans handle. Deciding which bucket each sub-task belongs in, before naming any pattern, is what keeps a design from asking the model to do work a database or a human already does better.
The split is not made by what is easiest to build first. It is made by how the model behaves on each piece of work: a piece that needs judgment and tolerates variance belongs with Claude; a piece with a guaranteed, deterministic answer or one owned by a system of record belongs with existing systems; a piece that needs human sign-off on a high-stakes decision belongs with a person. Owner follows behaviour, not convenience.
- The three-bucket decomposition
- Splitting a complex problem into three ownership buckets, what Claude handles, what existing systems handle, and what humans handle, based on how the model behaves on each piece of work rather than on build convenience. It comes before choosing an architecture pattern; skipping it risks asking Claude to do work an existing system already does more cheaply and reliably.
Owner follows behaviour, not build order
The determining question for each piece is how the model behaves on it. Where the work is genuinely judgment-heavy, extracting meaning, classifying ambiguous input, drafting, synthesising, Claude is the right owner, because that is where the model's adaptability earns its place. Where the work has a single guaranteed answer or is a live-state lookup owned by another system, the existing system is the right owner, because it is cheaper, faster, and reliable in a way the model is not. Where the work is a high-stakes decision that needs accountable review, a human owns it. Assigning a piece to Claude simply because "the AI can probably do it" ignores this behaviour test and often lands work in the wrong bucket.
The delegation map: reversibility, stakes, accountability
Behaviour tells you whether a piece is a fit for the model at all; three further tests decide whether Claude should own it outright, share it with a person, or hand it back entirely. The decomposition produces what the exam frames as a delegation map, and each assignment is justified against three questions. Reversibility asks whether a wrong call can be undone, since an irreversible action argues for a human gate. Stakes ask what a wrong call costs, because high stakes pull the work toward human sign-off. Accountability asks who must answer for the outcome, and work a named person is answerable for rarely belongs fully with the model. These tests sit on top of Claude's four behaviour properties, next-token prediction, knowledge boundaries, working memory, and steerability. The framing that matters is not "where can Claude help?" but "where do the four properties argue for Claude over the system that already does this well?", and the delegation map is where that judgement is recorded.
Decomposition precedes the pattern
The sequence matters as much as the split. Decomposition comes before choosing an architecture pattern, not after. The pattern, workflow, agent, augmented LLM, is a shape you fit to well-scoped work, and it can only be chosen well once you know which pieces Claude owns and how they relate. Choosing the pattern first forces it onto work that has not been scoped, producing a mismatch: an agent wrapped around a task that was mostly a deterministic lookup, or a workflow that has to reach into the model for something a system should own. The three-bucket split is the scoping that makes a good pattern choice possible.
Skipping the split is expensive
A design that skips decomposition risks asking Claude to do work an existing system already does more cheaply and reliably. Without the split, the natural tendency is to route everything through the model because it can technically do most things, which produces an expensive, probabilistic solution to pieces that a database lookup or a small function would have handled exactly. The three-bucket step is cheap insurance against that: it forces the question, for each piece, of whether an existing system already owns this, before the model is handed work it should never have been given.
What the CCAR-P exam trips candidates on
The exam tests two traps. The first is assigning a sub-task to Claude by default because "the AI can probably do it," without checking whether an existing system already owns that data or logic. The credited answer applies the behaviour test and routes deterministic or live-state work to the existing system rather than the model.
The second is choosing a pattern, such as workflow versus agent, before the three-bucket split is done, forcing a mismatched pattern onto poorly scoped work. The reliable reading insists on decomposing first, because the pattern can only fit once the pieces and their owners are known.
Worked example
A team is asked to build a system that, given a customer enquiry, looks up the customer's current account balance, decides whether they qualify for a fee waiver under a fixed policy, and drafts a personalised response. A designer immediately proposes 'an agent that handles the whole thing.' Apply the three-bucket decomposition first.
Decompose before naming the pattern, since jumping to "an agent for the whole thing" is the choose-the-pattern-first trap. There are three distinct pieces here, and each behaves differently. The account-balance lookup is live state owned by the banking system, so it belongs in the existing-systems bucket, fetched with a tool call, not reasoned about by the model. The fee-waiver eligibility decision follows a fixed policy with a single correct answer, so it is deterministic and also belongs with existing systems, in code, not routed through the model just because the policy is written in words. The personalised response is genuinely judgment-heavy and tolerates variance in phrasing, so drafting it is the piece that belongs with Claude.
Assigning owners by how the work behaves, rather than by "the AI can probably do it," keeps the balance and the eligibility check out of the model, where they would have been slower, costlier, and probabilistic on tasks that demand exactness. Only the drafting genuinely needs Claude.
With the buckets settled, the pattern choice becomes clear and well-scoped: a small workflow that calls the banking system for the balance, runs the eligibility rule in code, and then uses a single Claude call to draft the response, with a human gate if fee waivers are high-stakes. Had the team wrapped the whole thing in an agent first, it would have handed deterministic and live-state work to the model, exactly the cost the three-bucket step exists to prevent.
Common misreadings to avoid
Misconception
If Claude can probably do a sub-task, it belongs in the Claude bucket.
What's actually true
Misconception
You can pick the architecture pattern first and scope the work afterward.
What's actually true
How this shows up on the exam
Domain 1 questions on this knowledge point present a multi-part problem and ask how to structure it or which pattern fits. The reliable reading decomposes into the three buckets first, assigns each piece by how the work behaves rather than by build convenience, and only then chooses a pattern, keeping deterministic and live-state work with existing systems.
The three-bucket split consumes the architecture brief and the AI-shaped problem test, and it sets up recognising work that does not belong with Claude, dependency ordering in decomposition, and the human-bucket reasoning from automation vs augmentation.
A logistics system must: pull each shipment's current location from the tracking system, compute the exact delay penalty from a fixed contractual formula, and write a diplomatic explanation to the customer. Before choosing a pattern, how should the three-bucket decomposition assign these?
People also ask
What are the three buckets in AI decomposition?
Why decompose before choosing a pattern?
What determines which bucket a sub-task goes in?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
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.