On a Tuesday afternoon in February I watched our scheduler push a promise date out by nine days. Took about forty seconds. It happened in two places.
The first was the field you’d expect, on the work order header. The second was an operation-level date on the last routing step, because the report purchasing actually watches reads that one and ignores the header. Nobody designed it that way. Somebody built the report in 2019 against whichever field was convenient, and eleven hundred jobs later that’s just how the shop works.
Our scheduler knows this. She is the only person who knows this. In March she took a week off, somebody else moved a date the obvious way, and a customer spent eight days looking at a ship date we were never going to hit. Their buyer caught it, on a call about something else.
That kind of knowledge is worth real money right now. It’s also depreciating, and I don’t think most of this industry has noticed.
I’m not neutral here. I write the code that talks to our ERP, so this is an integrator’s opinion, filed as an open question on purpose. I’ll flag which parts are me guessing.
For thirty years the screens were the product
Enterprise software competed on the interface. Demos were screen tours, implementation was mostly teaching people screens, and what a vendor sold you was how few clicks it took a scheduler to move a job.
The data model underneath was never exotic. Work orders, routings, operations, POs, receipts, inventory transactions. Any competent engineer can sketch it on a whiteboard in ten minutes. You weren’t paying for the model. You were paying for forms and rules that let twenty non-programmers keep it current without wrecking it.
That’s inverting. Slowly down here in the mid-market, fast at the top.
The big platforms are saying it out loud now
One of the biggest CRM vendors spent its 2026 developer conference explaining that every capability of its platform would be reachable three ways: as a REST call, as a command-line invocation, and as a tool an AI agent can call directly. The stated goal was making it unnecessary for anyone to log in. Ever. And they hedged across all three on purpose, because nobody’s sure yet which one wins.
Mid-market manufacturing ERP is heading the same way with less press. From the more forward vendors you now get a documented REST API covering most of the object model, an OpenAPI schema you can generate a client from, site-scoped bearer tokens, and increasingly a tool server an agent can call, with permission awareness and a preview step before anything writes.
The reasoning is the same in both places. If software can read a document, reason about it, and act on it, a UI is a translation layer between two systems that could have talked directly. What stays valuable underneath is twenty years of data and business logic. The forms aren’t that.
What I’d actually ask a vendor
The old procurement question was “does the ERP have a screen for this?” The new one is “can I read and write this record programmatically, and does the API cover as much as the UI does?”
Different questions, and the second gets a much less flattering answer. On a call last spring I asked for the API documentation and got a forty-slide deck with a section titled Extensibility. Asked again, got a partner-program overview. The third ask produced a real doc site. It was decent, and it didn’t cover about a third of what the UI does.
Worth checking before you sign:
Coverage parity. Is every object you care about readable and writable? Quotes, routings, operation-level times, receipts, shipments. A lot of these APIs are read-heavy with a few write paths bolted on. Ours won’t let me set an operation’s standard time directly. Changing it means going through the routing template, which isn’t the same thing, and I lost two afternoons before I believed it.
Change notification. Webhooks, or polling list endpoints with a modified-after filter? Polling works fine. It’s also a design constraint you inherit permanently.
Idempotency. Your integration times out and retries. One record or two? Some vendors hand you explicit keys. Others expect you to abuse an external-reference field as a de facto dedupe, which is what we do.
Sandbox and rate limits. If neither is documented, assume every call hits production and the ceiling is whatever you find the hard way. I found ours at 11:40 on a Wednesday night, backfilling three years of closed jobs.
None of that shows up in a demo. All of it decides whether an integration takes nine days or a quarter. Our first took nine days. The second took most of a quarter, and the difference was one object.
What this does to “where’s my part”
Ask a shop where your job stands and the sequence is roughly this. A person gets located. That person opens a screen, reads it, composes a sentence, types it into an email. Latency is set by whether they’re at lunch, accuracy by transcription. What lands in your inbox is one person’s rendering of one screen at one moment, already stale.
When the record itself is reachable by software, status stops being a lookup and becomes a property of the record. An operation closes on the floor, the record’s state changes, and everything downstream that reads it sees the change without anyone deciding to tell you. Portal, scheduled email, a call into your own system, that part’s an implementation detail. The shift is that no human stands between the fact and the report of the fact.
Same upstream. Our 24-hour quote commitment is easier to hold when a quote gets built from structured inputs than when somebody retypes it off a spreadsheet at five o’clock.
Wherever AI touches any of that, the arrangement is the one I designed everything else around. It runs on servers we own, here in Stuart, on open-source models. Your data doesn’t go to an outside AI provider and it’s never used to train anyone’s model, ours included. That constraint made some of this slower than it had to be, and I’d make the same call again.
The part I’m not sure about
An API-first vendor is a vendor moving work onto you.
A UI is a finished product. An API is a kit. When a vendor stops investing in screens, they’re betting customers will build the last mile themselves, and for most shops that bet is wrong. An integration is software. It needs version control, error handling, retry logic, monitoring, and somebody who notices when a token expires at 2 a.m. or a field type quietly changes in a point release. We’re thirteen people. I’m that somebody, and I’m also several other people.
So “API-first ERP” isn’t a feature you buy. It’s a capability you either staff or you don’t. Buying the most agent-friendly system on the market and using it exactly like the old one is a legitimate choice. You’re just paying for a surface you’ll never call.
Here’s where I’m guessing. I don’t know if agent-callable tool servers matter in three years or turn out to be a 2026 fashion. I don’t know if small shops end up buying integration as a service, or if the ERP vendors take the last mile back once enough customers fail at it. I lean toward the second and I hold it loosely.
What I’m confident about is narrower. The screen isn’t going away, and a schedule board beats a JSON payload for a human every time. Its status is what’s changing, from the product itself down to one client among several.
Next vendor call, skip the UI roadmap. Ask which parts of the object model the API doesn’t cover. Whether they can answer without going to check tells you most of it.
