En el post anterior escribí sobre una conversación en Cartagena, y el razonamiento detrás de decisiones que nadie escribe.
Empecemos por lo obvio. Si una empresa tiene varios sistemas que nunca fueron diseñados para conectarse, los conectas.
Eso ya no es difícil, y casi ni es una habilidad. La mayoría de las cosas tienen una API. Para las que no, pones una capa delgada frente a ellas, y algo como FastAPI hace esa capa tan pequeña que no se convierte en proyecto. Hay librerías que exponen esos endpoints directamente a los agentes. Y cuando tu herramienta de flujos no tiene conector para lo que necesitas, n8n y Activepieces te dejan escribir el tuyo. Conectar sistemas es la parte que todos pueden hacer ahora.
Entonces conectar no es la idea. La idea es qué pones en el medio.
Una vez que los reportes, la ocupación y los números de desempeño llegan todos al mismo lugar, algo tiene que decidir qué significan. Esa es la parte que hoy vive en una persona, y de eso trata esta serie.
Las dos formas que podría tomar
Así es como lo imagino funcionando, en dos formas.
En la primera, la cosa vive dentro del flujo. Los sistemas le envían su información, agentes dentro de él hacen el análisis y llegan a una determinación, y las personas que realmente entienden el negocio pueden entrar a ajustar cómo piensan esos agentes. No editando código. Cambiando qué sabe el agente y qué se supone que debe pesar, luego viendo qué sale y corrigiéndolo de nuevo.
En la segunda, no ejecuta nada. Es una fuente. Un agente que vive en otro lugar completamente, en la herramienta de flujos que la empresa ya usa, lee el contexto actual de él antes de decidir. El razonamiento se queda en un lugar. La acción ocurre donde ocurre.
De cualquier forma, alguien necesita poder ver qué se está decidiendo y intervenir, porque nada de esto funciona si la persona se va desconectando del sistema.
Tres tipos de conocimiento
Ahora bien, le estaba describiendo esto a un amigo, y a mitad de la conversación me di cuenta de que ya había construido una versión de eso. No para un hotel. Para mi propio tooling, para que dejara de depender de documentación que se desactualiza.
He escrito antes sobre por qué existen esas herramientas, así que no lo voy a repetir. Lo que no había notado hasta que lo dije en voz alta es que lo que construí se separa en tres tipos de conocimiento, y esa separación es por qué sigue funcionando cuando el mundo cambia.
El ejemplo más claro es un paso que le hago dar a la IA antes de que escriba cualquier cosa, que es ir a buscar trabajo previo. Si alguien ya resolvió esto. Si puedo reutilizarlo, extenderlo, o si realmente necesito algo nuevo.
Esa instrucción nunca cambia. Es verdad en Drupal, es verdad en PHP en general, es verdad en JavaScript, y sería verdad en un lenguaje que nunca he tocado.
Pero dónde buscas cambia completamente. Para PHP estás en paquetes de Composer. Para Drupal estás en drupal.org mirando módulos y recipes. Para JavaScript estás en npm. El mismo razonamiento, terreno distinto. Si horneas el terreno dentro de la instrucción, obtienes una herramienta que solo funciona en un lugar.
Entonces la instrucción vive en un artefacto y el terreno vive en otro. He llamado a ese segundo una process recipe, y eso es todo lo que es, el vínculo entre un proceso general y un entorno específico.
Debajo de ambos están las guías. Los estándares, las técnicas, el cuerpo de conocimiento sobre cómo se hace algo correctamente. Cómo funcionan los estilos de imagen. Cómo configurar una view. Cómo luce un buen CSS. Ese conocimiento es real, es general, y se desactualiza constantemente, que es exactamente por qué no puede vivir dentro de la instrucción.
Y luego está la decisión en sí. No cómo funciona algo, sino qué hacer aquí, dado todo lo que sabes. Esa es la que junta las otras piezas, y es la más difícil de capturar, porque normalmente no está escrita en ningún lado.
Pon el hotel junto a eso y encaja.
Las guías son cómo se comportan los edificios. El desempeño de la envolvente, qué hace el calor y la humedad, cómo responde una fachada según su orientación. La decisión es cuándo hacer mantenimiento a algo, lo cual tira de las guías, los reportes, la temporada y este edificio específico. Y la process recipe es que una propiedad en Cartagena y una en Bogotá no tienen los mismos sistemas ni están en el mismo clima. El mismo razonamiento, terreno distinto. Composer y npm otra vez.
El mapeo se sostuvo. Construí esas capas para escribir software, y para mí mismo, y se trasladan a un calendario de mantenimiento sin doblar.
Pero los tres tipos no son el punto.
El punto es que el sistema que tienes que construir es el que los mantiene vigentes.
Esa es la razón completa por la que mi tooling sigue funcionando. El módulo Drupal AI pasa de 1.3 a 1.4 a 1.5 y mi instrucción no cambia, porque la instrucción nunca contuvo la versión. La guía a la que apunta se actualiza, a mano o mediante un agente que nota que se ha desviado, y la siguiente ejecución toma la nueva. Nada del proceso tuvo que reescribirse.
Hornea los detalles específicos dentro de la instrucción y obtienes algo que funciona perfectamente ahora y está silenciosamente equivocado después, sin que nadie lo note, porque sigue corriendo.
Ese modo de falla está en todas partes ahora mismo. Está en cada prompt que nombra una versión. Está en cada automatización que carga una regla que alguien decidió en una reunión que nadie recuerda. Y estaría en el agente de mantenimiento de un hotel poco tiempo después de que alguien lo configurara.
La parte para la que no tengo respuesta
Una investigación presentada en CHI este año probó eso directamente. Dale a un modelo un perfil guardado de alguien, luego pídele que juzgue una situación en la que esa persona estaba equivocada, y empieza a decirle que no lo estaba. Gemini pasó de estar de acuerdo el 30% del tiempo al 75%. Claude Sonnet se movió 33 puntos, un modelo de GPT 16. Otros dos no se movieron nada.
Fue probado con consejos personales, no con decisiones de ingeniería, así que no estoy diciendo que se transfiera limpiamente. Pero la dirección debería preocupar a cualquiera que proponga alimentar una IA con un relato rico y curado de cómo piensa una empresa.
Podrías construir exactamente lo que estoy describiendo y terminar con una máquina muy cara para confirmar lo que el director de operaciones ya creía.
Mi respuesta a eso es parcial, y viene de correr esto en lugar de probarlo. Las instrucciones le dicen a la IA que no esté de acuerdo conmigo, claramente, en el archivo que lee al inicio de cada sesión. Funciona, y es suficientemente frágil que a veces tengo que recordárselo. Las guías están particionadas en partes pequeñas para que el contexto se mantenga limpio y directo, el agente toma la pieza que importa en lugar de todo lo que he pensado alguna vez. Y el tooling tiene adversarios, agentes separados cuyo trabajo es atacar el trabajo en lugar de terminarlo.
Cuál de esos hace más, no sé. Nunca lo he corrido al revés para averiguarlo.
Entonces ahí es donde estoy. Conectar los sistemas es fácil y todos pueden hacerlo. Lo que va en el medio es la parte de la que no estoy seguro. Creo que se separa en conocimiento, decisiones y el terreno sobre el que corren esas decisiones, y lo que realmente estarías construyendo es lo que mantiene los tres vigentes.
¿Es esto válido? No sé. Necesita trabajo, podría construirse de una docena de formas, y lo estoy publicando para ver si sobrevive el contacto con personas que han intentado algo similar.