Delegation: Deciding What Claude Should Handle in a Use Case

1.Delegation starts with the problem, not the tool

A sponsor says, "Can Claude do our invoice-query triage?" That is a requirements question before it is a technology question. The AI Fluency framework handles it with the competency called Delegation: "Delegation involves deciding what work should be done by humans versus AI." The builders course groups Delegation and Diligence as the outer loop, which "guides bigger decisions about when and how to use AI", as opposed to the inner loop of Description and Discernment, which guides daily interactions with AI.

Delegation has three sub-components: "Problem Awareness (understanding your goals), Platform Awareness (knowing your tools' capabilities and limitations), and Task Delegation (distributing work thoughtfully)". Their order matters. Problem Awareness comes first, because you need to be clear on the problem you are actually solving before reaching for a tool. Platform Awareness comes next, because you cannot decide what to hand to a tool you do not understand. Only then does Task Delegation share out the work.

In practice, the question changes from "should I use AI here?" to "I have a business problem. How do I break it down, and what role does Claude play in each part?" The builders course says the same: delegation means breaking the problem down first and then deciding what AI handles at each step. When you analyse a use case, you work at the level of individual steps. You almost never decide on the whole process in one go.

Breaking the problem down is itself work you can do with Claude. The builders course starts from questions such as who the users are, what outcome they actually need, and what the real constraints are. Claude Code's best-practices page shows a prompt pattern for this: ask Claude to interview you and "Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs." Its questions help you find gaps and edge cases you had not considered. You still decide which answers matter. The builders course also asks for statements of "done" that are "concrete enough that a stranger could tell you whether the finished product passes or fails", so a vague requirement is a gap to close before delegating.

Sources12345

2.Map how people do the work today

In a real workflow, Problem Awareness means finding out how the process runs now. Anthropic's ticket-routing guide is explicit: "Before you automate, it's crucial to understand your existing ticketing system." It tells you to start by looking at how your support team currently routes tickets, and it gives questions that work for almost any process you are analysing:

- What criteria decide which service level applies? - Does routing decide which support tier or specialist gets the item? - "Are there any automated rules or workflows already in place? In what cases do they fail?" - How are edge cases or ambiguous items handled? - How does the team prioritise?

These questions bring to light knowledge that lives in people's heads and nowhere in a document. The guide gives the reason: "The more you know about how humans handle certain cases, the better you can work with Claude to do the task." Skip this step and ask Claude for "the standard requirements" of a process, and you get a generic answer. It may read well, but it is not built from how your organisation actually works.

The same applies to the categories a process sorts work into. "A well-defined list of user intent categories is crucial for accurate support ticket classification with Claude." The guide adds that Claude's routing quality is directly proportional to how well those categories are defined. So the analysis has to produce clear, written categories. A vague list of categories is a requirements gap, and the model cannot fill it for you. The guide also warns that intent is rarely the only factor. Urgency, customer type, service levels and language may also affect how work is routed, so record those too.

Sources6

3.Good candidates, and decisions that stay with a person

With the current process mapped, you can test each step against Platform Awareness. Anthropic's use-case guides list the signs of a strong fit. In customer support, "Claude excels at handling a large number of similar questions efficiently, freeing up human agents for more complex issues." For classification, the ticket-routing guide compares Claude with traditional machine learning:

Fit is only half of the analysis. The other half is deciding what stays with a person. The builders course states the rule directly: learn "why delegating implementation is safe and delegating judgment is not". Its closing lesson puts it as "Delegate implementation freely. Keep empathy, judgment, and shipping in your hands." The course states the rule without defining judgment further, so the examples here are an illustration rather than the course's own list. Drafting, summarising and classifying look like implementation work. Deciding something the organisation must answer for, such as rejecting an applicant or approving a claim, is the kind of call you would want to keep with a person. A use case that removes the human review stage from that kind of decision may have delegated the wrong part.

The framework gives three ways to split the work: "Automation (AI does it, you check), Augmentation (you and AI work it together), or Agency (AI operates with latitude inside boundaries you set)". Even under Automation, a person still checks the work. A sound use case also states when Claude should hand back to a person. The customer-support guide treats this as something you measure: "This measures Claude's ability to recognize when a query needs human intervention and escalate appropriately."

Finally, keep the design proportionate. Anthropic's engineering guidance recommends "finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all."

Sources7689

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Use-case analysis starts by picking the AI tool and then finding work for it.Why is that wrong?

   Problem Awareness comes before Platform Awareness and Task Delegation. You get clear on the problem before choosing a tool, then break it into steps.

   Covered in Delegation starts with the problem, not the tool

2. 2.If Claude handles the high-volume part of a process well, it can also make the final consequential decision, such as which applications are rejected.Why is that wrong?

   Delegating implementation is safe. Delegating judgment is not. Consequential decisions keep a person in the loop, and the design should include an escalation path.

   Covered in Good candidates, and decisions that stay with a person