The interface layer: a thesis on AI between systems

This is the long version of an argument we made in short form. Rather than a product tour, it is an attempt to state precisely what changed, why the previous fifty years of integration technology did not change it, what can go wrong, and what discipline makes it work. If you run a company with more than two systems, or you build software for such companies, it is written for you. The argument is deliberately short; the practical companion, chapter by chapter, starts here.

1. The job nobody designed

Take any company with an ERP, an inbox, a spreadsheet, a bank portal, and the state's e-invoicing system, and you will find work whose only purpose is moving information from one of those to another. Call it the interface layer. It has five recurring shapes:

• Transcription. Reading a value in one place and typing it into another: invoice totals from a PDF into the ledger, order lines into a supplier portal.
• Reconciliation. Deciding that two records are the same thing: the supplier spelled three ways, the payment that matches this invoice, the delivery that closes that order.
• Translation. Converting meaning between systems that model the world differently: their "customer" is our "account", their "net 30" is our payment-term code 4.
• Routing. Deciding where something goes and who must see it: which cost center, which approver, which folder.
• Exception handling. Everything that does not fit: the credit note without an invoice, the scan that is half legible, the duplicate that is not quite a duplicate.

Three properties make this layer expensive. It is performed by people who know the business, because the judgment calls require that knowledge. It is invisible: no org chart has a box called "interface layer", so its cost is never summed. And it grows faster than the company: with n systems there are up to n(n-1)/2 seams, and every seam is a place where someone reads from one side and writes to the other.

2. Fifty years of trying

Every generation of enterprise technology has attacked this layer. The pattern of what each achieved, and where each stopped, is the whole argument.

Electronic data interchange gave large trading partners structured messages for orders and invoices. It worked where both sides invested in rigid formats and stable relationships. It did nothing for the long tail of smaller partners, unusual documents, or anything not anticipated by the standard.

Middleware and service buses addressed the n-squared problem with a hub: every system talks to the bus, the bus talks to every system. Mappings became a specialist's job, expensive to build and brittle when either side changed. The hub moved the seams; it did not remove the judgment inside them.

APIs and integration platforms made the plumbing cheaper and the connectors more numerous. Deterministic mappings became cheap. But a mapping is still a rule, and rules only cover the cases their author imagined. The exceptions kept flowing to a person.

Robotic process automation took the most honest approach: automate the human's clicks exactly as they happen. It also revealed the problem most clearly. A robot that replays a workaround encodes the workaround. When the screen changes, it breaks; when the case is unusual, it stops and raises a ticket, which lands on the same person.

Look at what these waves have in common. Each automated the deterministic half of the work, the part expressible as a rule, and stopped at exactly the same wall: the point where the next step depends on reading something ambiguous, remembering a past decision, or judging plausibility. Half a century of tooling, one wall.

3. Why judgment was the wall

Four things made the judgment half resistant to code.

Open-ended input. The inputs to the interface layer are documents, emails, scans, and screens, produced by other organizations for humans. Their variety is unbounded. A rule that parses this month's invoice layout fails on next month's.

Drift. Even structured sources change: a field is renamed, a partner switches formats, a new tax code appears. Rules decay silently, and the decay surfaces as exceptions.

Context. "Is this the same supplier?" cannot be answered from the record alone. It requires knowing that the entity was renamed last year, that this is the branch office, that the finance team decided in March to treat the two as one. That knowledge lived in a person's head.

The long tail. The exceptional cases are individually rare and collectively dominant. Automating the common path removes the pleasant part of the job and concentrates the person's day on the hard part. The headcount does not move; the job gets worse.

4. What changed, precisely

Four capabilities arrived together in large language models, and it is the combination that matters.

Reading at human level. A model can read a scanned invoice, an email thread, or a portal page and extract what a person would extract, without a layout-specific rule. This covers transcription and translation, the two shapes that generated the most volume.

