Chat en lenguaje natural que navega dentro del ERP

Problema

Llegar a una pantalla concreta en un ERP con años de módulos encima es navegación a ciegas: menús anidados, criterios de búsqueda y un orden que solo domina quien lo usa a diario. "Abre el último pedido de ese cliente" es una frase de tres segundos que, a mano, son varios clics y saber de antemano dónde mirar.

Solución

Son tres piezas, separadas a propósito. Un add-on en C# dentro del ERP que expone un bridge HTTP local y entiende únicamente un repertorio cerrado de órdenes verificables. Un servidor intermedio que publica esas órdenes como herramientas MCP. Y un agente conversacional que vive fuera de SAP, interpreta lo que el usuario escribe y decide qué orden emitir.

El reparto no es casual. La parte que decide es la que puede equivocarse, así que la parte que ejecuta es deliberadamente tonta: no interpreta nada. Si le llega una orden que no está en el repertorio, la rechaza en lugar de aproximarla.

Eso también acota el daño posible. El agente no habla con la base de datos ni con el SDK. Solo puede pedir cosas que el add-on ya sabe hacer y que se revisaron una por una.

Arquitectura

Por qué está montado así

El lenguaje natural se queda fuera del ERP. Hacia dentro solo viajan órdenes cerradas, y esa frontera es lo único que hace el montaje defendible.

El repertorio de órdenes es finito. Lo que no está definido se rechaza; nunca se aproxima a la orden más parecida.

El bridge escucha solo en local. No hay puerto abierto en red ni ERP expuesto a nada que venga de fuera de la máquina.

Usé LangGraph para el agente porque el flujo de decisión queda como un grafo que se lee y se depura. Encadenar prompts funciona hasta que falla, y entonces no sabes dónde.

Streamlit es solo la interfaz. El chat es presentación y no debía condicionar el diseño de las otras dos piezas.

Resultado

Una petición escrita en lenguaje natural abre la pantalla que corresponde dentro de SAP Business One, y el ERP solo llega a ejecutar órdenes de un repertorio cerrado.