A vehicle leasing company we work with once sent us a file we were quietly proud of. Fifty-three pages, four documents that had been stapled into one PDF by someone in a hurry, two of them upside down, and a registration certificate where the holder's name was printed across a security watermark designed specifically to defeat scanners. It came back in ninety seconds: every part identified, every part attached to the person it belonged to, every figure carrying a bounding box that clicked back to its exact spot on the page.
Then it sat in someone's inbox for two days, because nobody was sure who was allowed to approve a lease above fifty thousand euros.
Provenance on the way in.Accountability on the way out.
Accuracy has a number. Waiting does not.
Extraction gets scrutinised because you can put a number on it. Accuracy has a number, benchmarks have tables, and tables get compared in procurement. That is where we spend our engineering, and it is where the market looks.
Nothing after extraction gets a number at all.
Think about what that hides. A case waits three days in a shared mailbox, and the waiting costs more than a misread digit ever did. A reviewer opens a forty-page PDF because the system said "needs review" and nothing else, and loses an afternoon. Tomorrow, another reviewer, another afternoon, forever. An approval happens correctly and leaves no record, which costs nothing at all until an examiner asks about it, at which point it costs everything.
None of that shows up in a benchmark. All of it shows up in headcount, and in how fast your company can say yes.
Which is awkward for a company that sells extraction. We can push our number higher and leave the real bottleneck exactly where it is. Getting to 97% on hard documents is genuine engineering. It is still worth less to a lending team than knowing which analyst may sign above fifty thousand euros.
Three things a shared folder cannot do
Almost every team we plug into has built this layer themselves. A queue, a status field, two Slack channels, and a spreadsheet of who approves what. Do not sneer at it: it works. Cases get decided. People go home.
It falls over on exactly three things, and they happen to be the three things a regulator asks about.
It cannot express authority. Not "who can open this screen" but "who may take this action, on this record, in this jurisdiction, under this limit." Home-built layers model permissions at the level of a page, because that is what a web framework hands you for free. Then, in the middle of an audit, somebody works out that page-level access cannot describe the rule the business actually runs on, and the honest answer to "who was allowed to do this?" turns out to be "anyone with the link."
It cannot escalate without amnesia. Forwarding a case is easy. Carrying the reason along with it is not: which check failed, by how much, and what the last reviewer already ruled out. When that falls off in transit, your senior specialist opens the file at page one and reads what a junior read yesterday. You paid twice for the same reading, and the second pass was the expensive one.
It cannot hold one trail across systems. The extraction tool has a log. The case tool has a log. The core banking system has a log. That is three logs, which is not a trail, it is homework. Six months later somebody joins them by hand, in a room, with a person who is not feeling charitable about the gaps.
The part that is genuinely hard to build
Any one of those is a sprint. You could ship record-level permissions this quarter if you cleared the decks. Holding all three as one model, while the business rewrites its rules underneath you every few weeks, is the actual problem, and it is the part that never ships.
Forest is built around that problem instead of around a screen. Cases arrive in an inbox with dispatch rules and SLAs. Workflows carry approval steps, escalation paths, and gates that stop and wait for a human. Actions live at the level of a record, each one permissioned, so a provider call, an agent step and a reviewer decision all land in the same trail. It reads and writes against your own database, with no copy layer, which spares everyone the 3 a.m. argument about which copy is authoritative and the follow-up conversation with a data protection officer about why there are two.
The part we did not expect to like as much as we do: it sits on top of the suppliers you already chose rather than replacing them. A KYB workflow there runs over whichever identity and registry providers are already in your stack, and we are one more supplier inside it, the one that reads the documents. That is a more honest picture of a regulated operation than any two-party diagram. Not a pipeline. A control plane over a dozen vendors, each excellent at one thing, none of them able to see the whole case.
It also answers the objection that quietly kills the in-house version of this project. Teams do not give up on the internal back office because it cannot be built. They give up because it is a multi-year commitment that has to beat the product roadmap in a fight every quarter, and it loses that fight. Forest's claim is a governance layer in twelve weeks. Call it twenty if you are feeling pessimistic. The comparison is still quarters against years, and quarters is what wins the argument internally.
Who acted, and were they allowed to
Everybody is putting agents into operations now. The interesting question was never whether the agent is any good, because that one gets settled in a demo. The question is what happens the moment it acts.
The usual answer is a service account. The agent acts as nobody in particular, with whatever scope the integration happened to be handed, and shows up in the log as a system event. Which is fine, right up until the day it is not, and that day is the only day anyone will ever read that log.
Forest runs people and agents through one permission model. Same roles, same scopes, same record-level log line, with the reasoning trace attached when the actor was not a person. An agent gets no allowance for being software.
The mechanism is the part worth stealing. An analyst picks a case out of the inbox and advances the workflow. An agent calls the same workflow through Forest's MCP server. Not a parallel automation path, not a webhook wired around the side: the same workflow object, the same gates, so the log reads the same either way and the difference between the two actors is a name and a trace.
It also absorbs the actor everybody forgets. An outsourced reviewer in a BPO team is, in governance terms, exactly the same problem as an agent: a capable actor who is not your employee, working on your records, whose scope somebody will have to state out loud one day. One model covers employees, agents and vendors. The alternative is that you maintain three, and they disagree.
Where the seam disappears
Forest's piece describes how our side is built, so here is what comes out of the end of it instead, which is the part that matters at a seam.
Not a value. A value, its coordinates on the page, the verdict of every rule that ran against it, and its history if a human touched it. The rules are the ones you wrote in plain English, compiled to Hololang, our DSL for financial validation. A statement that fails to close by more than two cents gets flagged, with the page and the amount named, before anyone exports anything.
That is the part that saves a review queue. "Needs review" is not a reason. Tell a reviewer that the credits on page 12 miss the closing balance by four euros and eighty cents, and they read one line of one page instead of forty.
It only survives the handoff because Forest routes on the rule that broke rather than on a status, and because its actions live at record level, so the coordinates and the correction history stay attached to the figure instead of staying behind in our system.
A figure in Holofin traces back to a pixel on the page it came from. The same figure, once acted on in Forest, traces forward to who decided what, when, and under which rule. Neither of us can produce that whole line alone.
Two halves, one line
Our own discipline is narrow on purpose. Accuracy before speed. Provenance on every field, or the field does not ship. A failed rule is a feature, not an incident. We plug in, we do not take over, and the data stays yours. In practice that is 100K+ documents a month in production, around 40 seconds each, across 100+ document types, handled in the EU with the retention period set by you.
Neither of us is drifting into the other's half, which is the only reason this works. Forest made the other half of the argument on their own blog: OCR is infrastructure, not a commodity. Both halves are unglamorous infrastructure, and both deserve to be built properly, because the alternative is a very good number sitting in a tray for two days.
A figure that can show where it came from, in a system that can show what was done about it. Anything less and somebody, eventually, does the work twice.
Related Articles

Your Table Extractor Passed. The Numbers Didn't.
An auditor opens your extraction output for a balance sheet. The model reports 99.2% cell accuracy. Impressive. Then she totals the asset column by hand, the way auditors do, and it comes to a number that is off by one row. Assets no longer equal liabilities plus equity. The statement does not close.

Document Fraud Detection: What a PDF Can't Hide
We used to think document fraud was a visual problem. Wrong fonts. Misaligned columns. A logo that felt slightly off. We built checks around what humans see, because what humans see is all we had.

When Documents Fight Back
Page 1: Account summary, two columns. Page 15: Same account, three columns, different header names. Page 47: A scan with a coffee stain. Page 89: The totals page, which references transactions you extracted 70 pages ago.