Resolution in context. Given a candidate and the records it might match, a model can weigh spelling, address, tax id, and history and decide, or say it cannot decide. This is reconciliation, the shape that generated the most judgment.

Acting. Models can call tools: query a system, write a record, send a message, run a calculation. Reading without acting would only have produced better reports. Acting closes the loop.

Memory. A decision stated once ("treat these two entities as one", "invoices from this supplier go to that cost center") can be stored and applied consistently afterward. This is what turns a clever reader into a colleague who learns the house rules.

Now the limits, stated with the same precision. These systems are probabilistic: they can be confidently wrong, and they do not know when. They have no authority of their own: a model that can write records is a model that can write wrong records at machine speed. They cost money per step, so wasteful loops are real. And they are only as good as what they can see: an assistant that cannot read your documents is a chat window.

None of these limits is fatal. All of them dictate the architecture.

5. The loop that makes it safe

The interface layer, done right, is a loop with a specific shape.

Each stage has a discipline attached, and the disciplines are what separate a working system from a demo.

Provenance on every fact. Everything extracted carries its source: which document, which page, which field. The cost of verifying a claim drops from "find the original" to "one click". Far from a nicety, this is what makes the human approval step fast enough to be real rather than a rubber stamp.

A hard confirmation boundary. Reading, resolving, and drafting are free to run. Anything that leaves the workspace or mutates a record of consequence waits for a person: sending, deleting, changing money-bearing fields. The boundary has to live in code, not in a prompt, because prompts are suggestions and boundaries must be guarantees.

Idempotency. Every synchronization is keyed by external identifiers, so running it twice produces nothing new. Systems that pull from other systems will be re-run, by schedules and by impatient people, and duplicates are the classic way an automation destroys trust.

Least privilege, assuming compromise. Credentials are scoped to what the job needs, rate-limited, and stored as if they will leak one day, because some of them will. A key that can only read invoices cannot email your clients.

Fail toward the human. When the evidence is insufficient, the correct output is "I could not determine this, here is what I found", never a plausible guess. A system that improvises on the hard cases is worse than one that never existed, because its errors arrive with the confidence of a system.

An audit trail. Every action recorded with who, what, when, and on what evidence. Less for compliance than for the Tuesday when something is wrong and someone must find out why in ten minutes.

6. The economics, honestly

Where does the time actually go in the interface layer? Rarely in the happy path. It goes into exceptions, lookups, and the switching cost of holding three systems in one head. The value of automating the layer is therefore the fraction of judgment calls the system resolves correctly, multiplied by the cost of the human minute it saves, minus the cost of the ones it gets wrong, and only marginally "the robot does the typing".

That formula has a consequence for how to evaluate any vendor, including us. The numbers that matter are measurable:

• Resolution precision. When the system says two records match, how often is it actually right, judged by the final outcome?
• Approval rate. How often does the human accept the proposal unchanged? A high rate means the judgment is being taken; a low rate means the human is still doing the job with extra steps.
• Escape rate. How many errors reach the ledger, the client, or the tax authority?
• Time to close. Per item, from arrival to recorded, with the human in the loop.

A vendor who cannot report these on your data is selling a feeling. The measurement is the product.

The cost objection

The first objection to all of this is cost: models are paid per token, and the interface layer runs all day. Three things make the objection weaker than it sounds.

The comparison is against a human minute, and the gap is enormous. A resolution call that reads an invoice and a handful of candidate records costs a fraction of a cent; the minute of a person who knows the business costs more by orders of magnitude. The price of tokens has also fallen steeply year over year and shows no sign of stopping, while the price of the human minute rises.

Most of the loop does not need the strongest model. Classifying a document, routing a trigger, extracting fields from clean XML, checking a plausibility rule: these are small-model tasks, fast and cheap, and they are the bulk of the volume. The strongest models are for the hard tail: ambiguous reconciliation, multi-document reasoning, a half-legible scan. A tiered design, small model first and strong model on the exceptions, spends the expensive tokens exactly where the human minutes used to go.

