6 patterns for this issue
The same field appears in multiple document locations with conflicting values, and the agent grabs the first or an arbitrary occurrence instead of the authoritative one
Long documents exceed the agent's context window, so naive chunking breaks cross-references and the agent loses track of earlier content
The agent's own error-recovery step corrects a value that wasn't actually wrong, corrupting good data to satisfy a validation check
The agent's reasoning chain is logically sound, but it operates on a misread input value, so the final answer is wrong despite correct reasoning
The agent mistranslates its own document understanding into tool call parameters, silently extracting from the wrong page or region
The agent struggles on free-form correspondence and narrative documents where key information isn't in a labeled field
Agentic orchestration fails when an agent’s document reasoning is sound but the surrounding machinery — context management, tool calls, and self-correction — corrupts or loses the information the reasoning depends on. Frontier agents score below 50% accuracy on Databricks’ OfficeQA benchmark for real enterprise document reasoning tasks not because reasoning is weak, but because the agent read the wrong value, called a tool with the wrong page number, or “fixed” a correct field to match a misread total. Orchestration failures matter because they turn a single upstream error — a misread character, a truncated chunk — into a full pipeline failure that looks like a reasoning problem but isn’t.
Every mitigation in agentic orchestration separates a step that used to happen implicitly inside one agent pass into two explicit, independently-auditable stages. Context-window-limits and conflicting-information both push toward extract-then-reconcile: pull every candidate value with its location first, then apply reconciliation logic as a separate, testable stage. Reading-bottleneck and unstructured-documents both push toward extract-then-reason: a dedicated parsing/candidate-surfacing stage feeds a reasoning stage, rather than one agent call reading and reasoning simultaneously. Tool-parameter-errors and error-recovery-errors both push toward validate-before-and-after-action: schema-enforce parameters before a tool call executes, and re-run full validation after any correction to catch a “fix” that broke something else. The shared theme is that orchestration reliability comes from decomposing a single agent pass into stages that can each be checked, not from a more capable single-shot agent.
Usually reading. The reading-bottleneck pattern documents frontier agents reasoning correctly through a multi-step task while scoring under 50% accuracy on OfficeQA, because the reasoning chain started from a misread number. Fixing orchestration failures means fixing what the agent reads and how it calls tools, not upgrading the reasoning model.
Because a validation mismatch (e.g., line items don’t sum to the stated total) doesn’t tell the agent which side is wrong. The error-recovery-errors pattern shows agents adjusting a correct line-item value to match an incorrectly-read grand total, since without a reliability ranking or confidence gate, the agent has no basis to know which field is more trustworthy.
Prefer structure-aware chunking on section/heading boundaries over fixed token counts, paired with a cross-reference pre-resolution pass that maps phrases like “see Exhibit B” to their target content before chunking begins, per the context-window-limits pattern. A retrieval-augmented fallback lets the agent query the full indexed document on demand when a chunk’s extraction confidence is low.
Conflicting-information is a source-document problem — the same field genuinely appears with different values across pages (draft, amendment, final terms) and needs reconciliation logic. Error-recovery-errors is an agent-behavior problem — the agent’s own attempt to fix a detected inconsistency introduces a new error, independent of whether the source document itself was ever ambiguous.
Not reliably. The tool-parameter-errors pattern notes tool-parameter mismatches are silent — the tool executes successfully on a slightly-wrong parameter (e.g., an off-by-one page number) and returns a plausible-looking result, so detection requires validating tool output plausibility against the intended target, not just checking that the call succeeded.
| Pattern | Mechanism |
|---|---|
| Conflicting Information (GitHub) | Same field has different values across document locations; agent picks arbitrary/first occurrence |
| Context Window Limits (GitHub) | Naive chunking breaks cross-references and tables spanning pages |
| Error Recovery Errors (GitHub) | Agent’s own correction “fixes” good data to match a bad extraction |
| Reading Bottleneck (GitHub) | Correct reasoning chain built on a misread input value |
| Tool Parameter Errors (GitHub) | Off-by-one or misspecified page/region parameters passed to extraction tools |
| Unstructured Documents (GitHub) | Key values sit in narrative text with no labeled field to extract from |
Total: 6 patterns