Andreessen Horowitz publicó la semana pasada un artículo que merece la pena leer si construyes o inviertes en software empresarial. El argumento es este: el CRM no va a desaparecer, pero se está convirtiendo en infraestructura. La capa que la gente usará de verdad — la que lee el CRM, extrae de una docena de fuentes más, hace el razonamiento y te dice qué hacer — es hacia donde se mueve el valor. Lo llamaron sistema de inteligencia.
Esa etiqueta me encajó como pocas cosas. Llevo meses intentando explicar qué estamos construyendo y por qué no es una función de CRM o ERP, no solo una plataforma de agentes, no una herramienta de flujos de trabajo. Sistema de inteligencia es el primer marco que lo sitúa en el cubo correcto. El artículo describe un patrón general. Lo que quiero añadir es cómo se ve ese patrón en un dominio concreto donde las apuestas son distintas.
El artículo describe un movimiento GTM genérico. Vendedores, revisiones de pipeline, informes de 10-K antes de reuniones. Ese mundo es real y el cambio ocurre allí. Lo que el artículo no describe es cómo se ve un sistema de inteligencia en un dominio donde el problema de conocimiento no trata del contexto de cuenta o la higiene del pipeline. Donde trata de si conoces lo que vendes lo bastante bien como para no poner la pieza incorrecta en una máquina.
El problema de conocimiento que la IA genérica no puede resolver
Llevo años en distribución industrial. Lo que rompe cada implementación de IA en este espacio no es el modelo. No es el marco de agentes. Es el conocimiento.
Un variador Siemens SINAMICS G120 tiene docenas de variantes de unidad de control solo, cada una con distintos protocolos fieldbus y niveles de funciones de seguridad, antes de tocar potencia o clase de protección. Turck ofrece más de 5.000 números de pieza de sensores de proximidad en una sola categoría de producto. El catálogo completo de Festo supera las 33.000 SKU. La mayoría de distribuidores de automatización trabajan con docenas de marcas. Dos números de pieza que difieren en un carácter pueden ser completamente incompatibles para una aplicación concreta. Las referencias cruzadas entre marcas no son simétricas y rara vez están documentadas en un solo sitio. Las revisiones de firmware importan. Los accesorios no son opcionales, y nadie te dice cuáles hasta que el proyecto ya va tarde. Esto no es conocimiento de producto exótico. Navegar este caos es el trabajo diario de cualquier vendedor interno o ingeniero de aplicaciones en un distribuidor de automatización.
Ningún CRM ni ERP lo contiene. Ningún sistema de registro diseñado para flujos GTM lo fue. El modelo de datos de un registro de contacto y el modelo de datos de un grafo de compatibilidad de producto no son lo mismo.
Por qué fallan los enfoques genéricos
El artículo de a16z habla de agentes que escuchan llamadas y escriben notas de vuelta en el CRM. Eso es real e importa, para GTM horizontal. Pero el agente que le dice a un vendedor interno si un variador concreto es compatible con un motor concreto, o qué cables añadir a una lista de materiales a punto de salir mal, o cuál es el reemplazo correcto de una pieza a dos semanas del fin de vida; ese agente necesita algo que el CRM nunca ha contenido y que ningún sistema de inteligencia horizontal tendrá.
Necesita una capa de anclaje que conozca de verdad el producto.
Un LLM general no la tiene. Los datos de entrenamiento no capturan la estructura relacional de un catálogo de fabricante: las reglas de compatibilidad, las restricciones de configuración, las cadenas de reemplazo que dependen de revisiones de firmware y entorno de instalación. Una implementación RAG sobre hojas de datos planas te acerca en parte y luego se desmorona cuando la consulta requiere razonar sobre varias restricciones a la vez. Un Copilot conectado a Microsoft 365 conoce tus correos. No conoce tus familias de producto.
Ninguno de estos es un sistema de inteligencia para este dominio. Son motores de razonamiento genéricos apuntando al sustrato equivocado.
Cómo se ve de verdad un sistema de inteligencia aquí
La distribución industrial es comercio configure-to-order o engineer-to-order. Cada transacción implica una cadena de decisiones: qué producto, qué variante, qué configuración, qué accesorios, qué alternativas si la primera opción no está disponible. Esa cadena debe recorrerse correctamente cada vez. No el 80 % de las veces. Cada vez.
Lo que este dominio requiere es una capa de anclaje de conocimiento: una estructura basada en grafos que codifica familias de producto, reglas de compatibilidad, lógica de configuración, cadenas de reemplazo y las referencias cruzadas que los vendedores experimentados llevan en la cabeza; en una forma que un agente de IA pueda recorrer con fiabilidad. No recuperar de un documento plano. Recorrer. La diferencia es la que hay entre sacar el fragmento de texto más cercano y saber que esta variante concreta de variador requiere este filtro concreto, que solo es compatible con estas familias de cable, y que la versión actualmente en stock sale con un conector que requiere un adaptador que el cliente no ha pedido.
Esa capa de conocimiento, emparejada con un arnés de herramientas creado a propósito que da al agente acceso estable a ella en el momento de la consulta, es el sistema de inteligencia para este dominio concreto. El arnés no es un detalle. Es lo que separa una IA capaz de una fiable. La calidad de lo que un agente puede hacer está limitada por completo por la calidad de las herramientas a las que tiene acceso. Construye mal el arnés y el agente alucina bajo presión. Constrúyelo bien y responde al nivel de tu mejor ingeniero de aplicaciones, cada vez, a cualquier volumen.
La distinción entre tiempo de construcción y tiempo de consulta
Hay un punto arquitectónico que conviene dejar explícito porque se pierde en la mayoría de las conversaciones sobre IA.
Los enfoques genéricos de IA intentan resolver el problema de conocimiento en tiempo de consulta. El usuario hace una pregunta, el sistema se apresura a encontrar información relevante, recupera las coincidencias más cercanas y el modelo genera una respuesta a partir de lo que encontró. Eso funciona razonablemente bien para conocimiento general. Falla para conocimiento de producto industrial porque el paso de recuperación destruye la estructura relacional: las reglas de compatibilidad, las restricciones de configuración, la taxonomía jerárquica de producto que da sentido a la información.
La arquitectura correcta resuelve el problema de conocimiento en tiempo de construcción. La capa de anclaje se preconstruye, se actualiza según haga falta, se valida contra datos reales del fabricante y pericia de dominio real, y se expone al agente a través de un arnés estable. Cuando llega una consulta, el agente no recupera y espera. Recorre una estructura verificada con herramientas creadas a propósito, incluidos datos en vivo como inventario o precios cuando la aplicación lo requiere. La diferencia de precisión no es marginal. Es la diferencia entre el 80 % y el 99,9 %, y en esta industria solo uno de esos números es un negocio.
Esto es lo que construye ReshapeX
No somos una herramienta de productividad. No una capa de automatización de flujos de trabajo. No un envoltorio de IA encima de tu ERP o CRM.
Somos el sistema de inteligencia para el comercio industrial configure-to-order o engineer-to-order. La capa de anclaje de conocimiento para operaciones de distribución donde el catálogo de producto es complejo, las decisiones tienen consecuencias y el coste de una respuesta incorrecta se mide no en malas experiencias de usuario sino en piezas incorrectas, líneas de producción paradas y confianza del cliente rota.
El artículo de a16z termina con una predicción con la que estoy completamente de acuerdo: la próxima década de valor en software empresarial se escribirá en la capa de inteligencia, no en la capa de registro. Lo que quiero añadir es que en distribución industrial, la capa de inteligencia tiene una forma muy concreta. No se parece en nada a una IA de ventas. Se parece a un sistema que conoce cada SKU, cada regla de compatibilidad, cada cadena de reemplazo en cada marca que trabajas, y que puede recorrer ese conocimiento con fiabilidad, cada vez, sin inventar.
El artículo de a16z acierta al decir que la IA compite por presupuestos de mano de obra, no de software. En distribución industrial, el presupuesto de mano de obra por el que compite pertenece a las personas que llevan el conocimiento de producto en la cabeza. Es el activo más caro, más frágil e insustituible del negocio. Nosotros lo codificamos.