Nearly every chemical manufacturer and distributor I meet wants to own the AI it runs on. That instinct is right about ownership and wrong about the object.
A digital lead at a large European manufacturer said it to me last week with no trace of apology, the way you'd describe the weather. "This is how we are. Renting capability from a vendor sits badly with us." His finance and IT counterparts are years into a CRM contract nobody can get out of, and they have no intention of signing another one.
In that conversation, as in most of them, ownership meant owning the software. Standing up an agent platform. Building assistants internally so no vendor sits between you and your own products. That's ownership of the software layer, and it leaves the intelligence underneath unowned.
There are four questions at the end of this piece. They test whether the knowledge your team builds up stays yours if you ever walk away from a vendor. I'd put them to any AI vendor in this industry, us included.
The question underneath the AI question
Most companies are asking which AI to buy. The better question is what you intend to do with your intellectual property now that AI is how people will reach it.
There are four layers a company could try to own here.
The model — but that market has several well-capitalised players competing to make it cheaper and more capable every quarter, and recent measurements of advanced AI capability show the length of task an agent can complete reliably roughly doubling every six to seven months. Any decision assuming today's model is the ceiling has an expiry date attached.
The training and fine-tuning — expensive, brittle, and obsolete the day the next base model ships.
The interface — buildable, increasingly cheap, and churning.
And the knowledge underneath all three, which is the only layer nobody can sell you, because it comes from your own people.
The improvement curve is usually offered as an argument against specialists like us. If the models keep getting better, they'll absorb chemical knowledge eventually — so why build on anything narrower?
Because models and interfaces get replaced, and whatever you build tightly around them gets rebuilt on someone else's release schedule. What your experts know is different, for a simple reason: no model can learn it, because it has never been written down anywhere a model could read. It lives in your people's heads and your private records — why a particular grade fails on a particular surface, which workaround your best customers actually use. That was true last year, it will be true next year, and no amount of model improvement changes it, because better models get better at public knowledge, not at your company's private experience. Capture it properly and every new model inherits it on day one — the faster the models improve, the more that captured knowledge is worth. The companies that lose here aren't the ones who picked the wrong model. They're the ones with nothing for the new model to inherit.
Your data is not your knowledge
The same digital lead said something in passing that was sharper than anything on our slides. Talking about everything sitting in his company's systems, he said: "that's data, not knowledge — and knowledge is a different question."
He'd put his finger on the gap the whole industry is standing in.
Your structured data lives somewhere. For some companies that's a Product Information Management application (PIM), though plenty of chemical businesses don't run one at all. More often it's the ERP and the CRM, with the remainder spread across spec sheets, technical reports, call reports, email, a document system, the regulatory database, a LIMS, and a great many spreadsheets belonging to individual people. Specifications, hierarchies, documents, account history.
Connect all of it and you have roughly fifty per cent of what an AI system needs. That part is tractable: connect it once, sync both ways, and it keeps itself current.
The other fifty per cent is the reasoning that turns a specification into the right recommendation. Corrections. Edge cases. Application advice. The objection a rep handled last Tuesday. It is written down nowhere and indexed by no one, and no amount of work on your systems of record will produce it, because it was never in them.
For a distributor the gap sits somewhere else, and it's wider. Your principals own the technical data. What you own is the mapping across dozens of portfolios — which grade from which principal solves which customer problem — and nobody has written that down because it was never anyone's product.
This is why "we already have a PIM" and "we don't need a PIM" are so often the same answer to the wrong question. Both describe where data is filed. Neither tells you whether the reasoning exists in a usable form.
What no model can supply
A frontier model knows adhesive chemistry in general. It doesn't know why your team approves a grade for one low-surface-energy substrate and quietly steers customers away from it on another.
It can read a datasheet. It can't know that the cure schedule your best customers actually run sits fifteen degrees off the published one, and why that's fine.
It can discuss substitution. It can't know which grade your team recommends when a raw material goes on allocation, or which technically correct answer has cost you an account.
That fifty per cent is earned. It lives in the exceptions, in what your specialists correct, in regional regulatory judgement nobody documented, and in the outcomes that reveal whether an answer was any good. It's the set of things your company knows without the company knowing them — because its people know them, and while everyone is supposed to write things down, nobody can write down everything.
A knowledge point is one of those pieces of reasoning, written down once, in a form a machine can use and a person can check. Not a document — a single claim, attached to the product or application it concerns, with an expert's name on it and a date. “This grade underperforms on this substrate above this line speed. This customer segment runs the cure fifteen degrees hot, and here's why that's fine.” Owning your intelligence means owning tens of thousands of those, in a store you control, that any AI system can read.
One of our customers has had their specialists enter more than thirty thousand knowledge points by hand across eighteen months. Not datasheets. Judgement, captured deliberately, structured so machines can use it. No general-purpose platform asks for that work, so it doesn't happen.
It isn't a clean-up project
The most expensive misunderstanding in this area is treating knowledge capture as a data clean-up: something with a start date, an end date, a scope, ideally delegated to a consultancy and then finished.
Walk through one of your own plants instead. A process unit holds tens of thousands of bolted flange joints. Every one is holding pressure. Every one has its own specification — size, gasket, torque figure — and needs the right tool, correctly calibrated, in the right sequence. One joint done badly is a leak, and the leak doesn't announce which joint it came from.
Nobody in your organisation would call joint integrity a project. A flange joint is never finished. It gets re-torqued on a schedule, by someone whose name is on it.
Knowledge behaves the same way. Thirty thousand knowledge points is thirty thousand small fasteners, each holding a claim in place, each degrading as products change, regulations shift, and the person who knew it retires. Which means ownership has to be named: recurring review cycles, staleness audits, and a person accountable for each knowledge area. Not a programme that ends.
Seven instruments, not one
Here's the part that took us a few years to learn. Different knowledge types need different capture instruments. There is no single one that reaches all of it.
Two are automated, and between them they cover the first fifty per cent: bidirectional sync with your systems of record (PIM, ERP, CRM, website), and document ingestion and enrichment — extraction across TDS, SDS, decks and spreadsheets, enriched into structured product passports for expert approval.
The other fifty per cent only comes from people, and three instruments do most of that work.
Review and corrections. Technical and sales staff approve or fix AI answers, and each fix is permanent. This is the one with the compounding property: one expert answers once, and every rep, portal visitor and API call gets that answer from then on. A wrong answer in a generic assistant, by contrast, comes back next week, because there's nowhere to put the correction so it sticks.
Passive capture from the flow of work. Customer email threads and call transcripts, copied in with no additional effort from anyone. This is where the objection a rep handled last Tuesday actually gets caught — not because someone remembered to document it, but because documenting it required nothing.
Demand signal. The most important one, because it decides the order of all the others. Analysis of customer and website queries, sample requests and gap analytics shows what the market is actually asking — so capture effort goes where revenue is, rather than where a project plan pointed eighteen months ago.
There are more — time-boxed capture sprints with experts, one product line at a time; workflows where specialists seed answers ahead of a launch — but the pattern is the point. Every instrument reaches a knowledge type the others cannot.
That is a toolset and a methodology, not a chat interface. It's also, candidly, why so few companies will ever build the full suite internally. A chat interface demos well to a board. Seven capture instruments and a staleness audit do not. The work sits closer to reliability engineering than to innovation, and it never reaches a point where anyone announces it's done.
Where the gap shows up
Everything so far is protective — don't get locked in, don't lose what you know. Here's the offensive case.
Answer quality behaves more like a rate than a level. A correction an expert makes this week is in every answer next week, in the portal and in the reps' hands. Eighteen months of that is not eighteen months of effort somebody else could catch up on with a budget, because what accumulates is judgement that has already been tested against real questions, along with a record of where the market kept asking and nothing good came back.
The place it becomes visible is response time on technical enquiries, which in specialty chemicals is close to the whole game. The first credible answer usually gets the sample request, and the specification tends to follow from there. A rep in a market with no local formulator can give the answer your best formulator would give, at the hour the customer asked rather than three days later when the technical service queue clears.
Your competitor across the street sells similar products and employs similar people. If they started capturing eighteen months before you did, the first place you'll notice is win rates on new specifications, and you won't be able to attribute it to anything.
Buying the instruments is not surrendering the ownership
Which brings me to something I had wrong a few years ago.
You do not have to build the instruments to own what they produce. The two are separable, and keeping them separate is the whole trick.
Buy the toolset. Own the output. The test of whether that's real is simple and you should apply it ruthlessly: if you decided to leave your vendor today, could you take everything your experts have captured with you, in a format another system can read? If yes, the instruments are like scaffolding you've hired — the building is still yours. If not, you've bought a dependency wearing the costume of a capability.
For us that means every knowledge point your experts capture is exportable now, not on a roadmap. It means bidirectional sync with your systems of record, so the flow isn't one-way into us. And should you ever want to build your own interface — your portal, your CRM, your internal assistant — the chemical intelligence layer is available as an API, so the knowledge your experts built keeps working wherever you point it.
None of that is generosity. It's the only structure under which a conservative European manufacturer should be willing to work with a company like ours, and we'd rather compete on whether the instruments are good than on whether you can get out.
What isn't worth building
I want to be careful here, because "don't build" is self-serving when a vendor says it.
You can build some of the interface if you want to. Interfaces are much cheaper to build now, your team will enjoy it, and you can build on an API like ours. That's a reasonable place to spend internal engineering.
The thing I'd think hardest about is building an assistant that has to stay accurate at scale, across tens of thousands of documents, dozens of ranges, multiple regions and decades of legacy naming.
In a bounded pilot everything looks fine. Divergence shows up on expansion, and it shows up in ways that are hard to see and harder to fix. Ten thousand documents go in, three hundred inform a given answer, the answer is wrong — which document? Retrieval systems are poor at telling you, and the difficulty grows with the corpus. Compare that with opening a single product characteristic and seeing which document it came from, and whether the value was stated there or inferred.
And I'd caution against taking accuracy-at-scale claims on faith from anyone, us included. Ask for evidence rather than assertion, and hold your vendors to it.
Then there's the part nobody budgets: agents need re-prompting as workflows change, data goes stale, connectors break, and every new surface is another thing to keep alive. The sharpest version of this I've heard came from a digital lead putting it to his own management: "Do we want to live with an AI application that we tried to build, that is consistently nine to twelve months behind the market?"
There are still legitimate reasons to build. Some data cannot leave a controlled environment. Some organisations have the engineering depth and would rather carry the cost than the dependency. Those are real decisions and I'd rather someone make them clear-eyed than be talked out of them. None of them changes what you should be accumulating underneath.
The inheritance test
Here's the test I'd apply to any AI decision in this industry.
When a better model arrives — and it will, inside the year — can it inherit what your company has learned? Your product truth, your specialists' corrections, your edge cases, your sense of what a good answer looks like. Can it become useful without your organisation starting over?
In practice, ask any vendor four questions:
Can we export everything our experts have captured?
Does it sync both ways with our systems of record, or only inward?
Can we consume this as an API and build our own interfaces on top?
Will it continue to capture and retain critical institutional knowledge as years pass?
Four yeses and your ownership is real, whoever runs the interface this year. Four no’s and you don't own your intelligence — you own an implementation with a shelf life.
That's the distinction worth being conservative about. Be relaxed about which chat window your team uses; that market will churn, and lock-in there costs you a quarter, not a decade. Be immovable about who controls the knowledge underneath it, and about whether it stays yours as the years pass.
The model vendors will keep competing to make general intelligence cheaper and more capable. That's their problem, and they're solving it quickly.
Your job is to make sure that when they do, the intelligence understands your world.
Own your intelligence. Buy the instruments. Let the models compete.
