Agent workflow ordering: launch the long pole first, verify the receipt, do side work in parallel, then join
AI Agent Engineering & Reliability

Agent Workflow Ordering: Launch Long-Running Chains Before Side Tasks

A numbered step that says "do this first" is a promise. A checked receipt that refuses to proceed without it is a dependency. Only the second one survives a run that runs out of tools.

Core Concept

In a tool-limited autonomous workflow, launch the longest independent operation first — the critical path, the "long pole" — and make that launch a machine-enforced precondition with a durable receipt. Only after the chain is running should the agent do cheap side work (thumbnails, descriptions, drivers). If the agent can finish everything else and still never start the operation that determines completion, the ordering was prose, not a dependency.

The Measured Failure

A real BUILD run, 05:00 → 05:41
05:00
run starts
side work
done early
05:41
budget out
The prompt called the chain launch the long pole — but buried it at step 7. The agent finished the thumbnail, description, and drivers, then exhausted its tool-call budget before ever reaching step 7. Useful side artifacts shipped. The operation that determines completion never started.

Key Components

01

The Long Pole

The longest independent operation. It defines the critical path — if it never starts, nothing else you did matters for completion.

02

Launch Receipt

A persisted record of the launched job's identity — expected job or artifact name. Proof that launch happened, checkable later.

03

Side Work

Independent, cheap tasks (thumbnail, description, drivers) that run while the chain does its work in the background.

04

Join Gate

The final step verifies the chain actually completed — and every step after launch refuses to proceed if the receipt is missing or names stale work.

How It Works — Four Phases

1

Cheap Preflight

Validate inputs before spending anything expensive. Never launch an irreversible job on unvalidated assumptions.

2

Launch

Start the long-running chain first, and write the launch receipt recording the expected job or artifact identity.

3

Parallel Side Work

With the chain detached, produce thumbnails, descriptions, drivers — anything independent — while it runs.

4

Join & Verify Complete

Check the chain finished and the receipt matches today's expected item. If the receipt is absent or stale, stop — don't guess.

The Boundary

Longest-first is not universal scheduling. Dependencies still outrank duration. The correct order is: cheap validation → launch the validated long pole → independent side work. An expensive or irreversible job launched before its inputs are proven is not good ordering — it is a faster failure.

Where You'll Meet It

Video pipelinesStart the long encode/processing chain, then cut thumbnails and write descriptions while it renders.
DeploysLaunch the slow database migration as step one with a job id, then clean up logs and update docs in parallel.
CI / test suitesKick off the slowest test shard before building docs, so a budget cut can't strand the run that gates release.

Falsification Test

Give the workflow a tool budget that ends immediately after the side tasks. If the background chain is nevertheless alive and its receipt matches today's expected item, ordering is enforced. If no chain exists, the launch was prose rather than a dependency — and you now know exactly which one you built.

Checkpoint — answer before you move on

  1. Why is a numbered step that says "launch the chain first" weaker than a machine-checked launch dependency?Think about what happens when the run runs out of tools before reaching that step.
  2. What must the launch receipt contain, and what should every later step do if it's absent or names stale work?One field carries the proof. One verb describes the refusal.
  3. Name the boundary: when is "longest first" the wrong rule, and what should take priority over duration?It involves cheap validation before an expensive, irreversible launch.