In recent articles, we've constructed loop patterns one at a time: a re-parse when a page check fails, a second retrieval when the answer points to another section, an aggregation sweep when the question demands a complete list. Each pattern has its own article, trigger, and test, and each works flawlessly in isolation.
Real-world questions rarely arrive neatly packaged as a single pattern. Consider what a compliance officer might actually ask about the NIST Cybersecurity Framework (a US government work in the public domain, per the NIST copyright statement): “What are all the Categories under GOVERN, and which one covers supply chain risk?” The question seems ordinary, but within the pipeline, it triggers three patterns simultaneously:
- TOC retrieval to land on the correct section;
- Listing aggregation to enumerate every Category, not just the most-cited ones;
- A synthesis step to identify which Category covers supply chain risk.
Each of these patterns carries its own iteration mechanics: a re-retrieval here, a re-generation there, an LLM flag that signals a second pass. When run concurrently on the same question, a practical issue surfaces: which pattern dictates when to stop? If left undecided, every new question type becomes another special case bolted onto the side, and predicting the pipeline's behavior becomes impossible.
The current trend is to offload this decision to an agent and let the model orchestrate. However, for enterprise deployments, we favor code we can read and reason about: a dispatcher that converts the parsed question and document profile into an explicit plan, paired with bounded loops that define, in code, how far each pattern may iterate. This article builds that architecture—the feedback loops, bounded iteration, and the dispatcher that orchestrates them into a cohesive workflow.
This piece concludes Part III of Enterprise Document Intelligence, a series constructing an enterprise RAG system from four foundational components: document parsing, question parsing, retrieval, and generation.
🧭 New to the series? Start with the map: Prompt, Context, Loop introduces the three engineering layers every RAG system relies on—the prompt (the call itself), the context (what fills the model's window), and the loop (when the next call fires and when it stops)—and walks through the series article by article. It's the quickest way to understand the coverage and where this installment fits.
📓 Hands-on companion: The associated notebook lets you drive the loop machinery yourself. Run pdf_qa_loop on a question that fails its first pass, print the IterationRecord history to see what each retry changed, and watch should_continue halt the loop when candidates stop evolving. Available on GitHub: doc-intel/notebooks-vol1.
In production, real questions stack patterns. For instance, “List the obligations of the seller, including any referenced standards” on a contract adds two-hop reference resolution atop the listing task, and iteration mechanics ride alongside seamlessly.
This article fits into a five-rung progression, each rung representing a more capable iteration of the same PDF question-answering function. The baseline (Article ...) establishes the foundation, and this installment addresses the critical engineering of loop control and dispatch.
Looking ahead to 2026, the increasing sophistication of LLM-based agents has pushed orchestration toward autonomy, but enterprise systems demand transparency and control. By embedding bounded loops and an explicit dispatcher, you retain determinism while enabling flexibility—ensuring the system behaves predictably, even as it handles complex, multi-pattern queries.