ExpertsFMThe Missing Infrastructure for AI Agents: Documents | Reducto’s Adit Abraham
The a16z Show · October 21, 2026
5 Selected Lessons:
heuristic · 2 case · 2 reasoning_pattern · 1
Why consequential domains adopt AI slower than low-stakes domains
Source
The a16z Show — The Missing Infrastructure for AI Agents: Documents | Reducto’s Adit Abraham (October 21, 2026) · at 15:17 ▸
When this applies
when explaining why a technically superior tool adopts slowly in one market versus quickly in another
The takeaway
Don't attribute slow adoption purely to cultural resistance — diagnose whether the real blocker is the asymmetry between error cost and reversibility in that domain.
Why it works
In low-stakes domains, errors are cheap to reverse (rolling back a code PR), so users tolerate imperfect automation for the productivity gain; in high-stakes domains, an error directly changes a real-world outcome (a medical/legal decision) with no easy rollback, so adoption requires visible guardrails (citations, grounding) before trust is extended.
One level up
The adoption curve of an automation technology is shaped less by its raw accuracy and more by how cheaply and visibly its errors can be caught and reversed in that domain.
Where it stops holding
This stops working when a domain is objectively low-stakes but still adopts slowly for other reasons (e.g., regulation, procurement cycles, or lack of champions), so the reversibility framing alone won't fully explain the gap.
Detail
approach: When comparing adoption speed across markets, separate 'is there enough value' from 'is there sufficient guardrail/trust infrastructure for the stakes involved.'
signals:
- Errors are reversible at low cost (e.g., code rollback) vs. irreversible real-world consequences (e.g., medical/legal decisions)
- Cultural enthusiasm for self-augmentation (developers) vs. professional caution in regulated fields
rationale: If you Vibecode something and it's filled with bugs, you get to roll back your PR in a way that is not true if you're making decisions in healthcare.
In their words
I think there's also something to be said about consequences. Like, if you Vibecode something and it's filled with bugs, you get to roll back your PR in a way that is not true if you're making decisions in healthcare.
Narrow focus beats broad frontier labs on specialized infra tasks
Source
The a16z Show — The Missing Infrastructure for AI Agents: Documents | Reducto’s Adit Abraham (October 21, 2026) · at 0:00 ▸ · at 17:26 ▸
When this applies
when a startup competes against a generalist platform player who has far more resources but a broader mandate
The takeaway
Constrain your problem surface deliberately; depth within a narrow, well-understood domain can outcompete breadth, especially on cost and latency at scale.
Why it works
Generalist labs must keep their models good at an unbounded range of tasks (e.g., turning selfies into stylized art), so they cannot afford to over-specialize; a focused company can tune cost, latency, and accuracy specifically for a narrow domain and beat frontier models on that axis even if the frontier model wins on raw intelligence.
One level up
Durable differentiation vs. a much larger competitor often comes from deliberately narrowing scope where the competitor structurally cannot specialize without diluting their core mission.
Where it stops holding
This stops working when the generalist lab decides the narrow domain is strategically important enough to invest dedicated resources into it, erasing the focus advantage.
Detail
rule: When your product is 'tangential to intelligence' (an infra layer around a generalist capability), bet on focus rather than competing on raw model intelligence.
threshold: Orders-of-magnitude better price at comparable accuracy for the specific domain vs. a frontier model.
rationale: Labs are in an arms race for general superintelligence and can't deep-dive into every narrow tool; a dedicated vision encoder tuned only for document structure can achieve 'Astra-level quality' cheaply, whereas throwing a frontier model at every PDF is not economical.
In their words
The fact that we can constrain the set of problems that we need to be good at is a big part of why we're able to be ahead. Like, we're not making generic models here.
Driving cost per unit down unlocks unimagined use cases
Source
The a16z Show — The Missing Infrastructure for AI Agents: Documents | Reducto’s Adit Abraham (October 21, 2026) · at 8:51 ▸
When this applies
when the marginal cost of an AI capability falls dramatically
The takeaway
Watch for the threshold where cost drops enough that people stop budgeting for a capability and start assuming unlimited access to it — that's when qualitatively new use cases (not just cheaper versions of old ones) appear.
Why it works
When cost per unit of an action becomes negligible, users stop rationing usage (e.g., 'only parse the important pages') and instead apply the capability indiscriminately and exploratively, enabling agent behaviors like open-ended web/document search that weren't previously economical.
One level up
Infrastructure businesses should track not just quality improvements but cost-threshold crossings, since those thresholds — not incremental accuracy gains — are often what unlock new categories of behavior.
Where it stops holding
This stops working when the bottleneck to adoption isn't cost but trust, regulation, or organizational workflow inertia (as discussed regarding healthcare adoption lag).
Detail
rule: Once a capability's marginal cost is low enough, stop constraining usage by cost and assume broad, exploratory use.
threshold: Reducto's stated price point: one cent per page, processing 'billions of pages every single month,' crossing 7 billion total pages.
rationale: Ideally people are not thinking from the lens of like, it costs me this much to parse a page, and therefore only these pages go to an accurate pipeline.
In their words
Today, literally this morning, we crossed our 7 billionth page. At this point, we process billions of pages every single month.
DeepExtract: agents self-correcting can beat human ground truth
Source
The a16z Show — The Missing Infrastructure for AI Agents: Documents | Reducto’s Adit Abraham (October 21, 2026) · at 8:51 ▸ · at 21:18 ▸
When this applies
when designing an automated system meant to match or exceed human performance on a repetitive judgment task
The takeaway
Build a review/self-correction loop into the agent's workflow rather than treating the first output as final, and benchmark against realistic (imperfect) human baselines rather than assumed perfect ground truth.
Why it works
Giving an agent tools to review and validate its own output (e.g., checking that invoice line items sum to the total) lets it catch the kind of careless errors humans make (dropped rows, lazy partial fills), shifting accuracy in the agent's favor versus a single-pass human or model attempt.
One level up
Measured superiority to humans is often not about raw capability but about structurally enforcing diligence that humans routinely skip.
Where it stops holding
This stops working when there is no reliable way to encode validation rules for the task (ambiguous or subjective correctness), so self-review has nothing objective to check against.
Detail
situation: Human-annotated ground truth for structured extraction tasks often contains errors (dropped rows, lazy partial fills) that go unnoticed because it's treated as the gold standard.
decision: Reducto built a harness (DeepExtract) that is model-agnostic but gives the model tools to review its own outputs, create validation rules, and check for internal consistency (e.g., line items summing to a total).
outcome: Found situations where agents using this harness outperformed humans on structured extraction accuracy, because they systematically caught their own mistakes.
lesson: Self-review tooling, not just raw model intelligence, is what unlocks near-perfect accuracy; it also reveals that 'ground truth' was never actually perfect.
In their words
DeepExtract is a really good example, where it's the first time where I find that agents can be better at structured extraction than humans on many tests.
Sub-50% OCR accuracy on inch-thick healthcare packets causing real patient harm
Source
The a16z Show — The Missing Infrastructure for AI Agents: Documents | Reducto’s Adit Abraham (October 21, 2026) · at 32:03 ▸
When this applies
when an automated data-extraction error propagates into a high-stakes downstream decision without a human catching it
The takeaway
In domains where humans are too overloaded to verify automation output, the automation's error rate effectively becomes the system's true error rate — there's no real fallback human check despite the appearance of 'human in the loop.'
Why it works
Overworked human reviewers (doctors) cannot realistically double-check every page of tens-of-thousands-page patient packets, so they trust the automated pipeline's output as ground truth; a single misread word (pain vs chest pain) then silently alters a real clinical/insurance decision.
One level up
Never assume a 'human in the loop' is an effective safety net without checking whether that human actually has the capacity/time to meaningfully review the volume involved.
Where it stops holding
This stops working as a universal claim when document volumes are small enough, or reviewers are not time-constrained, such that genuine human verification is feasible.
Detail
situation: A healthcare search customer processes physical patient document packets that can be inches thick, read by doctors who are already overworked.
decision: N/A — illustrative of current status quo rather than a Reducto decision; shown as motivation for needing high-accuracy, trustworthy pipelines.
outcome: An initial pipeline read 'pain' instead of 'chest pain,' leading to a rejected claim because a doctor's search for history of the symptom came back negative; current sub-pipelines for this kind of data can be sub-50% accurate, leaving best case as an approximate location flag for a human to check, who often cannot due to volume.
lesson: In consequential domains, low baseline accuracy plus the fiction of human review creates compounding real-world harm; the fix is to push accuracy, cost, and latency enough that full automation is trustworthy rather than papering over the gap with a nominal human checkpoint.
In their words
In those sorts of situations, we actually find that there are cases where it's like sub 50%. Like the best you can do is have some approximation of where information sits, and then a human has to look at it.