The Interface Layer, part 1: the job nobody designed

This is the first chapter of The Interface Layer, in practice, the working companion to the thesis. The thesis says why; these chapters say how, and they do not retell the argument. Written by the team at iTailors, the company behind Agentique, for the people who run companies and the people who run their back offices. This chapter is about finding the job. The ones that follow are about handing it over safely, measuring whether it worked, replacing forms with intake, and how a Romanian company starts.

Three offices

A distributor. Forty suppliers, a few hundred incoming invoices a month, an ERP, an accounting program, a bank portal, the state's e-invoicing system, and a shared inbox. One person in the office knows how they all fit. Each morning she downloads what arrived in SPV, opens each invoice, finds the purchase order it belongs to, checks the delivery note against it, fixes the supplier name that came in spelled a new way, types the totals into accounting, files the PDF in the right folder, and emails the two suppliers whose quantities did not match. She was hired as an office manager. Nobody wrote this list into her contract; the list wrote itself.

A transport company. Trucks, clients, subcontractors. A dispatcher matches delivery confirmations to orders, invoices the client from one screen, enters the transport declaration in another, answers "where is my shipment" from a third, and keeps the real state of the world in a spreadsheet that only he understands. When he is on holiday, the spreadsheet is on holiday too.

An accounting firm. One accountant, thirty-five client companies. Every month, thirty-five downloads from SPV, thirty-five reconciliations against what each client sent by email or by photo, a hundred small questions asked on WhatsApp because an invoice has no purchase order or a scan is half legible, and thirty-five sets of entries. The accountant's expertise is tax. Most of her hours are logistics.

The three have nothing in common on paper. They share one job: moving information between systems that never learned to talk to each other, with judgment applied at every step. Nobody designed that job. It accreted, one system at a time, and it landed on whoever was closest.

The five shapes

Look closely at any of the three offices and the job decomposes into five recurring motions.

Transcription. A value read in one place and typed into another. Invoice totals from a PDF into the ledger. Order lines into a supplier's portal. Delivery quantities from a photo into the ERP.

Reconciliation. Deciding that two records describe the same thing. The supplier known under three spellings. The payment that settles this invoice and not the other one with the same amount. The delivery that closes that order.

Translation. Converting meaning between systems that model the world differently. Their "customer" is our "account". Their payment term is our code 4. Their product code is our internal SKU, except for the ones that were renamed last spring.

Routing. Deciding where something goes and who must see it. Which cost center. Which approver, given the amount. Which folder, which client, which month.

Exceptions. Everything that does not fit. The credit note without an invoice. The duplicate that is not quite a duplicate. The scan cut off at the bottom. The email that says "same as last time" about a last time nobody remembers.

The first three shapes generate volume. The last two generate judgment. A useful thing to notice already: every previous attempt to automate this job attacked the first three and stopped at the last two. That is chapter two's subject. For now, the point is that the five shapes are how you will recognize the job when you go looking for it.

Why it grows faster than the company

Systems do not exchange information with each other; they exchange it through pairs. With two systems there is one seam between them. With four there are six. With six there are fifteen. The formula is n multiplied by n minus one, divided by two, and it is merciless: every system you add creates a seam with every system you already have.

Now count honestly what a system is. The ERP and the accounting program, obviously. But also the bank portal, the e-invoicing system, the transport declaration portal, the supplier's portal, the shared inbox, the WhatsApp group with the drivers, and the spreadsheet that holds the real state of the world. Each of those is a place information lives and must be moved out of by hand. A company that thinks it has three systems usually has nine, and thirty-six seams.

Here is the part that stings. Most of those seams were added in the name of saving time. A new portal, a new tool, a new channel, each one useful on its own, each one adding seams to everything that already existed. The company gets more capable and the person in the middle gets more seams. The seams never appear on any invoice. They appear as the office manager staying late.

What it really costs

The visible cost is the hour: the time a knowledgeable person spends transcribing, matching, and re-keying. That hour is real and is the smallest part.

Switching. Every seam is a change of screen and a reload of context. A person crossing fifteen seams in a morning is not doing fifteen small tasks; they are doing one large task with fifteen interruptions built into it. The work that requires concentration, the actual judgment, gets the leftover attention.

The error loop. A number mis-keyed in March is found in April by someone else. Finding it costs more than typing it did; fixing it costs more than finding it; explaining it to the supplier, the accountant, and sometimes the tax authority costs more than all of the above. The interface layer is where errors enter, and the layer's hourly cost never includes the loop.

Latency. Things wait for the person. The invoice is approved when she gets to it. The client learns where the shipment is tomorrow. The month closes when the last reconciliation is done. None of this shows up as cost; it shows up as a company that is slower than its systems.

Key-person risk. The day the person is sick, on holiday, or gone, the company discovers it was running an undocumented system whose only copy lived in one head. The handover, if there is one, is a list of screens and a shrug at the judgment calls.

The talent cost. You hired a capable person because the judgment calls need one. Then you filled a large part of their day with the copying that surrounds the judgment. Capable people notice. The ones who stay learn to work around the seams instead of through them, which is how the spreadsheet with the real state of the world is born.

Why nobody sees it

There is no line in the budget called "interface layer". The work is distributed across roles that all have other names. The people doing it are competent and quiet, which is exactly why they were given it. Management sees the outputs, the closed month, the paid invoices, and not the seams that produced them. Software vendors sell modules, not seams; a demo shows one system doing its job beautifully, never the moment its output has to enter a different system by hand. Consultants sell new systems, and a new system adds seams to every old one.

So the job stays invisible, and invisible costs do not get fixed. The first move, before any technology, is to make it visible.

The one-page audit

This takes an hour, and it is the most useful hour a company can spend before touching any AI. Sit with the two or three people who actually do the work; they know the seams better than anyone.

List every system. Everything that information lives in. Include the inbox, the messaging groups, the portals, and the spreadsheets. If a person moves information out of it by hand, it is a system.

Map the seams. For every pair that exchanges information through a person, write one line: what moves, from where to where, who does it.

Time each seam. How often it happens and how many minutes each time. Be honest about the interruptions; a five-minute task done twelve times a day is an hour and a broken morning.

Name the judgment. For each seam, what decision does the person make while crossing it? Matching two records, classifying a document, choosing a cost center, judging whether a number is plausible, deciding what to do with an exception. Write it in plain words. This column is the one that matters later.

Rank. Multiply hours by month, weigh by what an error at that seam costs, and sort. Expect a handful of seams to carry most of the hours and most of the risk. The inventory will show you which.

What you hold at the end is the seam inventory: one page that describes the job nobody designed, in the company's own words, with the judgment inside each seam named. Most companies have never seen this page. Reading it is usually a quiet moment.

What to do with the page

Two things not to do. Do not buy a new system to fix it; a new system is a new set of seams. And do not automate the easy seams first because they are easy; the easy seams are the ones where a machine already does most of the work, and the hours are in the hard ones.

Look at the judgment column instead. For fifty years, that column was the reason the job stayed human. Chapter two is about why that stopped being true, and where it is still true.

The seam inventory is also the document we ask for in a first conversation. If you make one, we would like to read it.