3.5x Evaluation After Clean Books and Agentic Ops (A Gallery Cautionary Tale)

3.5x Evaluation After Clean Books and Agentic Ops (A Gallery Cautionary Tale)

Data cleansing is the work of making one record mean one thing. A SKU gets one name. A count matches the shelf. A book entry matches the sale. Dirty data is the opposite. Once AI agents run operations, they repeat every error at speed, so the cleanse has to come first.

I write this for PE operating partners, mid-market operators, and family office principals who are about to let agents into fulfillment, inventory, invoicing, and accounts.

An art gallery business had 5+ years of SKU and books mess, plus fulfillment pain. I will not name it. I will not point at a city, an artist, or an owner. The file I can stand on is the mess, the order we built, and the result.

What is data cleansing?

Data cleansing is the repair. You decide which name, which count, and which book entry the business will trust, and you retire the other copies. Data cleanup is the same job under a shorter name. You are fixing the records so a later system can act without someone in the middle guessing which row is real.

Garbage data is dangerous when agents enter ops. A person can see two names for one item and pause. An agent will fulfill, invoice, and post whichever row it was given. It will do that on every order. The error stops being a single mistake. It becomes the process.

Dirty data has a shape. Here is an illustration of that shape. It is an example of the failure mode, kept separate from the gallery file. A SKU recorded twice under two names. One name is the catalog title. The other is the shorthand the floor uses. Inventory reconciliation then fails in both directions. You buy stock you already hold. You promise a piece you cannot ship. The books can record yet another version of the same sale.

Data readiness for AI is the question under that illustration. Can an agent read one truth, or only a pile of records that almost agree? If two people can pull two official answers for the same SKU, you do not have a source of truth yet. You have files.

Why we cleaned the data first

Watching agents touch dirty SKUs is the fear that made us fix the data first.

The gallery was about to hand fulfillment, inventory, invoicing, and accounts to agents. A dirty SKU would not stop at one bad shipment. The agent would treat that SKU as law and repeat it through every one of those jobs. I wanted that fear in the room before anyone wired a write path.

The pain was already operational. Fulfillment hurt. The floor and the ledger were not telling the same story. 5+ years is a long time for names to drift. I am not attaching a SKU count, an error rate, a team size, or a calendar to that mess. The fact is the mess, and the fulfillment pain that came with it.

How the work was built

Backfill and cleanse before any agent runs. The order was the design.

First we backfilled the garbage data. History had to land in one place a person could audit. Names resolved to one SKU. Counts reconciled to what could actually ship. Book entries lined up with the sale. That pass is data cleansing on a live operation. It is also the backfill. An agent cannot read a clean table that is missing the years you still have to ship and explain.

Then the agents ran. Agentic fulfillment. Agentic inventory. Agentic invoicing. Agentic accounts. Each one reads the clean source of truth and writes back to it. The agent is a worker on that source. A second set of books would split the truth again.

The path we refused is the right side of the diagram. Dirty data goes straight into the agents. The agent issues an invoice from the wrong name, posts it, and the next run treats that invoice as evidence. Wrong invoices multiply. The speed is real. The speed is applied to the error.

What a 3.5x evaluation stands on

The business scaled. The books were clear for investment. Clean books plus tech led to a 3.5x evaluation.

I will leave that as the file. A 3.5x evaluation is the result we can name. I do not have a dollar figure to put beside it. I do not have a timeline or a headcount. Adding any of those would be fiction.

What I trust is the order. Clean books, then tech. A buyer could read the books. Tech on top of the old mess would have industrialized the mess. The evaluation followed the clean books and the tech together.

How dirty is the SKU truth?

If you buy or operate a company that wants agents in the warehouse and the ledger, ask these before you fund the agent.

• How dirty is the SKU truth? Can two people pull two names for the same item and both look official?
• Does inventory reconciliation land on one count, or on a meeting where someone picks a number?
• Can invoicing name the same sale the books will post, without a person rewriting the line?
• If an agent ran fulfillment tonight on the current file, which errors would it copy into every order?
• Who owns the cleanse, and is the backfill finished before the agent can write?
• Would a buyer, reading only the books, see a business that is clear for investment?

Data readiness for AI is a diligence item. If the SKU truth is dirty, an agent project scales the dirt. Ask the questions in the room where the money is decided. A demo on a tidy sample file will not show you this.

What I keep from the file

Three things, then I stop.

The personal one is the fear. Watching agents get close to dirty SKUs is what made us clean first. I would rather delay the agent than explain a stack of wrong invoices the software produced on purpose.

The build one is the order. Backfill and cleanse. One source of truth. Then the agentic loop for fulfillment, inventory, invoicing, and accounts.

The investment one is plain. Clean books plus tech led to a 3.5x evaluation. The gallery scaled, and the books were clear enough for that evaluation to be real.

I do not have a quote from the client. I do not have a vendor list I will hang on this page. The work is the order. The result is the evaluation.