The Three-Owners Lens: Who Should Actually Do This Step?

Sequential, parallel, routing, and recursive decomposition answer one question about a decomposed problem: how should the steps be arranged relative to each other? There is a second, entirely separate question that arrangement doesn't answer: who should own each step once it's carved out? This is the ownership lens, and it is complementary to -- not a replacement for -- the four-technique toolkit. You can (and usually should) apply both lenses to the same decomposed task: arrange the steps with sequential/parallel/routing/recursive logic, then assign each resulting step to an owner using the framework below.

The Three Owners

Every discrete task that falls out of a decomposition belongs to exactly one of three owners:

• What Claude does -- the step genuinely requires language understanding, synthesis, judgment under ambiguity, or generation. This is the model's home turf.
• What existing systems do -- the step is a deterministic lookup, calculation, transaction, or state mutation that a database, a rules engine, or an existing service already does reliably and cheaply. Routing this to Claude instead is paying LLM-call cost and introducing non-determinism for something a SELECT statement already solves.
• What humans do -- the step requires accountability that cannot be delegated, judgment the organization has decided must stay with a person, or a decision whose cost of being wrong is high enough that the organization wants a human name attached to it.

This mirrors, at the level of individual task steps, the same discipline Lesson 1.1 applies at the level of the whole system: don't reach for the model as a reflex when a simpler, cheaper, more reliable owner already exists for the job.

The Three Criteria That Justify Each Assignment

A three-owners assignment is a claim, and like any claim in this domain, it needs to be justified rather than asserted. Three criteria do that justification:

A step assigned to Claude should be easily reversible, low-to-moderate stakes, and not require a specific accountable human to have made the call personally. A step that fails any of those three tests is a candidate to move to a human owner (if accountability or stakes is the blocker) or to an existing system (if the step is actually deterministic and Claude is solving a problem that doesn't need language understanding at all).

Worked Example: A Loan-Servicing Support Assistant

A loan-servicing company decomposes "handle an incoming borrower message" into steps and assigns owners:

• Classify the message intent (payment question, hardship request, general inquiry) -- Claude. Reversible (a misclassification just routes to the wrong specialized handler, easily corrected), low stakes on its own, no accountability concern.
• Look up the borrower's current balance and payment history -- existing system. This is a deterministic database read; routing it through the model adds latency, cost, and a hallucination risk for a fact that a direct query answers exactly, every time.
• Draft a response explaining the borrower's options for a routine payment-date change -- Claude. Reversible (a human or the borrower can push back before anything executes), moderate stakes, and accountability is satisfied because the borrower is only being informed, not committed.
• Approve a hardship forbearance that pauses payments for 90 days -- human. This step fails reversibility (once payments are paused and reported to credit bureaus accordingly, unwinding it is messy), fails stakes (a wrong call has real financial and regulatory consequences for both the borrower and the lender), and fails accountability (loan-servicing regulation in many jurisdictions requires a named human decision-maker for hardship determinations) -- all three criteria point the same direction, which is the strongest possible signal that this step does not belong to Claude.

Notice that the *same* three-owners lens, applied to four different steps inside one decomposed workflow, produces three different owners. That's the point: ownership is a per-step decision, exactly like model-tier selection in Domain 2 is a per-step decision, not a single answer applied to the whole task.

How This Interacts With the Four Decomposition Techniques

The four-technique toolkit (sequential, parallel, routing, recursive/hierarchical) decides the *shape* of a decomposed task -- which steps depend on which, which run concurrently, which get dispatched by category. The three-owners lens is applied *after* that shape exists, to each individual step inside it. A sequential chain might have its first step owned by an existing system (a deterministic data fetch), its second step owned by Claude (synthesis), and its third step owned by a human (final sign-off) -- the sequential arrangement and the per-step ownership are two independent decisions layered on the same decomposition.