A customer phones the shop with an invoice number and a question about their bike.
We can find the sale. What we cannot necessarily establish is exactly what we built. A component was substituted during assembly, but the change never made it into the record. The invoice identifies the transaction; it does not resolve the customer’s question.
This happened regularly in my bicycle business, and I've seen it happening in many others. It was a recording gap. Something had changed in the physical world without the corresponding change being preserved in the information we would later use to support it.
At build time, the substitution might have been understood perfectly well by the people involved. Later, somebody else needed that understanding. The business had completed the work without retaining everything it would need to explain the result.
That is where I would begin a discussion about preparing for business AI. Before asking how intelligently a system can answer, I want to know what account of the business it has been given to work with. Ideally, information collection should be a passive consequence of doing the work. If fitting a component includes scanning its serial number against the build, the manufacturing process also creates the record that somebody will later need for support. Nobody should have to reconstruct that history afterwards.
That is the relationship I want between passive information capture and active information use: ordinary work creates the context, and people or agents deliberately draw on it to investigate, decide and act.
What the record can actually establish
A business does not retain a complete account of reality simply because it records transactions. Each record serves a purpose and leaves other things out.
An invoice establishes what was billed. A sales order records a commercial commitment. A bill of materials, usually shortened to BoM, describes the components intended for a build. The manufacturing record needs to establish what happened during that particular build.
Those accounts should relate to one another, but they are not interchangeable.
An editable BoM and good operating hygiene can help accommodate the substitutions that real work requires. There is an important distinction, though, between changing the specification for future builds and retaining what was fitted to one particular bicycle. Today’s standard specification cannot, on its own, establish what left the workshop previously.
The practical requirement is to preserve the actual build, its departures from the intended specification and its connection to the individual product. Odoo provides manufacturing records and serial-number tracking that can support this, when appropriately configured and used. The presence of those features does not establish that a substitution was recorded. Odoo’s documentation on manufacturing with serial numbers describes the tracking foundation.
An agent searching an unchanged specification would inherit the same uncertainty as the person answering the phone. If the substitution was never recorded, more confident reasoning would not supply the missing fact.
The first preparation for useful AI is therefore an operational one: make the ordinary record sufficiently faithful to the work.
Where does a business remember?
We often talk about organisational knowledge as though it were a collection of things employees know. In practice, the ability to answer a question depends on a wider arrangement: people, records, tools, routines and the connections between them.
Edwin Hutchins explored this in his 1995 paper, How a Cockpit Remembers Its Speeds. He examined remembering as an activity distributed across a flight crew, instruments and other representations, rather than locating the capability solely inside an individual pilot’s head.
I find that a useful way to think about an operating business. The question becomes how the arrangement allows someone to establish what they need to know. A capable person working with incomplete records has a different problem from an inexperienced person who does not know which records to examine. Improving one does not automatically resolve the other.
In the bicycle example, a mechanic might remember the substitution. That could rescue the immediate conversation. But the business’s ability to support the customer would still depend on reaching the right person while they could remember the right build.
A better arrangement allows the information to survive the original participants. It gives another colleague a route to establish what happened, examine the evidence and continue the work.
That was part of what I was trying to achieve in my first Odoo implementation. More of the connections needed to become usable by people who had not assembled them.
Centralisation is a question of relationships
This is why I think data centralisation is easily undersold. Its value is often described in terms of having fewer applications or producing a consolidated report. Both can be useful, but the more consequential benefit is preserving continuity across activities.
The customer on an invoice needs to be recognisable as the customer on the order. The delivered product needs to connect to the relevant build. A later repair needs to concern the bicycle that actually exists, including recorded changes since it was first supplied.
Putting files in one place does not establish those relationships. Neither does using the same word for things that mean something different in each department.
My supplier onboarding work at Lukiad exposed this repeatedly. Files arrived through different routes, used different conventions and sometimes separated related information across several sources. I had to clean, combine and transform them, then map categories and variation colours into conventions the business could use consistently.
Having the files available was the beginning. Making their contents mean something consistent was the work.
ERP gives those relationships an operational centre. It can connect a commercial promise with the stock, purchasing, production and financial activity needed to fulfil it. Specialist applications can retain useful roles, provided their records have dependable connections to that centre.
Leaving finance outside my first implementation for too long taught me the cost of an incomplete connection. Operational work continued into financial consequences, whether or not I had designed the information flows properly. An application boundary did not make that relationship disappear.
Centralisation, in this sense, means establishing a coherent account of the operation. It does not require every document to occupy the same database. It requires us to know what each source represents, how the records relate and which account we should rely on for a particular question.
Availability does not guarantee investigation
Now suppose the substituted component was recorded correctly.
Someone answering the customer still has to find it. They may need to follow the invoice to the sales order, identify the individual bicycle through its serial number, examine the manufacturing order and compare the build with its specification. Relevant service history may add another layer.
That is a substantial investigation for what began as a phone call quoting an invoice number.
An experienced person may know instinctively to follow those connections. Someone else may stop at the first plausible answer. Training, familiarity, workload and the design of the interface all influence how far the investigation proceeds.
This develops a point I explored in Signal-to-noise: information being available does not establish that it will receive attention or influence the decision. A business can retain the necessary evidence while still failing to use it.
That second gap is particularly interesting for agents.
An appropriately designed agent could be instructed to follow the relevant chain of records, check for amendments and return an account of what it found. Its method could be tested against cases where the invoice alone gives an incomplete answer.
The opportunity is to make a useful depth of investigation more consistently available. We can give the system a method that looks beyond the first screen, rather than depending entirely on the instincts of whoever happens to take the call.
That does not make thoroughness automatic. An agent can also stop too early, select the wrong record or mistake a current specification for historical evidence. Its investigation needs designing and checking, just as the recording process does.
Nor does it require sending every available document to a model at once. A useful investigation follows the question, retrieves relevant evidence and goes deeper where the answer remains uncertain.
What changes when the interface becomes headless?
By headless ERP, I mean an arrangement in which more work can be initiated through agents and connected tools, without requiring the user to navigate the application’s screens themselves.
The support request can remain an ordinary question. Behind it, an agent could examine the connected records and prepare an answer with references to the evidence. Where the records disagree, it should expose the disagreement. Where the fitted component cannot be established, it should identify what needs confirming rather than quietly substituting the expected specification.
The screens may become less prominent in that interaction. The business model beneath them becomes more consequential.
An invoice, a manufacturing order and a serial number are useful because they represent different things and connect in meaningful ways. Those distinctions allow an investigation to progress. They also allow us to check whether the resulting answer is supported.
This is why I see ERP as central to the agentic future. It provides an organised basis for relating what the business promised, what it did and what happened afterwards. An agent working across those relationships has something more useful than a collection of documents that happen to mention the same customer.
The interface can make the question easier to ask. The quality of the operating record determines how well it can be answered.
Everyday work becomes useful again
Much of that record is generated while people do the work. Responding to a lead, revising a quotation, placing an order, fitting a component, delivering a product and raising an invoice all produce information with potential value beyond the immediate task.
Ideally, capturing that information should be a passive consequence of completing the work properly. If fitting a component includes scanning its serial number against the individual build, the manufacturing process also creates the history somebody will later need for support. A substitution becomes part of the record as it happens, without requiring a separate account to be written afterwards.
That is a process-design responsibility. The system needs to make recording what actually happened part of the task, so that useful context survives without depending on somebody remembering to document it later.
The aim is passive information capture followed by active information use. People or agents can then investigate that history, examine the relationships and use what they find to inform the next decision. Technology has made this viable - we still need to design it in.
When useful context survives, the next task can begin from a better position.
Consider quotation. In my experience of sales, a sensible ballpark number is the first step of the battle. A salesperson who cannot provide one struggles to establish whether there is a viable conversation to have. Preparing a detailed quotation takes time, and even a carefully prepared one may never become an order.
Connected records of previous work could help an agent prepare that starting point: what was supplied, what changed during delivery and which costs differed from the original assumptions. Current prices, requirements and technical constraints would still need checking. History gives the investigation somewhere to start; it does not make an earlier price valid today.
The same principle extends to support. A recorded substitution first helps complete a build accurately. Later, it can help identify the right replacement, understand a customer’s problem or avoid repeating an unsuitable recommendation. The value of capturing the event extends beyond the person and task that created it.
There is a cumulative possibility here. As ordinary work leaves a better connected history, future investigations can draw on it. Those investigations may expose gaps in what the business records, allowing the workflow to improve. That improvement requires deliberate changes; neither collecting more data nor running more AI guarantees that the business learns.
Preparing the record, and the method
I would start preparing for this future with a real question from the business, then follow the evidence needed to answer it.
If a customer calls about a product, can someone establish which individual item they received and what has changed? If a quotation needs revising, can they recover its assumptions? If the record is incomplete, is there a way to confirm the missing fact and preserve the correction?
That is a more useful starting point than attempting to capture everything. Recording has a cost, and access needs to reflect the purpose of the work. We need the context that could materially change an answer, together with a way to recognise when it is missing.
We also need to distinguish the investigation from the action that follows. Establishing which component was fitted does not automatically authorise a replacement order or a promise to the customer. Those commitments need their own permissions and ownership.
In the Entropy article, I described the effort required when the relationships between activities become harder to follow. A connected operating record is one way to reduce that repeated reconstruction. An agent may then help more people use it, without requiring everyone to develop the same familiarity with every corner of the system.
The customer who phones with an invoice number should not need to know where the answer is stored. Increasingly, the colleague helping them may not need to know which screens to visit either.
Somebody still needs to have recorded what happened, and the investigation still needs to establish what the evidence supports.
That is the value I see in preparing ERP for the agentic future: the ordinary work of the business becomes a dependable resource for the next person, question and decision.