A person asks the pipeline: “what’s the premium?” on a fifty-page insurance coverage coverage. The parser seems on the doc profile it simply acquired from the parsing brick:
doc_type: insurance_policyn_pages: 47toc_dfnames Normal Data, Coverages, Exclusions, Endorsements. No part referred to as Premium.
Naive top-k embeds “premium” and scans the entire doc. It returns exclusion clauses that point out the phrase, endorsement boilerplate, and some incidental references. The precise premium schedule sits underneath Normal Data on web page 3, however nothing within the question stated so.
A loop-engineered pipeline does one thing totally different. The parser sees “premium” has no match within the TOC, holds the pipeline, and sends one plain query again to the person:
“I don’t see a ‘Premium’ part on this coverage. The place ought to I look?”
They could kind “Normal Data” (brief), “generale info” (typo), or “attempt underneath coverages” (rephrased). None of that issues. The parser re-runs on the enriched query, the LLM suits no matter got here again into section_hint or one other typed subject, and the pipeline continues.
That single flip removes the paradox and scopes retrieval.
The fuller mechanism (an specific listing of candidate values, a proposed default, an audit path so the reply might be cached and utilized silently subsequent time) is what Article 6bis develops. This text stays on the smallest doable model: a query in, a solution out, one LLM cross.
Enterprise Doc Intelligence builds enterprise RAG on 4 bricks (doc parsing, query parsing, retrieval, era). This text re-reads brick 2 via the loop-engineering lens, the rising self-discipline that names the loops constructed round the LLM because the place the place manufacturing high quality is received. Articles 6A (thesis), 6B (extraction), and 6C (dispatch) code the brick. Article 6bis codes the clarification loop’s mechanics. This one names why that mechanic is the loop-engineering sample utilized on the smallest doable scope.
📓 The three instances in Part 3 all run within the shipped pocket book: reproduce the clarification loop your self towards the arXiv corpus and a dealer contract, watch how the LLM’s “what’s lacking?” query shifts with the doc profile. Repo → doc-intel/notebooks-vol1.
1. From immediate to context to loop engineering
The body has moved twice in eighteen months.
Immediate engineering (2023). The person does the work. Be taught to write down the fitting immediate, add few-shot examples, use “assume step-by-step”. The LLM is a stateless oracle. High quality is a wording drawback.
Context engineering (mid-2025). The engineer does the work. Tobi Lütke and Andrej Karpathy rename the apply: “the fragile artwork of filling the context window with simply the fitting info for the following step.” The immediate is one slot amongst many. See Article 6quater (context engineering for query parsing) for that framing utilized to this brick.
Loop engineering (2026). The engineer designs the loops round the LLM name. LangChain places it plainly: “the potential in brokers is within the loops you construct round them.” MindStudio frames it as “designing AI techniques that function in iterative cycles, repeating till a objective is met”, the self-discipline that “closes the suggestions hole.”
The three will not be a race. They stack: immediate engineering shapes what one name reads, context engineering picks what enters that decision, loop engineering wraps the decision in a bounded iteration.
Loops are available in sizes. An enormous loop is agentic RAG (plan, act, observe, replan, many turns). A small loop is a single ask-answer-continue flip. This text is concerning the smallest helpful loop, sitting on query parsing.
2. The loop fills a hard and fast schema
Earlier than the loop, title the fields it is going to fill.
Query parsing writes right into a mounted set of typed fields, outlined as soon as for the entire collection and consumed deterministically by retrieval and era. Vol.1 ships with these:
key phrases: content material noun phrases for retrieval detectors.intent: a bounded enum (factual,itemizing,section_retrieval,open_scoped,open_corpus_wide).retrieval.section_hint: a piece title or quantity to filtertoc_df.retrieval.layout_hint:"desk","determine", or"glossary"when the reply sits in a particular structure.structural_hints.pages_hint: an specific web page listing the person pinned within the query.- (
sheets_hint/slides_hintfor Vol.2 codecs, unused right here.)
These names will not be article-local. They stay within the docintel.query module and each downstream brick (retrieval detectors, dispatcher, era schema lookup) reads them. Add a subject and the entire pipeline modifications. That may be a design choice, not a JSON tweak.
The loop’s solely job is to fill considered one of these fields when the parser can’t fill it alone. It by no means invents a brand new one.
The circulation, six steps and one loop-back arrow:
In code, the identical circulation on the premium query from the intro:
# 1-2. First parse from uncooked query + doc context.
parsed = parse_question(
uncooked="what's the premium?",
doc_context=doc_context, # doc_type='insurance_policy', toc_df=..., ...
)
# What comes again:
assert parsed.key phrases == ["premium"]
assert parsed.intent == "factual"
assert parsed.retrieval.section_hint is None # <-- the lacking subject
assert parsed.structural_hints is None
# 3. Detect the lacking subject.
if parsed.retrieval.section_hint is None and _topic_looks_sectioned(parsed, doc_context):
question_to_user = (
f"I do not see a '{parsed.key phrases[0].title()}' part on this coverage. "
"The place ought to I look?"
)
user_reply = ask_user(question_to_user) # UI round-trip, free-form reply
# 4-5. Re-parse with the enriched query.
parsed = parse_question(
uncooked=f"{parsed.original_question} (look underneath {user_reply})",
doc_context=doc_context,
)
# By now, section_hint is crammed from the person's reply.
plan = dispatch(parsed) # step 6, unchangedDiscover what modifications throughout the 2 parse_question(...) calls: solely the sector that was lacking. Each different subject of ParsedQuestion stays the place it was. dispatch(parsed) on the finish is the very same name it might have been with no loop, operating towards the identical schema.
Not each subject is obligatory: no TOC means no section_hint, and that’s wonderful so long as one other subject (like pages_hint) scopes the search. The engineering work is selecting which subject to ask about, given the doc profile, and the best way to phrase the query for the person’s context.
See Article 6bis for the fuller mechanic that provides candidate enumeration, a proposed default, and caching so the identical ask fires silently subsequent time.
3. Three instances, three lacking fields
Every case beneath names the one subject the parser can’t fill from the uncooked query alone, the doc profile that flags the hole, and the plain query that fills it. Similar schema throughout the three, no new subject invented.
3.1 Lacking section_hint: matter not within the TOC
Image an insurance coverage analyst opening a coverage she has by no means seen earlier than. Forty-seven pages, 4 TOC entries, nothing standing out at a look. She varieties the query she would in any other case reply with ten minutes of scrolling:
“What’s the premium for the primary quarter?”
The parser reads the query alongside what doc parsing already is aware of concerning the file:
doc_type: insurance_policyn_pages: 47toc_dfnames Normal Data, Coverages, Exclusions, Endorsements. Nothing that carries the phrase Premium.
On its first cross, parse_question(...) fills what it could:
key phrasescomes again as["premium"].intentcomes again asfactualas a result of the reply is one quantity, not a abstract or a listing.retrieval.section_hintrefuses to fill.
The final one is what stops the pipeline. The person’s matter doesn’t correspond to any TOC label, and the parser is not going to invent one. Reasonably than ahead a half-filled row to retrieval, it holds and asks.
One query goes again to the analyst:
“I don’t see a ‘Premium’ part on this coverage. The place ought to I look?”
She varieties no matter comes first. “Normal Data” if she is dashing. “The overall one” if she is not sure of the precise label. “Attempt common info” if she is being exact. The wording doesn’t matter. The identical LLM that parsed the unique query re-runs on the enriched string, resolves whichever variant she typed to “Normal Data”, and writes it into section_hint on the second cross. Each different subject on the row stays precisely the place the primary parse left it.
From that time the pipeline is deterministic once more. section_filter_active fires downstream as a result of section_hint is now set. Retrieval reads solely the pages inside Normal Data on toc_df (web page 3, on this coverage). Technology reads a crisp passage as an alternative of forty-seven pages of noise. The analyst will get the quantity again in seconds.
3.2 Lacking pages_hint: multi-position matter
A distinct desk, a special pipeline floor. A paralegal asks the assistant to take a look at a contract she must file earlier than the tip of the day:
“What’s the shopper’s title?”
The doc profile confirms a contract, forty-seven pages lengthy. The TOC lists numbered clauses however by no means spells out a Events header. On the primary cross:
key phrasescomes again as["client name"].intentcomes again asfactual.structural_hints.pages_hintstaysNone.
The final one is the lure. On a contract, the shopper’s title lives in three canonical positions:
- the duvet web page;
- the operating header on the prime of each web page;
- the signatory block on the finish.
Forwarding the query with no web page trace sends retrieval into the entire doc and drags in each boilerplate point out of “the shopper” in between. The correct passage is on web page 1. The signal-to-noise ratio collapses earlier than era ever runs.
The parser writes again:
“Contracts typically carry the shopper’s title in a number of locations (cowl, header, signatories). The place would you like me to look?”
The paralegal solutions “cowl”, or “web page 1”, or “the primary web page”. The precise phrasing doesn’t matter. On the second parse, the LLM resolves whichever variant she typed into pages_hint: [1]. key phrases and intent keep the place they have been. pages_hint_active fires downstream, retrieval reads web page 1 and solely web page 1, and the LLM generates towards one clear candidate.
3.3 Lacking pages_hint: no TOC on a protracted doc
A researcher opens an inside threat paper and asks the assistant:
“Summarize the chance part.”
The doc profile flags a research_paper, thirty-two pages, and toc_df is empty. Visually the paper has part headings, however the parsing brick couldn’t extract them cleanly (nested styling, inconsistent numbering, no matter induced the miss). That kills section_hint earlier than the loop may even attempt. There isn’t a TOC entry to bind to.
However it doesn’t kill pages_hint. The researcher might know roughly the place within the paper the chance dialogue lives, and a tough web page vary is all retrieval must slender the search. That provides the parser one helpful factor to ask about:
“This paper has no clear desk of contents. Have you learnt roughly which pages cowl the chance part?”
Two solutions ship the pipeline to 2 very totally different locations:
- “No thought” retains
pages_hint: None. The pipeline truthfully falls again to a full-document scan. Retrieval reads all thirty-two pages, era runs on the widest doable context. Costly, however at the least the person was instructed what would occur. - “Across the center” resolves to
pages_hint: [11, 12, 13, ..., 22]on the second parse.pages_hint_activefires. Retrieval reads one third of the doc as an alternative of all of it. Technology sees a shorter, extra related context. The abstract arrives sooner and the LLM invoice is a 3rd of what it might have been.
It’s the identical brick chain operating on a smaller working set.
Discover what stays fixed throughout the three. Each subject the loop touches (section_hint, pages_hint) already existed on the schema. The loop’s contribution is selecting which one to ask about given the doc profile. Similar downstream code, identical dispatcher, identical activation flags. Nothing new to plumb via the pipeline.
4. The place the loop suits, and why it isn’t agentic RAG
The loop sits inside query parsing. The remainder of the pipeline by no means sees it: retrieval solely begins as soon as query parsing has produced a full-confidence ParsedQuestion, whether or not on the primary cross or after one clarification flip.
Retrieval and era see one interface: a crammed ParsedQuestion. Whether or not the pipeline wanted a flip or not is invisible to them. The loop is small, engineered, and lives completely contained in the query brick’s edge with the person.
That placement can also be why the small loop seems like an agent flip however just isn’t one:
- One iteration, not many. The loop fires as soon as, the person picks, the pipeline continues. No plan, no replan, no self-critique contained in the loop.
- Engineer-designed, not LLM-planned. The candidate values, the goal subject, the fallback default: all authored code paths pushed by the doc profile. The LLM writes the “question_to_user” string and picks the proposed default. That’s all.
- Grounded in actual state. The loop solely fires on gaps the parser can title (matter not in TOC, multi-position matter, no TOC). No open-ended “let me take into consideration this” introspection. Aligned with what Zylos Analysis calls grounded self-correction: anchored in execution outcomes, not within the mannequin second-guessing itself.
- Bounded latency. An enormous agentic loop can spin for tens of seconds. This one provides one round-trip and one LLM name, then both continues or arms management to the person.
The excellence issues as a result of the business framing of loop engineering typically assumes the multi-turn agentic case. On the query facet of a single-document pipeline, the loop that pays off is the smallest one which exists.
5. Out of scope
Three issues this text intentionally doesn’t cowl.
- The multi-turn agentic loop. When the pipeline itself plans and re-plans throughout many LLM calls, that’s Quantity 4’s territory (agentic bricks with instruments).
- Verification / evaluator loops after era. Reply-generated-then-critiqued patterns (see the schema-validation retry in Article 8C) are their very own loops downstream. Totally different receiver.
- Cross-document / corpus scoping. “Which doc?” quite than “which part?” is a
CorpusContextdrawback, Quantity 2.
Every of those is a special loop, at a special scope, for a special receiver, utilizing the identical vocabulary at a special scale.
6. Sources and additional studying
The loop-engineering framing arrived in 2026 from a number of sources directly, converging on the identical time period after context engineering had settled the vocabulary.
The first business anchors:
- Sydney Runkle (LangChain), “The Artwork of Loop Engineering”: weblog submit, June 2026.
- MindStudio, “What Is Loop Engineering? The New Meta for AI Coding Brokers”: weblog submit, June 2026.
- mem0, “Loop Engineering for AI Brokers: Reminiscence-First Design”: weblog submit.
The muse the loops construct on:
- Anthropic, “Constructing Efficient AI Brokers”: analysis submit. The bottom patterns (evaluator-optimizer, reflection) and the temperance rule (add loops solely once they demonstrably enhance outcomes).
- Yao et al., “ReAct: Synergizing Reasoning and Appearing in Language Fashions”: arXiv 2210.03629. The founding reason-act-observe loop.
- Madaan et al., “Self-Refine: Iterative Refinement with Self-Suggestions”: arXiv 2303.17651. Generate → self-feedback → refine.
The collection articles that code the items this one frames:
- When RAG customers ask imprecise questions (Article 6bis). The clarification loop’s mechanics:
ClarificationRequest,ClarificationDefault, the ask-then-learn cache. - Context Engineering for RAG (Article 7bis). The pipeline-wide context-engineering framing this text extends into loop-engineering.
