Tenemos un agente que se llama Golem y es el único de nuestro sistema al que no dejamos pensar. No lleva IA dentro. Ni una llamada a un modelo. Y es de las piezas de las que más me fío — precisamente por eso. Os cuento qué hace y por qué lo diseñé así, porque creo que es la decisión menos intuitiva y más útil de todo nuestro sistema de agentes.
El contexto mínimo: cada semana, un agente consultor (Belisarius, ya os lo presentaré en detalle) revisa el funnel de captación completo de TramitApp, donde soy CRO, y me entrega como máximo cinco decisiones verificadas. El problema que tuvimos al principio no fue la calidad de las decisiones: fue que se quedaban en el informe. Un informe semanal que nadie convierte en tareas es un PDF muy caro.
Ahí entra Golem. Su trabajo, paso a paso:
Uno: cuando el consultor termina su run, Golem lee el dictamen — un fichero estructurado con las decisiones, su prioridad, su esfuerzo estimado y su evidencia.
Dos: crea una tarea en nuestro backlog por cada decisión. Una fila por decisión, en una sección propia, con identificador trazable al run que la generó. Si la sección no existe, la crea él.
Tres: nunca duplica. Cada tarea lleva una marca de origen (consultor + semana + decisión), y si ya está en el backlog, la salta. Eso significa que puedo relanzar el proceso las veces que quiera sin miedo: mismo input, mismo resultado. También tiene modo de ensayo — te dice qué haría sin tocar nada.
Cuatro: crear la tarea no ejecuta nada. La decisión sigue siendo humana: trabajarla es aprobarla, y descartarla exige decirle el motivo — que va a un fichero de aprendizaje y genera un periodo de enfriamiento para que el consultor no me proponga lo mismo la semana siguiente. El descarte deja huella; esa huella es la que hace que el sistema mejore.
Y un detalle que nos encanta: para escribir en el backlog no inventa su propio camino — reutiliza el mecanismo de registro que ya había construido otro agente (Orión, el del outbound, del que os hablé hace unos días). En nuestro sistema hay un solo camino para registrar tareas, y todos los agentes pasan por él.
¿Por qué Golem no lleva IA? Porque está en el último eslabón: el que toca nuestro backlog. Y en el último eslabón no quiero creatividad, quiero fiabilidad. Un modelo de lenguaje, por bueno que sea, introduce varianza: hoy formatea así, mañana interpreta una prioridad de otra manera, pasado duplica una tarea porque la frase era distinta. La inteligencia ya se gastó antes — en los agentes que investigan, contrastan y verifican cada hallazgo. El que firma en el registro tiene que ser aburrido: veinte líneas de código de toda la vida, deterministas, testeables, re-ejecutables.
Esta es la regla general que nos llevamos a cualquier sistema de agentes: no todos los eslabones merecen IA. Pregúntate cuáles necesitan juicio (investigar, priorizar, redactar) y cuáles necesitan exactitud (registrar, contar, mover dinero, tocar datos de producción). Los primeros son para modelos; los segundos, para código normal. Cuanto más cerca del registro está una pieza, menos IA debería llevar.
Si quieres aplicarlo mañana, tres decisiones: separa el pensar del registrar en piezas distintas, aunque te parezca burocracia; haz al registrador idempotente — marca de origen, dedupe, modo ensayo — para poder relanzar sin miedo; y haz que el descarte humano deje huella con motivo, porque ahí está el aprendizaje del sistema.
La paradoja de Golem es la lección entera: en un sistema lleno de inteligencia artificial, la pieza que lo hace confiable es la que no tiene ninguna.
Este retrato forma parte de la serie Los agentes de la empresa agéntica: los agentes de IA reales que tengo funcionando, contados uno a uno — qué problema tenían, cómo trabajan, qué falló. El próximo: Belisarius, el consultor.
Deja un comentario ¡Tu opinión me interesa!