Task decomposition for AI-enabled work: divide by evidence and control

Map the decision path

Write the final decision or deliverable at the top. Then work backward through the claims, calculations, source material, and approvals needed to support it. A subtask earns its own boundary when it has a distinct input, output, principal failure, or reviewer.

Useful boundaries often separate retrieval, extraction, normalization, calculation, interpretation, recommendation, communication, and external action. Avoid splitting work only to create more model calls. Every handoff adds opportunities for context loss, duplicated work, and error propagation.

The NIST AI RMF Core calls for documenting intended purposes, context, requirements, specific tasks, human oversight, testing, monitoring, and risk response. The framework is voluntary and under revision. It supplies useful questions for decomposition, but following them does not certify a workflow or establish safe operation.

Sources: [1]

Build an INPUT task map

Use five fields for every subtask:

Connect the subtasks with explicit handoffs. Preserve identifiers, units, dates, and source links as invariants. If a subtask cannot satisfy its output contract, it should emit a gap or stop condition rather than a plausible placeholder.

Microsoft's guidance on prompt engineering techniques describes breaking a task into smaller steps and gives an example in which facts are extracted before search queries are generated for verification. Treat that as a prompting technique to test, not a universal claim that more steps always improve results.

• Input: Name the source, schema, version, permissions, and freshness required.
• Need: State why this subtask exists and which downstream decision it supports.
• Procedure: Describe the transformation without asking for hidden reasoning or unsupported invention.
• Unit of output: Specify the artifact, fields, units, evidence links, and uncertainty markers.
• Test and owner: Define the acceptance check, responsible reviewer, and failure route.

Sources: [2]

Worked artifact: a synthetic service-backlog review

A fictional customer-operations team must prepare a weekly backlog review from a case export, service-level policy, escalation log, and staffing calendar. The original request asks an assistant to analyze the backlog and recommend priorities in one step.

The team decomposes the work into an INPUT map:

| Subtask | Input and need | Output unit | Test and owner | | --- | --- | --- | --- | | Validate export | Case rows and schema; establish usable population | Exception list plus retained row set | Data owner checks duplicates, missing IDs, and extraction time | | Classify obligations | Service policy and case attributes; identify applicable target | Case ID, target, rule citation, uncertainty | Policy owner reviews ambiguous categories | | Calculate age | Valid timestamps and calendar; measure elapsed service time | Reproducible age table with units | Analyst reruns a sample and checks time zones | | Join escalations | Escalation log keyed by case ID; expose elevated concerns | Matched and unmatched escalation table | Reviewer rejects name-only or subject-line matches | | Prepare options | Verified tables and staffing constraints; support prioritization | Three options with tradeoffs and unresolved gaps | Operations lead challenges assumptions | | Draft briefing | Accepted option set; communicate the decision | Briefing with claim-to-artifact links | Accountable manager approves communication |

During testing, the age calculation treats a missing closure timestamp as the current time and makes closed cases appear overdue. Because the calculation has its own output and test, the analyst finds the error before the recommendation stage. The repaired step distinguishes open, closed, and unknown status, preserves the raw timestamps, and reruns the sample.

The example is synthetic. It does not establish a service policy, staffing decision, or customer outcome.

Choose where AI belongs

Assign AI only where its contribution and failure can be observed. Deterministic joins, schema checks, or arithmetic may be better handled by ordinary code or spreadsheet formulas. AI may help classify ambiguous text or draft explanations, but those subtasks need evidence links and review criteria.

Keep recommendation and action separate. A system that drafts priority options should not automatically reassign cases, contact customers, or change a service record unless that authority is explicitly designed, tested, and approved. Use least-privilege access for each subtask.

Test recombination, not just the pieces

A collection of passing subtasks can still produce a poor final result. Test whether all material claims survive recombination with their source references, whether uncertainties remain visible, and whether one subtask's output is interpreted correctly by the next.

Inject failures such as a stale export, renamed field, duplicate identifier, missing policy section, conflicting escalation, time-zone shift, and unavailable reviewer. Measure where the failure is detected, whether the process stops safely, and which errors reach the final artifact. Version the task map, prompts, code, source pack, and checks together.

Assess decomposition judgment

A controlled assessment can provide a complex assignment, mixed evidence, limited tools, and a deadline. Observable evidence may include how the participant identifies dependencies, defines subtask outputs, preserves invariants, assigns checks, chooses between AI and deterministic tools, and recombines the evidence.

Do not infer broad competence from the number of subtasks or the use of a particular framework. Report only the behavior and artifacts observed in the scenario, along with missing evidence and confidence limits. Two Prune produces assessment evidence for human interpretation and does not make employment decisions.