Some of it needs no model at all. A structured e-invoice is an XML with a schema: the supplier's tax id, the total, the due date, the VAT lines are read by a parser, exactly and for free, and a model that re-reads them is wasted spend. Keyword search is tokenization plus scoring and finds an invoice number or a tax id better than any embedding. A fixed set of commands ("pull the invoices now", "what is due this week") is a small classifier and a dispatch table. Scheduled triggers are a clock. The discipline is to push every task down to the cheapest tier that meets the precision bar: parser and rules where the input is structured, small model where it is semi-structured or the choice is among a closed set, strong model only where reading is open-ended, the match is ambiguous, or the next step must be planned. Most of the volume lives in the bottom two tiers. Most of the value, and nearly all of the risk, lives in the top one.

The real cost risk is waste, not price. An agent that loops, re-reads whole documents it could have retrieved from, or re-sends the same instructions on every call burns money without producing decisions. The disciplines are known: retrieval instead of whole documents, caching of the parts of a prompt that repeat, a budget per run, cooldowns on triggers, batching of scheduled work. Token economy is an engineering practice, and it is where most of the cost difference between implementations lives.

On running models on your own hardware: a mid-sized open model on a decent server can carry the small-model tier well, and for organizations with strict data-residency requirements that is a legitimate design. Two honest caveats. The hard tail is exactly where smaller models are weakest and where errors cost the most, so a local-only design needs the confirmation boundary more, not less. And a model server is an operations commitment: updates, evaluation, capacity. For most companies, a tiered design hosted inside the EU delivers the same economics without a closet full of GPUs. The right metric for any of these choices is cost per correct decision, never cost per token.

7. What this means for ERPs

The ERP is the system of record: the ledger, the stock, the contracts, the truth. That role does not go away, and any argument that AI replaces the ERP misunderstands what an ERP is for. What changes is the system of work: the surface people touch during the day. That surface is moving out of the ERP's forms and into a layer that reads what arrives, resolves it against the records, proposes the entry, and writes it back once approved.

Three predictions follow.

Connectors become a commodity. As more systems expose APIs and standard protocols emerge for tools to talk to models, the question "do you have a connector for X" loses weight. The plumbing was never the hard part; the previous four waves proved it.

Judgment becomes the product. The differentiator becomes which decisions the layer can take reliably, with what evidence, under what boundary. This is where the disciplines of section 5 stop being engineering hygiene and become the competitive substance.

Bolted-on chat is not an interface layer. Expect every ERP to grow a chat window. A chat window without provenance, without memory, without tools, and without a confirmation boundary is a search box with better grammar. The test is simple: ask it to do the reconciliation, then ask it how it knows.

8. What stays human

Three things, and they are not consolation prizes.

Choosing. Between two suppliers, two offers, two ways to structure a deal. The system can lay out the comparison with every number; the choice carries responsibility, and responsibility does not transfer to software.

Committing. A promise to a client, a signature, a payment released. These are acts of the company, made by people the company has authorized.

Owning the error. When the interface layer gets something wrong, a person decides what to do about it, and that person needs the audit trail from section 5 to do it in ten minutes rather than a day.

Nobody is replaced. The person who did this work sees their day change from doing the transfers to approving them, and approval is precisely the part that always needed a human. The hours saved are the hours that never needed one.

9. Where we are

We build one implementation of this thesis, and we would rather be judged on the specifics than on the argument. Today the layer reads documents, scans, and Romanian e-invoices pulled from the state's SPV system once a company connects its account; it fills and updates data tables from what it reads; it reads and writes Google Sheets and Drive; it calls systems that expose an API from scheduled workflows; it exposes the workspace to any tool that speaks the Model Context Protocol; and every consequential action stops at the confirmation boundary. What we do not have yet: named one-click connectors for specific ERPs, and the broader write-back that comes with them. Pilots are how we learn which judgments are safe to take next, and in what order.

If the argument above describes a job in your company, we would like to see the job.