Andreessen Horowitz published a great piece last week worth reading if you build or invest in enterprise software. The argument is this: the CRM is not going away, but it is turning into infrastructure. The layer people will actually use -the one that reads the CRM, pulls from a dozen other sources, does the thinking, and tells you what to do- that is where the value is moving. They called it the system of intelligence.
That label landed for me in a way few things do. I have spent months trying explaining what we are building and why it is not a CRM or ERP feature, not just an agent platform, not a workflow tool. System of intelligence is the first frame that puts it in the right bucket. The piece describes a general pattern. What I want to add is what that pattern looks like in a specific domain where the stakes are different.
The article describes a generic GTM motion. Sales reps, pipeline reviews, 10-K briefings before meetings. That world is real and the shift is happening there. What the piece does not describe is what a system of intelligence looks like in a domain where the knowledge problem is not about account context or pipeline hygiene. Where it is about whether you know what you are selling well enough to not put the wrong part on a machine.
The knowledge problem generic AI cannot solve
I have spent years in industrial distribution. The thing that breaks every AI implementation in this space is not the model. It is not the agent framework. It is the knowledge.
A Siemens SINAMICS G120 drive has dozens of control unit variants alone, each with different fieldbus protocols and safety function levels, before you touch power rating or protection class. Turck offers more than 5,000 proximity sensor part numbers in a single product category. Festo's full catalog runs to over 33,000 SKUs. Most automation distributors carry dozens of brands. Two part numbers that differ by one character can be completely incompatible for a specific application. Cross-references between brands are not symmetric and rarely documented in one place. Firmware revisions matter. Accessories are not optional, and nobody tells you which ones until the project is already late. This is not exotic product knowledge. Navigating this mess is the daily work for any inside sales rep or applications engineer at an automation distributor.
No CRM or ERP holds this. No system of record built for GTM workflows was ever designed to. The data model for a contact record and the data model for a product compatibility graph are not the same thing.
Why the generic approaches fail
The a16z piece talks about agents that listen to calls and write notes back into the CRM. That is real and it matters, for horizontal GTM. But the agent that tells an inside sales rep whether a specific drive is compatible with a specific motor, or which cables to add to a BOM that is about to go out wrong, or what the right replacement is for a part that is two weeks from end of life; that agent needs something the CRM has never contained and no horizontal system of intelligence will ever have.
It needs a knowledge layer that actually knows the product.
A general LLM does not have it. Training data does not capture the relational structure of a manufacturer's catalog: the compatibility rules, the configuration constraints, the replacement chains that depend on firmware revisions and installation environment. A RAG implementation on flat datasheets gets you partway and then falls apart when the query requires reasoning across multiple constraints simultaneously. A Copilot connected to your Microsoft 365 knows your emails. It does not know your product families.
None of these are systems of intelligence for this domain. They are generic reasoning engines pointed at the wrong substrate.
What a system of intelligence actually looks like here
Industrial distribution is configure-or-engineer-to-order commerce. Every transaction involves a decision chain: what product, which variant, which configuration, which accessories, which alternatives if the first choice is unavailable. That chain has to be traversed correctly every time. Not 80% of the time. Every time.
What this domain requires is a knowledge grounding layer: a graph-based structure that encodes product families, compatibility rules, configuration logic, replacement chains, and the cross-references that experienced reps carry in their heads; in a form that an AI agent can traverse reliably. Not retrieve from a flat document. Traverse. The difference is the difference between pulling the closest text chunk and knowing that this specific drive variant requires this specific filter, which is only compatible with these cable families, and that the version currently in stock ships with a connector that requires an adapter the customer has not ordered.
That knowledge layer, paired with a purpose-built tool harness that gives the agent stable access to it at query time, is the system of intelligence for this specific domain. The harness is not a detail. It is what separates a capable AI from a reliable one. The quality of what an agent can do is bounded entirely by the quality of the tools it has access to. Build the harness wrong and the agent hallucinates under pressure. Build it right and the agent answers at the level of your best applications engineer, every time, at any volume.
The build-time vs. query-time distinction
There is an architectural point worth making explicitly because it gets missed in most AI discussions.
Generic AI approaches try to solve the knowledge problem at query time. The user asks a question, the system scrambles to find relevant information, retrieves the closest matches, and the model generates a response from whatever it found. That works reasonably well for general knowledge. It fails for industrial product knowledge because the retrieval step destroys the relational structure: the compatibility rules, the configuration constraints, the hierarchical product taxonomy that makes the information meaningful in the first place.
The right architecture solves the knowledge problem at build time. The knowledge layer is pre-constructed, refreshed as needed, validated against real manufacturer data and real domain expertise, and exposed to the agent through a stable harness. When a query arrives, the agent is not retrieving and hoping. It is traversing a verified structure with purpose-built tools, including live data like inventory or pricing when the application requires it. The accuracy difference is not marginal. It is the difference between 80% and 99.9%, and in this industry only one of those numbers is a business.
This is what ReshapeX builds
We are not a productivity tool. Not a workflow automation layer. Not an AI wrapper on top of your ERP or CRM.
We are the system of intelligence for configure-or-engineer-to-order industrial commerce. The knowledge grounding layer for distribution operations where the product catalog is complex, the decisions are consequential, and the cost of a wrong answer is measured not in bad user experiences but in wrong parts, stopped production lines, and broken customer trust.
The a16z piece ends with a prediction I agree with completely: the next decade of enterprise software value will be written at the intelligence layer, not the record layer. What I would like to add is that in industrial distribution, the intelligence layer has a very specific shape. It looks nothing like a sales AI. It looks like a system that knows every SKU, every compatibility rule, every replacement chain across every brand you carry, and that can traverse that knowledge reliably, every time, without making things up.
The a16z piece is right that AI is competing for labor budgets, not software budgets. In industrial distribution the labor budget it competes for belongs to the people who carry product knowledge in their heads. That is the most expensive, most fragile, most irreplaceable asset in the business. We encode it.