Most document AI companies are racing to build better parsing. Retab is doing something different, building the workflow layer that makes AI actually usable in production. Eqvista sits down with Louis de Benoist, CEO and co-founder of Retab, to discuss how his team is reimagining document AI for the enterprise. From the early challenges of building automation tools in logistics to creating a platform that focuses on orchestration rather than just extraction, Louis shares the thinking behind Retab’s approach to making document processing faster, more reliable, and production-ready.
In this conversation, he explains why the real bottleneck in document AI is not just reading a PDF, but handling complex workflows at scale, validating outputs, and ensuring confidence in every step. He also shares how Retab is helping businesses in industries like insurance and logistics streamline operations with a system built for accuracy, flexibility, and real-world deployment.
Your journey to co-founding Retab?
Before Retab, shortly after graduating from Cambridge, I was building a tool called Cube that automated data entry from PDFs and emails into transport management systems for freight forwarders. We were deep in the logistics space, using LLMs and vision language models from day one – and what we kept hitting was the same wall. The document processing layer underneath was fundamentally broken.
Not the models themselves. The models were getting really good. You’d see someone extract data from a purchase order in a notebook, and it would be flawless. But the moment you tried to put that into production – handling thousands of documents a day, dealing with formats you’d never seen, knowing when the model got something wrong – it all fell apart. The demo worked. The system didn’t.
And that gap is what nobody was solving. Not “how do I read this PDF better” – the models were handling that. The real problem was everything above the model: splitting a mixed packet into the right document types, validating extracted data against business rules, knowing which outputs to trust and which to flag, routing exceptions to the right person, monitoring the whole thing at scale. The orchestration layer.
That’s when it clicked. The world didn’t need another OCR API. It needed the infrastructure that makes these increasingly powerful models actually usable for workflows businesses stake their operations on. So we pivoted, and Retab was born.
What does “operating system for document AI” mean in practice?
Think about what an operating system actually does – it abstracts away hardware complexity so developers can focus on building applications. That’s exactly what Retab does for document processing.
In practice, you upload a few example documents, describe what you want in natural language, and Retab’s AI agent builds the entire pipeline: splitting mixed document packets, classifying pages into the right categories, extracting structured data, validating it against your business rules, and routing exceptions to human reviewers. Developers can work directly from Claude Code or Codex via our MCP integration, deploy workflows as APIs or webhook-driven jobs, and monitor everything from a single dashboard.
The reason the “OS” framing matters is that right now, teams are stitching together an OCR service, an LLM, a validation layer, a human review tool, and a monitoring system – and then spending months maintaining the glue between them. That glue is where everything breaks. Retab replaces the entire stack. You don’t assemble the plumbing. You describe what you need, and the system builds and runs it.
How does Retab integrate with LLMs and what makes the approach unique?
Most document AI follows a two-step architecture: run OCR to extract text, then feed that text to a language model. It sounds reasonable until you realize how much information gets destroyed in that handoff. Spatial relationships between fields, the visual structure of tables, the context that comes from seeing a document the way a human actually sees it – all of that is lost the moment you reduce a page to a text string.
We took a fundamentally different path. Retab uses vision language models that process documents directly from image to structured output; we skip OCR entirely. The model sees the document the way you would: as a visual artifact with structure, context, and meaning.
But seeing the document better is only the foundation. The real challenge – the one nobody talks about in demo videos – is everything you need around the model to make it production-grade. We built intelligent model routing that selects the right configuration per document type to balance cost and accuracy. We built k-LLM consensus that runs multiple passes to give you per-field confidence scores – so you actually know when to trust the output and when to flag it. We built self-optimizing schemas that refine extraction instructions automatically, and full pipeline evaluation so you can test your entire workflow against historical data before it ever touches a live document. Building that infrastructure yourself on raw model APIs would take months and a dedicated ML team. That’s the gap we fill.
How do self-optimizing schemas, model-agnostic routing, and consensus engines contribute to reliability and cost-effectiveness?
Every enterprise buyer asks the same question: “How do I know the output is correct?” And right behind it: “How do I keep costs under control at scale?” These three features exist because those two questions are actually deeply connected.
Smart Routing solves the cost problem by recognizing that not every document deserves the same treatment. A simple cover sheet doesn’t need the same processing power as a complex legal deed. The system automatically selects the cheapest model that can handle each document accurately, so straightforward pages get processed by our micro model at a fraction of the cost, while the hard cases get the full treatment with consensus.
The k-LLM consensus engine is our answer to the trust question – and it’s something nobody else in the market offers. It runs multiple VLM passes on a document and compares the outputs field by field. If every pass agrees on a value, you can trust it. If they disagree, you know exactly where to look. That’s a fundamentally different proposition from getting a single output and hoping it’s right.
And self-optimizing schemas mean you don’t spend days hand-tuning extraction prompts – the system automatically tests and refines its own instructions to maximize accuracy. Together, these features let you ship workflows faster, trust the outputs more, and spend less per document. That combination is what makes the difference between a proof of concept and a production system.
Specific industries or workflows where Retab has delivered significant impact?
I’ll give you two concrete ones.
In insurance, we automated claims packet processing where adjusters were manually reviewing massive PDFs containing intake forms, police reports, medical records, and repair estimates. Imagine that’s someone’s actual Tuesday – paging through over a thousand pages of documents for a single claim. The full pipeline now runs dramatically faster with straight-through processing for high-confidence outputs.
In logistics, the leading European TMS provider, serving thousands of carriers handling millions of shipments per year, built their order ingestion module on Retab. Their clients were previously spending millions annually outsourcing that data entry. They now process orders at over 99% accuracy, with the vast majority going straight through with no human touch.
What’s interesting about both cases is the same pattern: these aren’t companies that lacked technology. They’d tried OCR tools, they’d tried outsourcing, they’d tried building in-house. The problem was never the extraction step in isolation – it was orchestrating the full workflow reliably enough to actually trust it with critical operations.
How does Retab differentiate from other document AI platforms?
Most document AI companies are building better parsing. We’re building the workflow layer.
And that distinction matters more than it sounds. Parsing – converting a document into structured text – is becoming commoditized. Every major model can do a reasonable job of extracting text from a PDF. That’s layer one of the problem. But production document processing has layers two through ten: splitting mixed packets into the right document types, classifying each one, extracting structured data, cross-validating fields across documents, routing exceptions to the right human reviewer, and monitoring the whole thing in production.
We’re the only platform where you can describe your entire pipeline in natural language and have it built for you. The only one with k-LLM consensus for per-field confidence scores. The only one that evaluates your complete end-to-end workflow – not just individual extraction nodes in isolation. And our straight VLM architecture gives us an edge on the hardest documents: handwritten forms, damaged scans, historical records, complex table layouts.
The hard part – and where enterprise value concentrates – is the orchestration layer above parsing. That’s our entire focus.
How do you see document AI evolving as foundation models get more capable?
As foundation models get better at understanding documents natively, the need for what Retab does doesn’t shrink – it grows. Better models mean more companies will attempt to automate document workflows. And every single one of them will hit the same orchestration problems that have nothing to do with model quality.
How do you split a thousand-page mixed packet into the right document types? How do you validate extracted data against dozens of business rules and cross-reference it across multiple documents? How do you handle the cases where the AI isn’t confident? How do you evaluate whether your pipeline actually works before deploying it to production? How do you route simple documents to fast, cheap models and complex ones to expensive, accurate models?
None of that goes away as models improve. It becomes the bottleneck. We’re building the infrastructure layer that makes increasingly capable models actually usable for the workflows that businesses stake their operations on. The self-driving back office isn’t going to be built by a better model alone – it’s going to be built on the orchestration layer above it.
Biggest technical and market challenges in scaling Retab?
On the technical side, the hardest challenge is one that never shows up in benchmarks: the insane diversity of real-world documents. Production documents aren’t the clean PDFs you see in demos; they’re damaged scans, handwritten notes, faxed forms with coffee stains, packets with hundreds of pages and inconsistent layouts. Every new customer brings document formats we’ve never seen before, and the system needs to handle them reliably from day one.
We learned early – and honestly, the hard way – that you can’t just throw a better model at this problem. You need evaluation infrastructure that tells you exactly where your pipeline is strong and where it’s breaking. You need consensus scoring that quantifies uncertainty at the field level. That’s why we invested so heavily in those capabilities before building flashier features.
On the market side, the challenge is a framing problem. Many companies still think “document AI” means OCR – a point solution that reads text from a page. We have to shift the entire conversation from extraction to workflow orchestration, from parsing accuracy to production reliability. It’s the difference between selling a component and selling the system. That education takes time, but once a team sees their full pipeline running end to end, the conversation changes entirely.
Priorities after the $3.5M pre-seed?
First, expand our enterprise customer base across insurance, logistics, oil and gas, and financial services – industries where we already have strong proof points and where the pain is acute enough that teams move fast once they see the platform work.
Second, keep investing in the developer experience. Our MCP integration with Claude Code and Codex is a real distribution advantage – we want Retab to be the tool developers reach for instinctively when they need to process documents in their workflows.
Third, grow the team, especially on engineering and go-to-market.
We’re backed by founders who understand developer infrastructure at scale – Olivier Pomel built Datadog, Florian Douetteau built Dataiku. They invested because they see the same pattern: when a new technology wave hits, there’s always an infrastructure layer that becomes the default platform. Stripe became the default for payments. Twilio became the default for communications. Datadog became the default for observability.
The long-term vision is that Retab becomes that default layer for document workflows.
Advice for startups integrating LLMs into their products?
Teams get excited because a vision model can extract data from a PDF in a notebook and it looks like magic. So they ship it. And then the real documents show up – the ones that don’t look like the test set, the ones with handwriting the model has never seen, the edge cases that represent a small percentage of volume but carry outsized business risk. The model is wrong, and nobody knows it’s wrong, and by the time someone notices, the damage is done.
The hard part of integrating LLMs isn’t getting them to work. It’s knowing when they don’t work. It’s handling the documents that don’t match your expectations. It’s recovering gracefully from errors. It’s evaluating accuracy at scale across your real production data, not a curated benchmark. It’s managing costs when you’re processing at volume. It’s keeping humans in the loop where they need to be, and only where they need to be.
My advice is to invest in evaluation infrastructure from day one. If you can’t measure how well your system works across real data, you’re gonna get nasty surprises in production. Don’t just trust the model output, validate it or quantify its uncertainty. And don’t try to build the orchestration layer yourself. The routing, validation, human review, monitoring; it’s genuinely hard to get right, and it’s not what makes your product unique. Use infrastructure that handles it so you can focus on the thing only you can build.
