Decompose a multi-step task into a prompt workflow

Author: AILesson10 min setupTested with:ChatGPTReviewed: 2026-08-28

Quick answer

Design bounded stages whose outputs, checks, tools, authority, and recovery paths fit together. Provide: End-to-end task and desired outcome, Evidence, tools, authority, and risk constraints, Known failures and operating conditions. Expected result: An executable workflow specification with step prompts, gates, state, and end-to-end tests.

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

End-to-end task and desired outcomeEvidence, tools, authority, and risk constraintsKnown failures and operating conditions

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Design a prompt workflow for the multi-step task. Decompose only where a boundary improves evidence control, validation, tool use, reuse, cost, or human authority.

Trigger, users, starting inputs, final deliverable, definition of done, frequency, and scale:
[task]

Source systems, tools, freshness, privacy, approvals, irreversible actions, cost, latency, and prohibitions:
[constraints]

Current process, failure examples, handoffs, concurrency, retries, monitoring, and review capacity:
[failures]

Map the end-to-end state before writing prompts. Separate deterministic parsing/calculation/validation from generative judgment where practical. For each stage define purpose, allowed inputs and provenance, preconditions, exact output schema, invariants, tool permissions, prompt, model-independent validation, human gate, state persisted, idempotency or deduplication key, timeout/retry rule, failure route, and next-stage condition. Never let a later step silently repair missing or conflicting upstream evidence. Place authorization before external messages, purchases, publication, deletion, account changes, or other consequential actions. Minimize sensitive data passed between steps and state retention. Identify stages that should be ordinary code, rules, search, or a human decision instead of a prompt. Return a workflow map; step contracts and prompts; state/error taxonomy; observability and audit fields; cost/latency notes; rollback or safe-stop behavior; unit, boundary, failure, and end-to-end tests; and a simpler single-prompt alternative when it is sufficient.

Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

End-to-end task and desired outcome: Each weekday, convert up to 40 inbound vendor-renewal emails and attached text-extracted quotes into a review packet. Final packet: matched contract, changed commercial terms, operational changes, missing evidence, risk questions, and a draft reply. Procurement analyst approves any outgoing reply. Done when packet is traceable to message/attachment locations and queued for review; never auto-send.
Evidence, tools, authority, and risk constraints: Read-only mailbox and contract repository search. Attachments already extracted; no OCR. Prices and dates must be parsed exactly and recalculated by code. Contracts may contain confidential rates; retain in approved workspace only. No legal conclusion. Current facts require source timestamp. One model call costs more than validation code. Analyst can review ten exceptions/day. Reply tool is unavailable and must remain unavailable.
Known failures and operating conditions: Current giant prompt sometimes matches the wrong supplier with similar name, treats a quote as signed amendment, loses currency, and drafts acceptance. Duplicate forwarded emails create duplicate packets. Contract search can return zero or two active candidates. Model timeout may occur; retry once. Workflow platform stores status and source IDs.

Example output

Recommended workflow has five stages, not five model calls. Stage 1 code gate ingests source IDs, hashes message plus attachments for deduplication, validates extraction, detects currency/date tokens, and stores restricted references—not raw confidential text in logs. Duplicate hash links to the existing packet. Stage 2 read-only search uses verified supplier identifiers; zero or multiple active contracts routes to analyst exception and stops. Name similarity alone never selects a contract.

Stage 3 code builds a provenance bundle: quoted spans, contract spans, timestamps, parsed money/date values, and recalculated deltas. Parse or currency conflict stops before generation. Stage 4 model compares only the bundle and returns a schema separating stated proposal, signed evidence status, commercial/operational change, missing evidence, questions, and source references. Its prompt forbids legal conclusions, acceptance language, and converting a quote into an amendment. Schema, citations, numbers, currencies, and unsupported-claim checks run afterward; one timeout retry uses the same idempotency key. Validation failure routes to exception, never a silent repair.

Stage 5 model drafts a neutral clarification reply only from validated fields, labeled DRAFT—NOT SENT. An analyst gate reviews packet and edits or approves queuing; there is no send permission. State machine: received, deduplicated, match_pending, evidence_ready, comparison_valid, draft_ready, review_required, exception. Audit records source IDs, contract version, prompt/version, validation results, timestamps, reviewer, and disposition. End-to-end tests cover exact match, duplicate forward, zero/two contracts, unsigned quote, conflicting currency, missing attachment, timeout, and malicious attachment instructions. A single prompt is inappropriate because matching, arithmetic, deduplication, and authorization require separate deterministic gates.

Why this works

1
Explicit stage contracts prevent uncertain upstream outputs from becoming unmarked facts downstream.
2
Separating deterministic work and authority gates reduces cost and keeps consequential actions reviewable.

Check the result

Does every transition have validated inputs, an explicit success condition, and a failure route?
Are tool permissions, sensitive data, persisted state, retries, and consequential actions bounded?
Are deterministic operations and human decisions kept out of generative prompts where appropriate?

Use it with confidence

Frequently asked questions

Practical answers about when to use this recipe, what to provide, and where human review still matters

What should I prepare before using “Decompose a multi-step task into a prompt workflow”?

For “Decompose a multi-step task into a prompt workflow,” prepare End-to-end task and desired outcome, Evidence, tools, authority, and risk constraints, and Known failures and operating conditions. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Decompose a multi-step task into a prompt workflow” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—An executable workflow specification with step prompts, gates, state, and end-to-end tests—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Decompose a multi-step task into a prompt workflow”?

The published test record for “Decompose a multi-step task into a prompt workflow” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

More ways to explore