When an automation project for a mid-market accounts-payable queue stalls, the post-mortem usually blames the model: the agent couldn't read the invoices well enough, the accuracy wasn't there, the vendor oversold. That diagnosis is almost always wrong, because the model is generally fine. What broke is the part nobody budgeted for: getting the answer back into the system of record. The business runs on QuickBooks, the clerk posts a bill by clicking through three screens, and there is no clean, documented, supported way for software to do the same thing the clerk does. The integration surface is the bottleneck, not the intelligence, and that distinction explains why so much of this work dies after the demo.
The failure is documented, and it clusters in one place
The robotic-process-automation wave of the last decade ran this experiment at scale, and the results are unambiguous. EY's "Get ready for robots" reported that thirty to fifty percent of initial RPA projects fail outright, and a Deloitte global RPA survey of roughly four hundred enterprises found that sixty-three percent hit delays or missed deadlines. Those are not numbers you'd expect from a mature technology built on top of stable interfaces, and the reason they're so high is structural rather than incidental. An RPA bot scripted against a screen or holding an authentication token is brittle by construction. When the UI it was recorded against changes, when the token expires, when a vendor ships a patch that moves a button, the bot keeps running and silently does the wrong thing, or it stops doing anything at all. The failure mode is quiet rather than loud: a finance team discovers three weeks later that nothing posted, which is precisely the kind of failure a controller cannot tolerate in a workflow that touches the ledger.
Why the systems of record won't be written to
The deeper problem is that the software running these businesses was never built to be written to by other software. QuickBooks is the canonical case because of its reach: estimates of its share of the US small-business accounting market run roughly sixty to eighty percent depending on methodology, with QuickBooks Online alone past six million subscribers. A platform that dominant defines the integration reality for an enormous number of companies, and that reality is that the supported automation paths are narrow, the APIs cover a fraction of what a clerk does on screen, and the parts you most want to automate are often the parts with no programmatic entry point at all. The connector-and-bot approach assumes an API the system never exposed, then covers the gap with a UI script that inherits every fragility of the screen it imitates. You end up depending on a contract the vendor never agreed to.
Act at the interface a human already uses
The engineering move that avoids this is to stop looking for a programmatic path that doesn't exist and to work at the desktop the clerk already uses. The interface a human operates is the one interface the vendor commits to keeping stable, because their own customers depend on it; it changes slowly, it's documented for people, and when it does change, the change is visible rather than silent. An agent that reads the same screens, fills the same fields, and posts through the same workflow a clerk would is acting at the layer the business actually runs on, which is the system of action sitting on top of the system of record. This isn't screen-scraping with extra steps so much as the recognition that, for a system with no usable API, the supported and durable surface is the human one, and the right place to build is where the work already happens rather than around it.
The accounts-payable queue, walked through
Take the AP queue concretely. An invoice arrives, and the job is a three-way match: reconcile the invoice against the purchase order and the receiving record, confirm the quantities and prices line up, and post the approved bill into QuickBooks. The capture and extraction tier handles the clean cases, and a rules-and-OCR pipeline gets you to roughly the seventy percent straight-through ceiling that template-based document processing tops out at, because a fixed template only works on layouts it has already seen. The remaining thirty percent is the long tail of layout variance, the vendor who reformats their invoice, the line items that wrap, the handwritten note in the margin, and that's where a model plus a human earns its place, pushing straight-through processing from the rules ceiling toward ninety-nine percent. The match itself is logic, and current systems do it reliably. The genuinely hard part, the part where these projects historically die, is the last step: taking the posted result and writing it back into QuickBooks through the same screens a clerk uses, reliably, every time, without a token that expires or a recorded macro that breaks when the layout shifts.
This is the production gap, not a model gap
What this reframes is where the difficulty in enterprise AI actually lives. The popular story is that the models aren't good enough yet, but in a three-way-match workflow the reasoning is well within reach of current systems, and getting the read side from seventy to ninety-nine percent on variable documents is the long-tail problem that capture-plus-model handles. The write side is where the eighty-to-ninety-nine-percent production gap opens up, and it opens up at the integration surface rather than in the model. A reasonable counter is that vendor APIs are improving and the no-connector argument will date itself as the supported surfaces widen. There's something to that for the largest platforms, but it misreads the mid-market: the systems these companies run on are old, customized, partially supported, and frequently a version or two behind, so the API coverage gap is widest exactly for the workflows worth automating. Even where an API exists, it tends to cover the simple writes and stop short of the exception handling that is most of the actual job, so betting the reliability of a month-end close on a partial API is a bet the discovery work will usually advise against. The interface a human uses is the one you can count on, and building there is what separates a system that posts the bill every time from a bot that quietly stopped three weeks ago.