A task or subprocess invokes itself (or an ancestor process) during execution. The process decomposes hierarchically and terminates at a base case. Unlike a loop, each recursive invocation creates a new process instance with its own context — results propagate back up the call stack when base cases resolve.
An AI document decomposer processes large technical reports for long-context analysis. Any section exceeding 10,000 tokens is too large for a single model context window. The agent checks the section size: if it fits, it processes directly; if it is too large, it splits the section into subsections and spawns recursive sub-agents for each. Each sub-agent performs the same check — fitting subsections are processed immediately, oversized ones split further. Results propagate back up the tree and are merged at each level.
The key insight: the depth of decomposition is not known at design time — it depends entirely on the input document structure. A five-level deep legal contract and a two-level deep technical spec are handled by the same process definition. The recursion terminates when every leaf node fits the context budget. This is structurally impossible to express as a fixed pipeline or a counted loop.
| Metric | Signal |
|---|---|
| Recursion depth distribution | P50/P95/P99 depth per document type. Deep tail cases reveal base-case condition miscalibration. |
| Total agent instances per root invocation | Cost multiplier. Should scale sublinearly with document size if the base condition is well-tuned. |
| Merge quality score | Recall of leaf-level information in the root result. Measures merge loss compounded across levels. |
| Base case rate | Fraction of invocations that hit the base case directly. High rate means the recursion is rarely needed — consider relaxing the threshold. |
| Node | What it does | What it receives | What it produces |
|---|---|---|---|
| Check Section Size | Measures token count of the current section. XOR-split: routes to Process Section if within budget, or to Split into Subsections if oversized. This node also serves as the convergence point for recursive results (XOR-join). | Section text, token budget threshold (10k tokens) | Route token: "fits" or "too large" |
| Split into Subsections | Decomposes the oversized section into semantically coherent subsections. AND-split: each subsection spawns a recursive Check Section Size invocation in parallel. | Oversized section text | N subsection texts, each passed to a new recursive instance |
| Process Section | Base case handler. Runs full analysis on a section that fits the context window — summarization, extraction, or embedding generation. | Section text (confirmed within token budget) | Processed section result: summary, extracted facts, or embedding |
| Merge Subsections | AND-join: waits for all recursive sub-agent results, then combines them into a single section result. Mirrors the Split node — produces the same output format as a base-case Process Section call. | N subsection results from recursive instances | Merged section result (same schema as base case output) |
| Section Output | XOR-join: collects either a direct process result or a merged subsection result. Propagates the result up to the parent process instance. | Either processed section or merged subsections result | Section result ready for parent merge or final output |
| Origin of Value | Where it appears | How it is captured |
|---|---|---|
| Future Cashflow | Base case Process Section | All value is produced at the leaves. The Split and Merge nodes are pure overhead — they exist to organize work, not produce output. Value concentration at base cases means the quality of the base-case processor is the primary quality lever for the entire system. |
| Governance | Check Section Size condition | The token budget threshold encodes the model capacity constraint. Changing the threshold changes the decomposition depth and therefore the total agent cost. This is an architectural governance decision, not a runtime parameter. |
| Conditional Action | Split into Subsections | Each split multiplies the number of active agents. A two-level recursion on a document with binary splits at each level produces 4x base cases. Cost is exponential in depth — the base condition must be tight enough to prevent unnecessary depth. |
| Risk Exposure | Merge Subsections | Merge quality degrades with depth: a merge of merges of merges loses structural fidelity. If the final output at the root is a high-level summary, deep recursion may introduce summarization loss at every merge layer. The root result may be less accurate than a flat processing approach. |
VCM analog: Nested Work Token tree. The root token splits into child tokens at each recursive invocation. A child token cannot complete until all its own children complete. The root result is the aggregation of the entire token tree. The depth of the tree is unknown until all base cases have resolved.
A section that always produces subsections of the same size will never reach the base case. This happens when the Split node produces subsections by character count rather than semantic boundaries — a section of dense code may split into equally dense chunks that all remain over threshold. Fix: the base case must be guaranteed reachable. Either enforce a minimum split granularity (single sentences always pass), or add a hard depth limit that forces base-case processing regardless of size at maximum depth.
The Merge Subsections node must compress N subsection results into one result at the same schema as a single processed section. Each merge is a lossy compression. A three-level deep recursion applies merge compression three times. The root result may retain only 60–70% of the information content of the leaf results. Fix: preserve leaf outputs alongside the merged tree and allow downstream consumers to query specific subtrees directly rather than relying solely on the root merge.
A wide document with many sections at each level spawns agent instances exponentially. A document with 10 sections, each splitting into 10 subsections, spawns 100 base-case agents in one invocation. Without agent pool limits, this saturates the runtime. Fix: implement a width limit per recursive level and queue excess sub-agents, processing them sequentially within each level when the pool is at capacity.
The base case produces a detailed extraction schema. The Merge node produces a summarized schema (different fields). A parent process expecting base-case schema receives merge schema — downstream processing silently operates on wrong fields. Fix: enforce that the output schema of Merge Subsections is identical to the output schema of Process Section. Recursive patterns require a uniform output contract at all depths.
| Variant | Modification | When to use |
|---|---|---|
| Tail Recursion | Recursive call is the last operation — no merge step required. Parent context is not needed after the recursive call completes. | Each level fully delegates to the next level with no result aggregation — the deepest instance produces the final output directly |
| Memoized Recursion | Results for previously seen sub-problems are cached and reused without re-execution | Documents share repeated subsections (e.g., boilerplate clauses across legal contracts) — avoid re-processing identical sub-inputs |
| Depth-Limited Recursion | Hard depth cap forces base-case processing at maximum depth regardless of section size | Guarantees termination at known cost ceiling — preferred in production systems where unbounded depth is unacceptable |
| Mutual Recursion | Process A invokes Process B, which invokes Process A | Two interlocking decomposition strategies (e.g., section splitter invokes clause extractor, which invokes section splitter for embedded references) |
| Pattern | Relationship |
|---|---|
| 50.51 Structured Loop | Flat iteration over uniform items. Use when items are independent and do not decompose hierarchically. |
| 20.23 Orchestrator-Workers | A hierarchical variant where the orchestrator spawns different worker types rather than invoking itself. Use when sub-problems are not self-similar. |
| 20.26 Multi-Tier Orchestration | Fixed-depth hierarchy of orchestrators. Use when the decomposition depth is known and the levels have different roles. |
Recursion is the pattern that enables arbitrary-depth document and code analysis at scale. Systems built on this pattern can handle inputs of any structural complexity without redesign — the same agent processes a 5-page brief and a 500-page technical specification by adapting depth. This is a significant capability moat: competitors using fixed-pipeline architectures must redesign for each new input complexity class.
The critical due diligence question is base-case quality. Recursive systems amplify base-case performance across all levels — a 10% improvement in the leaf processor produces a 10% improvement at the root. Conversely, a systematic bias in the base case (e.g., always dropping tables) propagates to every merged result. Audit the base case processor in isolation before evaluating the recursive system end-to-end.
Red flag: a recursive system with no depth limit or agent pool cap in production is a runaway cost risk. A single malformed input document can spawn thousands of agents and exhaust the runtime. Bounded recursion is not optional — it is a production readiness requirement.