Diagnosing the Right Workflow Pattern for a Document-Intake Pipeline
A team is building a pipeline that ingests incoming legal documents and needs to: (1) determine which of four document types it is (contract, NDA, invoice, other), (2) run type-specific extraction appropriate to whichever type was found, and (3) have a second LLM call double-check the extracted fields against the source document before anything is written to the database.
- Name the workflow pattern(s) present in this pipeline, stage by stage, and justify each with the distinguishing question for that pattern.
- A colleague argues stage 2 should be "orchestrator-worker" because "a worker handles each type." Explain precisely why that's the wrong name for what's described, and what it would take to actually make it orchestrator-worker.
- Is this pipeline, as a whole, an agent? Justify using the agency-levels framing.
1. Pattern per stage
Stage 1 (determine document type) is routing: a classifier decides which of four known, fixed categories the document belongs to, then dispatches to exactly one downstream path. The distinguishing question — "is the input one of a small number of known categories needing different handling" — is answered yes, and the menu of four types is fixed and enumerable in advance.
Stage 2 (type-specific extraction) is the routing pattern's destination, not a separate pattern of its own — each of the four types gets its own extraction prompt/logic, which is exactly what "dispatch to a fixed menu of known paths" means. Whether extraction itself is one call or a small chain per type is a separate detail that doesn't change what pattern stage 1→2 together represents.
Stage 3 (a second call checks the extraction against the source) is evaluator-optimizer: one call generates (the extraction), a separate call evaluates it against the source as the quality bar. If the description had included "and re-extract if the check fails, up to N times," that loop-back would still be evaluator-optimizer — bounded, around one artifact, with a fixed iteration cap — not evidence of anything more autonomous.
2. Why stage 2 isn't orchestrator-worker
Orchestrator-worker's defining property is that the decomposition itself — how many sub-tasks, and what each one is — is decided dynamically, at run time, by an LLM call looking at the specific input, because the shape of the decomposition isn't enumerable in advance. Here, the four document types and their four extraction procedures are fully known and fixed before any document arrives — there are always exactly four possible paths, chosen by a classifier, not a dynamically-decided number of worker sub-tasks. That's the textbook definition of routing, not orchestrator-worker. To actually make this orchestrator-worker, the task would need to change so that a single document could require a variable, not-fully-enumerable set of sub-extractions decided at run time — for example, "read this document and decide for yourself how many distinct clauses need separate extraction, then extract each" would genuinely be orchestrator-worker, because the number and shape of "workers" isn't fixed by a four-item menu.
3. Is the pipeline an agent?
No — it's Level 1, a fixed workflow, throughout. Every control-flow decision (which of four paths in stage 1, whether to re-run stage 3 up to N times) is decided by code written in advance, not by a model deciding its own next step at run time in an open-ended way. Nothing in the description has the model deciding what kind of step to take next from an open set of options, which is the Level 2 threshold. Calling this "an agent" because it involves three LLM calls chained together is exactly the imprecision the agency-levels framing exists to prevent.
Share this question