Calogero Bonasia

Four Ways of Saying “Customer” (1/5): Working Pipes, Broken Registers

Part 1 of 5.

Abstract. Companies are connecting their artificial intelligence assistants to almost every internal system, and technically the connection works. A question older than computing remains open: what do the words an organization uses to record its work actually mean? I argue that connecting a system to data and establishing what the data mean are two distinct problems. The first belongs to engineering, the second to semiotics and archival science.

I examine some recent contributions from the consultancy Enterprise Knowledge and set them against the experience of a Roman official of the first century. Sextus Julius Frontinus, curator of Rome's water supply, found working pipes and registers that no longer matched reality. Many companies are in the same condition today.

I draw three theses from this. The meaning of a company's words must be written down and entrusted to someone accountable. Content readiness is assessed before tools are chosen. The shape of the graph follows from the questions it will have to answer. I add a caveat: the semantic layer works as a local, revisable dictionary, and fails when it claims to become a perfect language.

In the master data system, customer means the legal entity that pays. For the sales office it means the main contact. For technical support it means the site where the machine is installed, which may belong to a third party.

For accounting, the customer is the party named on the invoice, which may be yet another company. The same word serves four offices to mean four different things.

The same happens with job. It is a production batch on the shop floor, a cost center in accounting, a project in management control. Deadline changes meaning too: for the tax office it is binding, for the sales office it is a guideline.

Anyone who has worked in a company for a few years moves from one meaning to another without noticing. The distinctions are written down nowhere and live in people's memory. Today companies connect their artificial intelligence assistants to almost every internal system, and technically the connection works.

The distinctions, however, stay where they were. Connecting a system to data and establishing what the data mean are two different problems. The first belongs to engineering. The second belongs to semiotics and archival science, and predates computing by many centuries.

Almost all the technical ideas I examine come from a single source: Enterprise Knowledge, a firm that sells consulting on the problems it describes. I say so at the outset, because whoever sells a solution has an interest in showing that the problem is widespread. The firm's texts offer exemplary cases, built to illustrate a principle.

What they lack are systematic measurements of costs and benefits; when I discuss them, I can only say which way the scale tips. To balance those pages I turn to two authors who have nothing to sell: a Roman official of the first century and a semiotician of the twentieth.

I begin with the connection, which is the solved part. Within a few months the Model Context Protocol, MCP, has become the de facto standard through which artificial agents connect to a company's tools and archives. An agent here means a language model authorized to call external programs. The enthusiasm is justified.

For the first time there is a common way to open a channel between a language model and the ERP, the contract repository, the project system.

Eloragh Espie, in an article from August 2026, observes that the protocol's name suggests more than its specification establishes. Model Context Protocol evokes context, while the protocol standardizes the connection to context. The meaning of the data passing through it lies outside its scope, as it does for any transport protocol.

The specification is consistent with its own purpose. The misunderstanding arises among those who adopt it believing they have solved, along with the channel, the problem of what flows through it.

The same article contains an anecdote. At a conference, a junior colleague asks Espie why experts speak of GraphRAG as if it were a dirty word. The term refers to systems that retrieve information from a graph to build a model's answer, and every serious project on company data needs a retrieval mechanism.

Espie replies that the experts' distrust concerns retrieval systems without semantic grounding, which produce inconsistent results. Retrieval as such is something no one can do without.

To describe the situation Espie uses a plumbing image: a pipe welded to perfection carrying untreated water. The image has a precise historical precedent, and an Italian one.

In 97 AD the emperor Nerva entrusted Sextus Julius Frontinus, senator, former general and governor of Britain, with the care of Rome's waters. Frontinus began with an inventory. His report to the emperor, the De aquaeductu urbis Romae, describes the aqueducts one by one and compares the flows entered in the registers with those measured at the intakes.

The quinaria was originally the size of a pipe, and Frontinus uses it as a unit of flow: he counts the cross-section of the conduits and ignores the speed of the water.

The accounts do not add up, and for two reasons. The first lies in the registers themselves: they record 12,755 quinariae coming in and 14,018 going out, that is, 1,263 more than enter. The second emerges from the measurements.

At the intakes the water is far more abundant than the registers declare, and Frontinus attributes the gap to errors of calculation made from the start. Between the intakes and the distribution, by his reckoning, some ten thousand quinariae are intercepted.

They are diverted by the service's own staff, the aquarii, who carry public water to fields, shops, even attic rooms.

Historians debate how far the treatise is also a political document (Taylor 2024). Even if Frontinus had sharpened his tone for political reasons, the core of the facts would stand.

The pipes worked, while the register that was supposed to describe them no longer matched reality, and no one in Rome could say exactly where the water went. Frontinus's merit was to rebuild the register.

A company that connects its assistant to every internal system finds itself in the Rome that Frontinus inherited. Water reaches everywhere. What flows through the pipes, and from which source, is by now known to few people, and only from memory.

Next: part 2, the dictionary's missing cuts.

Sources for this part

#artificial intelligence #english #organizational intelligence #semantic layer