Your AI has a plumbing problem

Robert De Niro as Harry Tuttle beside exposed ducts in Brazil (1985).
Robert De Niro in Brazil (1985).

Imagine a distributor whose sales system marks an order “closed” when the customer accepts the quote. In the warehouse, “closed” means the boxes have left. Let an agent confuse the two and it can report a shipment nobody has packed.

Now ask an agent whether that order can ship. It needs to identify the customer, find the right stock, check payment and follow the company’s release rules. Each answer may live in a different system. Even when the agent can read them all, somebody has to settle what the records mean.

This is why preparing a company for AI can involve so much ordinary software engineering and data work. Before you can delegate a decision, you need a reliable way to establish its facts. Behind the dashboard, the pipe marked “paid” may turn out to carry emails saying somebody intends to pay.

Start by following one order

At a growing midmarket company, the explanation may be spread across an accounting system, an old integration and the person who knows which numbers to ignore. An audit starts by following the work through those places. Ask someone to show you how they decide an order is ready, including the messages they send when the screen doesn’t tell them enough.

Take a sample of actual records. Trace each answer back to its source. Where do quantities change from cases to individual units? Which system records a shipment leaving? Who can approve an exception? Where does someone copy a correction by hand because the systems don’t share it?

You can start with an audit and diagnostic before committing to an agent build. You leave with a map of the workflow, a ranked list of repairs and a scope for the first build. That scope names the records it will use, the actions it may take, the questions a person still has to settle and the checks it must pass.

The nouns, verbs and adjectives

The nouns are the things the business deals with: customers, orders, products and shipments. Each needs an identity you can follow between systems. Two similar customer names might be a duplicate, or two different companies. Merging them on resemblance alone can put somebody else’s order on your screen.

The verbs are what people and software can do: reserve stock, approve a release, ship an order, issue a refund. These need rules. An agent that can read a payment record doesn’t automatically get to change it. A refund may need approval even when the amount looks right.

The adjectives describe those things: paid, available, overdue, disputed. In software, these become properties or statuses with agreed meanings. “Available” might mean stock on the shelf, or stock on the shelf minus everything already promised. The difference determines whether you can keep a promise to the next customer.

Classification helps put records in the right groups, such as invoices, purchase orders and shipping notices. We also need to identify sensitive information and enforce who can read or change it. Calling a file “confidential” accomplishes little if the application gives everyone access.

The plumbing has a name

ETL stands for extract, transform and load. Extract gets the relevant records from their source systems. Transform puts them into a form the workflow can use: consistent units, dates and identifiers, with known errors corrected. Load puts the result into the destination system. The original values and their source should remain traceable.

For our order, that might mean reading the sales record and warehouse count, converting cases into units using the product’s confirmed pack size, then making the result available to the shipping workflow. A missing pack size needs an answer from somewhere. A tidy table doesn’t supply one.

Data mining looks for patterns across records. It could help discover that one supplier repeatedly omits units, or that a particular import produces duplicate customers. Those findings tell you where to investigate and repair the process. A pattern alone doesn’t prove the correct value for an individual order.

Much of the implementation is familiar engineering: integrations, transformation scripts, validation, permissions and tests. Coding agents can help us write and check that software. People who know the business still have to settle what “available” means. Once they do, we can encode the definition and test it against records that used to cause trouble.

Repair the part you need

You don’t have to renovate every system before trying a useful workflow. Start with the records and rules needed to release one kind of order. Keep unresolved values visible, route exceptions to someone who can settle them, and make sure confirmed corrections survive the next import.

The repair also has to hold when tomorrow’s records arrive. That means checking for changed formats, failed imports and new contradictions, rather than declaring the data clean once and leaving the room.

Now ask the agent whether the order can ship. It should be able to show the stock, payment evidence and approval behind its answer—or identify exactly what is missing. The person at the desk can make the decision without crawling behind three systems to find the leak.

The distributor is an illustrative example. Technical background: IBM on data cleaning, ETL and data mining. Film still: Robert De Niro as Harry Tuttle in Brazil (1985), directed by Terry Gilliam. Cinematography by Roger Pratt. Frame via Film Grab.