Lo que construyo cuando construyo PRISM

Las cuestiones que me hago mientras convierto una forma de trabajar con agentes en algo que otros puedan usar: de dónde viene, qué es, dónde vive el criterio, por qué las reglas escritas no bastan y cómo se pasa de lo decible a lo comprobable. Con las respuestas provisionales que hoy sostengo y las lecturas que me han hecho mudar de parecer.

Índice

1. Por qué escribo esto ahora
2. De dónde vengo: la cadena de suministro
3. La torre de control y el plan único
4. Qué estoy construyendo exactamente
5. Dónde vive el criterio
6. Por qué las reglas escritas no bastan
7. De lo decible a lo comprobable: la escalera
8. Cómo se genera conocimiento en un sistema así
9. Qué sabe el agente cuando empieza, y cuánto cuesta que lo sepa
10. Quién responde cuando actúan
11. Cómo visualizo la evolución
12. Fuentes y lecturas

Por qué escribo esto ahora

Llevo meses trabajando con agentes de inteligencia artificial casi a diario. No como quien tantea una herramienta, sino como quien intenta que un equipo que no duerme, que amanece cada día sin memoria y que yerra con un aplomo admirable, saque adelante encomiendas reales: código, propuestas, vídeos, contabilidad. De esa convivencia se decantó PRISM, que empezó siendo un puñado de reglas escritas para mí y hoy es un método con constitución, con secuencias de trabajo tasadas, con puertas de verificación que se ejecutan solas y con una norma de madurez de producto que se puede medir.

Esta semana estoy congelando la primera versión numerada para sentarme con el equipo de MAINDS y empezar a mejorarla entre todos. Y al releer el curso que la explica, he caído en la cuenta de que tengo las ideas bastante menos sedimentadas de lo que el método aparenta. Aviso navegantes: lo que sigue no es doctrina cerrada. Son las preguntas que me hago, lo que hoy respondería, y las lecturas que me han empujado hacia un lado o hacia otro. Empiezo por donde empezó todo, que no fue en la inteligencia artificial sino en una fábrica, y desde ahí subo hasta las preguntas que aún no sé contestar. Si algo de esto le sirve a alguien que ande en la misma travesía, bien. Si alguien me demuestra que voy desencaminado, mejor todavía, porque llegaré antes.

De dónde vengo: la cadena de suministro

Me ha costado admitir cuánto de PRISM viene de mi etapa anterior. Antes de dedicarme a la inteligencia artificial trabajé en estrategia de cadena de suministro en consultoría, y durante años pensé que aquello había quedado atrás, como un oficio que se deja al cambiar de sector. No era así. Casi todo lo que hoy considero mío en el trabajo con agentes lo aprendí entonces, en fábricas, almacenes y salas de reuniones donde nadie hablaba de modelos de lenguaje. Por eso empiezo por aquí: el vocabulario que usaré en el resto del texto, variables, criterio, protocolo, postergación, nació en aquel trabajo.

De una estrategia a un portafolio

Hubo un proyecto que me marcó: el rediseño de la cadena de suministro de un gran fabricante de electrónica de consumo, que no voy a nombrar. Llegamos con una empresa que operaba toda su gama con una única estrategia. La misma cadena, los mismos plazos, el mismo nivel de existencias y la misma manera de planificar servían para el portátil de gama alta que el cliente configuraba a medida y para el periférico barato que se vendía por millones en cualquier gran superficie. Aquello funcionaba a medias, que es la peor manera de funcionar, porque nadie veía la necesidad de cambiarlo y todo el mundo sufría sus consecuencias: sobrantes de lo que no se vendía, roturas de lo que sí, y unos costes de urgencia que se habían vuelto costumbre.

Lo que hicimos fue, primero, entender las variables. Qué mueve de verdad el coste, el plazo y el riesgo de cada familia de producto: la volatilidad de su demanda, el margen que deja, la duración de su ciclo de vida, cuánto está dispuesto a esperar quien lo compra, cuántas variantes admite y en qué punto de la cadena se decide cada una. Con esas variables segmentamos la gama, y con la segmentación diseñamos no una estrategia sino un portafolio: cadenas eficientes para lo estable y de bajo margen, cadenas ágiles y con más holgura para lo volátil y caro, y cadenas de configuración tardía para lo que se personalizaba. Era, sin que yo lo supiera entonces, lo que Marshall Fisher había publicado en Harvard Business Review en 1997 con una claridad que aún me admira: no existe la cadena de suministro correcta, existe la correcta para cada producto, y el error habitual, y caro, es tratar a todos los productos como si fueran uno. Hau Lee lo afinó después añadiendo la incertidumbre del suministro a la de la demanda, y con las dos dimensiones salían cuatro estrategias distintas. Nosotros llegamos a un número parecido por el camino largo.

Posponer la personalización

De aquel trabajo me quedó una primera obsesión: posponer al máximo la personalización. Fabricar lo común cuanto antes y aplazar la variante hasta el último momento en que todavía se puede decidir con información real. El caso clásico de la literatura es el de las impresoras de Hewlett-Packard en los años noventa, que se ensamblaban genéricas en la fábrica y se localizaban, con su fuente de alimentación y su manual en el idioma que tocara, en el almacén regional cuando ya se conocía el pedido. El ahorro no venía de fabricar más barato, sino de decidir más tarde. En nuestro proyecto el principio se aplicó a la configuración de los equipos y cambió la cadena entera: qué se hacía en origen, qué en destino, dónde se guardaban las existencias y en qué forma.

Hoy veo la postergación en tres sitios de PRISM, y en ninguno la puse a propósito. El módulo de contexto, brain, es postergación pura: no cargar al arrancar todo lo que un agente podría necesitar, sino lo común y estable, y dejar lo específico para cuando el encargo lo pida. Los combos adaptativos por complejidad son postergación: la secuencia genérica se fija pronto y los gates que sobran para un encargo trivial se relajan al declarar la complejidad, dejando huella. Y el perfil de Calibre por tipo de producto es la segmentación de Fisher aplicada a la calidad: no exigir a un prototipo interno lo que se exige a un producto con usuarios y datos personales. En los tres casos la regla es la misma que en la fábrica: lo genérico se decide pronto y barato; lo específico, tarde y con información.

Entender las variables antes de diseñar nada

La segunda obsesión es la que precede a todo: entender las variables antes de diseñar. En aquel proyecto pasamos semanas midiendo antes de proponer una sola línea de estrategia, y hubo momentos en que el cliente se impacientaba, porque quería soluciones y nosotros seguíamos preguntando. Pero sin el mapa de variables cualquier estrategia es una corazonada bien presentada. En PRISM esas variables son la ontología y las cuarenta y ocho dimensiones de la norma de calidad: qué tipo de producto es, qué familia de riesgo toca, si hay usuarios humanos, si hay datos personales, si hay decisiones delegadas, qué complejidad declara el encargo. Sin ese mapa no se puede enrutar, solo improvisar, y la improvisación con agentes es cara porque parece barata.

El generador de motores

La tercera obsesión es que la estrategia no se elige a mano cada vez. Cuando se tienen cientos de referencias, decidir producto a producto qué cadena le corresponde es imposible y, además, inconsistente: dos planificadores llegarían a conclusiones distintas para productos iguales. Lo que construimos entonces fue un mecanismo que, dadas las variables de un producto, devolvía la estrategia que le correspondía y, con ella, el juego de reglas operativas: niveles de existencias, puntos de desacople, plazos comprometidos, frecuencia de planificación. Lo llamábamos, con poca poesía, el generador de motores: cada estrategia era un motor, y el generador decidía cuál montar en cada producto y con qué parámetros.

Es exactamente el router de PRISM, que con siete preguntas de sí o no elige la secuencia de trabajo, y es lo que quiero que sea el generador de protocolos: no una máquina de inventar protocolos, sino un mecanismo que, dada la intención compilada y sus variables, devuelve el protocolo que corresponde y, solo cuando de verdad no lo hay, abre el proceso de crear uno con sus frenos. En la fábrica, un producto que no encajaba en ningún motor era una señal de dos cosas posibles: o las variables estaban mal medidas, o había aparecido una familia nueva que merecía motor propio. Casi siempre era lo primero. Con los protocolos ocurre igual, y por eso la primera pregunta ante «necesito un protocolo nuevo» es «¿qué existe ya?».

Protocolos que mejoran con el uso

La cuarta obsesión es la que más pesa, y la que da sentido a las otras tres: todo lo anterior solo vale si se materializa en protocolos que la gente pueda ejecutar sin mí, y que mejoren con el propio uso. En consultoría se aprende pronto que el criterio que vive en la cabeza del consultor se va con el consultor, y que el entregable que se queda en un cajón no cambia nada. Lo que se queda es el protocolo: la hoja de trabajo estándar que el planificador sigue el lunes cuando ya no estamos, con sus parámetros, sus excepciones y su registro de desviaciones. Toyota lo formuló hace décadas con una frase que Masaaki Imai popularizó: sin trabajo estándar no hay mejora, porque no hay respecto a qué mejorar. El estándar no es el techo; es el suelo desde el que se mide cada desviación, y cada desviación investigada produce un estándar mejor.

Ese ciclo es el corazón de PRISM y explica varias piezas que de otro modo parecen burocracia. Las decisiones registradas con motivo, alternativas descartadas y reversibilidad son el registro de desviaciones. Los combos versionados como datos son la hoja de trabajo estándar. Las evals, esas tareas que corren en cada cambio y que incluyen casos diseñados para fallar, son la auditoría que comprueba que el estándar sigue vigente y que la mejora no ha roto lo anterior. La norma de calidad, con sus controles numerados que nunca se reutilizan y que se retiran marcándolos en vez de borrarlos, es el manual de procedimientos que en la fábrica colgaba de la pared, con la ventaja de que aquí un agente lo consulta sin leerlo entero. Y la ficha de cierre enlazada al commit es el parte de producción. Nada de eso es nuevo; lo nuevo es que se puede ejecutar y comprobar solo.

Lo demás que traje sin darme cuenta

Hay más correspondencias, y las enumero porque me sorprendió encontrarlas todas. La planificación integrada de ventas y operaciones, ese ciclo mensual en que la empresa entera acuerda un único plan, es el ritmo de fases con apertura, ejecución, comprobación y cierre. La gestión por excepción, en la que las personas solo intervienen cuando algo se sale del corredor previsto, es la puerta humana que PRISM reserva para lo irreversible, lo que cuesta dinero y lo ambiguo, dejando lo demás en manos de la secuencia. La medición de la precisión de las previsiones frente a lo que de verdad ocurrió es la calibración de los tiempos: en doscientas veintiséis fases medidas, los agentes tardaron de mediana algo menos de un cuarto de lo que habían previsto, y sin esa medida seguiríamos planificando con estimaciones infladas. El efecto látigo, esa amplificación de una pequeña variación de demanda a medida que sube por la cadena, es lo que le pasa a una regla añadida en las instrucciones globales cuando la heredan todos los subagentes. Y la torre de control, el sistema que ve toda la red y avisa de las desviaciones, es la plataforma que estamos construyendo ahora, con la lección que en logística también costó aprender: la torre se levanta después de tener sensores fiables, nunca antes, y las cuatro plataformas que se nos marchitaron murieron por construir la pantalla antes que el sensor.

También hay cosas que no se traducen, y conviene decirlas para no forzar la analogía. En una cadena física la restricción es el coste de producir y de tener existencias; con agentes, producir cuesta casi nada, y la restricción se desplaza a la verificación y a la atención de las personas que revisan. En la fábrica se puede tocar el producto; aquí el producto es texto y código, y la única manera de tocarlo es la prueba. Y en la fábrica los operarios recuerdan; aquí cada turno empieza sin memoria, y eso obliga a que el protocolo lleve dentro lo que en la fábrica llevaba el oficio de la gente.

La obsesión, dicha de una vez

Esa es, bien mirado, la obsesión que atraviesa todo lo que viene a continuación, empezando por las dos ideas de aquella etapa que aún me faltan por contar: desarrollar criterio y materializarlo en protocolos reutilizables que el uso mejore. La cadena de suministro me enseñó que la calidad de una operación no está en la máquina más nueva ni en el operario más brillante, sino en el diseño de las reglas que hacen que cualquier máquina y cualquier operario rindan igual y que cada fallo deje una regla mejor. Con los agentes ocurre lo mismo, con una ventaja que entonces no teníamos: aquí el protocolo se ejecuta y se comprueba solo. Lo que en la fábrica era un manual, una auditoría y un planificador con criterio, aquí es un fichero de datos, un hook y una prueba en disco. Y el planificador con criterio, el que decide qué motor va en cada producto, sigue siendo una persona. Ese es el sitio que reservo para mí y para el equipo, y creo que es el único que no se va a comoditizar.

La torre de control y el plan único

Hay dos ideas más de aquella etapa que me acompañan, y que explican tanto lo que he acertado con PRISM como lo que he estropeado por el camino. La primera es la torre de control. La segunda, la planificación integrada del negocio, que en la jerga se llama S&OP o IBP según lo ambiciosa que sea. Las cuento por separado porque en la práctica se confunden, y confundirlas me costó cuatro plataformas muertas.

Qué era una torre de control cuando yo la vendía

En 2017 asistí a una presentación interna, en la gran consultora donde trabajaba, sobre lo que entonces llamábamos torre de control de la cadena de suministro. La transcribí en su día y la he releído para escribir esto. La idea partía de un diagnóstico que hoy podría firmar cualquiera que opere agentes: las cadenas se habían vuelto exponencialmente complejas, con más productos, más canales, más proveedores y más datos de los que nadie podía mirar; y los síntomas eran siempre los mismos, apagar fuegos gobernaba la agenda, cada vez más decisiones se tomaban fuera del sistema, nadie veía la red extendida de proveedores y clientes, y los planes cambiaban sin cesar.

La torre de control era la respuesta: una plataforma por encima del sistema de registro, que en una empresa es el ERP, con tres funciones que me aprendí de memoria. Sentir, es decir, captar señales de dentro de la empresa, de la red de proveedores y clientes, y del ecosistema, desde el tiempo meteorológico hasta la geopolítica. Traducir, o sea, cuantificar el impacto de cada señal sobre el servicio, el coste y el riesgo. Y resolver y ejecutar, eligiendo entre protocolos de respuesta ya escritos para minimizar el impacto y lanzando las instrucciones que realineaban la cadena. Con un cuarto paso que cerraba el ciclo: aprender y mejorar, midiendo el resultado de cada respuesta y refrescando los algoritmos. Lo que más me marcó de aquella presentación no fue la tecnología sino una casilla pequeña de una de las diapositivas: un repositorio de señales, alertas y protocolos de solución. La torre no improvisaba respuestas; las tenía escritas, con su señal disparadora, y el trabajo de fondo consistía en engrosar y afinar ese repositorio con cada excepción resuelta.

También me quedé con su modelo operativo. Una torre inteligente orquestaba las decisiones de extremo a extremo, por ejemplo mover existencias de un almacén a otro, y torres funcionales, la de transporte, la de planificación, tomaban las decisiones operativas de su ámbito alineadas con la de arriba. Un solo dueño por capa, dicho de otro modo. Y con un itinerario de madurez que iba de la visibilidad, cuadros de mando y trazabilidad, a la gestión de excepciones y la planificación concurrente, y de ahí a lo que la presentación llamaba, con cierta grandilocuencia, cadena autónoma y cerebro de la cadena de suministro. Se insistía en algo que entonces sonaba a prudencia comercial y que hoy entiendo como una ley: la torre no es un proyecto aislado sino un viaje, y es el primer paso hacia la autonomía, no la autonomía misma.

Lo que hice mal por recordarlo a medias

Cuando en 2026 escribí el brief del paper de PRISM, la torre de control fue la primera analogía que usé: la herramienta que orquesta la cadena de desarrollo con agentes, con sus niveles de decisión y su gestión por excepción. Estaba bien visto y mal ejecutado. Construimos la torre antes que los sensores. Cuatro veces intentamos levantar la plataforma que enseñara el trabajo de los agentes, y las cuatro se marchitaron en semanas: la primera registró cientos de ciclos en un mes y ninguno después, porque los ciclos se marcaban como éxito sin que nadie lo comprobara; la más seria técnicamente no la llamaba ningún comando del día a día; las otras dos se quedaron en diseño. La presentación de 2017 ya lo advertía en su itinerario: primero visibilidad sobre datos fiables, luego excepciones, y solo después autonomía. Yo había leído el final del itinerario y me había saltado el principio.

Por eso la plataforma de PRISM empieza ahora por lo que la torre llamaba sentir: un registro automático de cada petición y cada ejecución, con el modelo real que se usó, emitido por los propios mecanismos y no por el autoinforme del agente. Los hooks son los sensores. Las puertas son la traducción, porque convierten una señal en un rojo o un verde con su impacto declarado. Los protocolos de PRISM son, con toda exactitud, aquel repositorio de señales, alertas y soluciones: cada protocolo tiene su cuándo aplica, su método, su criterio de completado y sus antipatrones, y el generador de protocolos que quiero construir es el mecanismo que engrosa el repositorio con cada excepción resuelta. La ficha de decisión es el aprender y mejorar. Y el módulo de contexto, brain, es lo que la presentación llamaba cerebro de la cadena, sin que yo lo supiera cuando le puse el nombre.

El plan único: S&OP e IBP

La segunda idea es más antigua y más sobria. La planificación de ventas y operaciones nació a finales de los años ochenta, cuando Richard Ling y Walter Goddard describieron un ciclo mensual en el que la empresa entera acordaba un único plan: revisión de producto, revisión de demanda, revisión de suministro, reconciliación de las diferencias y revisión ejecutiva. Oliver Wight lo amplió después a lo que llamó planificación integrada del negocio, IBP, que añadía la dimensión financiera y elevaba el ciclo a la dirección general. La regla central era casi moral: un solo plan, un solo juego de cifras, y todo el mundo trabaja contra él. Su complemento, la planificación de ventas y ejecución, S&OE, bajaba el mismo ciclo a la semana para gestionar las desviaciones sin tocar el plan mensual.

Lo que hacía funcionar aquello no era la reunión sino tres disciplinas. La primera, la gestión por excepción: los directivos no revisan el plan entero, revisan lo que se ha salido del corredor acordado, y todo lo demás se ejecuta sin ellos. La segunda, la medición de la precisión de la previsión contra lo que de verdad ocurrió, con su métrica, el error porcentual medio, y la obligación de mejorar la previsión, no de justificarla. La tercera, la reconciliación: cuando demanda y suministro no cuadran, alguien con autoridad decide, y la decisión queda registrada con sus alternativas.

En PRISM las tres viven con otros nombres, y esta vez creo que las puse a propósito. Las fases de una secuencia de trabajo, abrir, ejecutar, comprobar y cerrar, son el ciclo; la intención compilada es el plan único contra el que se trabaja, porque fija qué se quiere y con qué prueba se cerrará; el comprobador de mitad de fase es la reconciliación; y la puerta humana reservada a lo irreversible, a lo que cuesta dinero y a lo ambiguo es la gestión por excepción, que deja todo lo demás en manos de la secuencia. La precisión de la previsión es la pieza que más me gusta haber medido: en doscientas veintiséis fases, los agentes tardaron de mediana algo menos de un cuarto de lo que habían previsto. Sin esa cifra seguiríamos planificando con estimaciones infladas y, lo que es peor, tomando las estimaciones del agente por hechos.

Hay una lección de la planificación integrada que aún no he sabido trasladar y que dejo escrita como deuda: el plan único era de la empresa entera, no de un equipo. Con varios agentes, varios repositorios y varias personas, todavía no tengo el equivalente de aquella reunión mensual en la que producto, ventas, operaciones y finanzas miraban las mismas cifras. La plataforma, cuando exista, tendrá que ser también eso: no solo la caja negra de lo que pasó, sino el sitio donde se reconcilian los planes de todos contra un único juego de hechos.

Qué estoy construyendo exactamente

Durante mucho tiempo respondí a esta pregunta con un inventario de piezas, y un inventario no es una respuesta. Lo que necesitaba era un asidero en algo que ya hubiera ocurrido, para entender hacia dónde va esto sin dejarme aturdir por el ruido del mercado. Las dos analogías que acuden primero son las peores. PRISM no es un Windows, porque un sistema operativo es indiferente a lo que hagas con él, y PRISM tiene criterio sobre si el trabajo está bien hecho; además, en esta época el sistema operativo de verdad ya lo fabrican otros, y se llama modelo más su herramienta de agente. Tampoco es una suite de oficina, porque no es la herramienta con la que produces, sino la forma de trabajar que gobierna cualquier herramienta.

La analogía que me ha ordenado la cabeza es la aviación comercial. Las aerolíneas no fabrican aviones: se los compran a dos o tres constructores que los perfeccionan cada año. Lo que hace segura la aviación es la manera de operarlos, y esa manera tiene, pieza por pieza, lo que yo he acabado construyendo sin saber que lo estaba calcando. La lista de comprobación es la secuencia de trabajo: nadie despega de memoria, por avezado que sea. El «listo o no listo» que precede a cada fase es la puerta de verificación: el avión no despega con un punto en rojo, y el rojo se declara siempre. El briefing previo al vuelo es cuanto el agente sabe antes de tocar un mando, y una tripulación nueva en cada vuelo es, con exactitud, el problema del agente que amanece sin memoria. La caja negra es el registro de lo ocurrido, ajeno a lo que el piloto cuente. Y la investigación de accidentes es la ficha de decisión: cada regla de la aviación nació de un fallo investigado, igual que cada línea de mi constitución nació de una corrección que tuve que reiterar.

Para los técnicos tengo otra que me gusta igual: PRISM es una distribución de Linux con manual de política. Debian nunca escribió el núcleo; su valor fue el manual de política, el oficio de los mantenedores y las congelaciones de versión. Cuando el núcleo cambia, la distribución perdura. Los modelos son el núcleo y evolucionan sin mí; PRISM es la política, el empaquetado y el rito de publicación. Que esta semana esté «congelando la versión 0.1.0» no es una figura retórica: es, al pie de la letra, lo que hace una distribución antes de publicar.

Si tuviera que cifrarlo en una frase, PRISM es una forma de trabajar con agentes que se hace cumplir sola, funcione con el motor que funcione. Una forma de trabajar, a secas, es un documento que nadie sigue; el adjetivo es lo que muda la naturaleza de la cosa.

Dónde vive el criterio

Esta es la pregunta que más vueltas me ha dado, porque de ella pende el negocio. Si el criterio reside en el modelo, cada versión nueva de Anthropic, de OpenAI o de xAI se come mi trabajo y lo que construyo nace con fecha de caducidad. Si reside en el harness, el andamiaje de código que envuelve al modelo, padezco el mismo problema en diferido, porque los propios laboratorios están absorbiendo esa capa. Y si reside en la organización que opera todo eso, entonces lo que construyo es otra cosa.

Quise cotejarlo con lo publicado y no únicamente con mi experiencia. Reuní los corpus que tengo sobre el asunto y les formulé a todos la misma pregunta. Lo primero que aflora es el giro determinista: Anthropic lo enunció a finales de 2024 en «Building effective agents», y desde entonces casi todo el mundo ha convergido en que los sistemas fiables son flujos de topología fija donde el modelo solo decide dentro de cada nodo. El barrido que hicimos en Atlas, nuestra herramienta de inteligencia de mercado del campo agéntico, lo condensa en una tesis que suscribo palabra por palabra: el valor no está en el agente sino en el sustrato determinista que lo rodea; quien compra agentes compra demostraciones, quien construye el andamiaje compra fiabilidad. El equipo de Manus lo dice con una imagen que prefiero: la capacidad del modelo es la marea que sube, y el harness es el barco.

Lo segundo es la verificación como palanca principal. Boris Cherny, que lleva Claude Code dentro de Anthropic, lo afirma sin paliativos: darle al agente una manera de verificar su propio trabajo duplica o triplica la calidad. Y la academia ya ha bautizado la disciplina, «harness engineering», con un dato que me parece el más contundente de cuanto he leído. En el estudio de Tianbao Zhang sobre el harness como activo (el marco CAAF, 2026), un modelo de frontera con razonamiento extendido y sin andamiaje falló en veinte de veinte pruebas bajo ruido contextual, mientras que modelos modestos dentro de un harness con aserciones deterministas alcanzaron la fiabilidad plena a un coste más de cien veces menor. Y a la inversa: al cambiar el modelo conservando el harness, los contratos se mantuvieron indemnes. El criterio no estaba en el modelo.

Aquí es donde me interesa el contraste con el libro de O’Reilly sobre agentes, el de Kyle Stratis sobre agentes con el protocolo MCP, porque aborda la misma pregunta desde otra ladera. Stratis piensa como ingeniero de integración: el protocolo resuelve que cualquier modelo converse con cualquier herramienta, y el harness es la fontanería que descubre e invoca esas herramientas. Pero cuando llega a la responsabilidad no la deposita en el protocolo ni en el modelo: la deposita en la aplicación anfitriona y en la persona que decide qué servidores conecta y qué llamadas aprueba, y advierte de que los límites que el protocolo declara no los hace cumplir el protocolo, sino quien lo opera. Me parece una lección de humildad de ingeniería: la capa de interoperabilidad, por bien concebida que esté, carece de criterio. Ken Kousen, en otro libro de O’Reilly sobre Claude Code, lo remata con una frase que merecería la portada de cualquier curso: los ficheros de instrucciones aportan contexto, pero no son mecanismos de imposición; la imposición de verdad habita en los permisos, en el aislamiento y en los hooks.

Hay, sin embargo, una tensión que me obliga a ser honesto, y que en Atlas llamamos descomplejización: cada componente del andamiaje codifica una suposición sobre lo que el modelo no sabe hacer solo, y cada versión nueva del modelo deja obsoleta alguna de esas suposiciones. Anthropic ha llegado a podar más del ochenta por ciento de las instrucciones de sistema de su propia herramienta al llegar la generación actual de modelos, con el argumento de que constreñir de más a un modelo capaz lo empeora. Si construyo andamiaje, construyo algo llamado a desaparecer.

Mi respuesta provisional es que el criterio no vive en ninguno de los tres sitios por separado, sino en la relación entre ellos, y que lo que perdura no es el andamiaje sino la prueba. Me explico. Lo que no se vuelve mercancía es qué exijo antes de dar algo por hecho, cómo lo compruebo y qué prueba dejo en disco. Eso lo puede ejecutar un modelo mejor con menos andamiaje, pero no lo puede suplantar, porque es una decisión sobre qué significa «bien» en mi casa. Es la economía de las plantillas de Notion llevada a su extremo: la herramienta la regala el fabricante, el sistema de criterio lo vendes tú. Con una diferencia que sí es nuestra: el criterio de PRISM es verificable, porque cada regla lleva su comprobación automática y su prueba que sabe fallar. Una plantilla no puede demostrar que funciona.

Por qué las reglas escritas no bastan

Siete veces la misma regla

Esto lo aprendí a fuerza de repetirme. La regla «el bridge nunca se detiene a preguntar mientras hay trabajo» la escribí en prosa siete veces, cada vez más nítida, cada vez más enfática, y siete veces el agente la desatendió en cuanto la situación se pareció a otra cosa. Solo dejó de ocurrir cuando la regla dejó de ser texto y pasó a ser mecanismo: un hook que intercepta el intento de parar y devuelve al agente a la tarea. El consenso de 2026 lo resume en una frase que me habría ahorrado meses: las reglas en prosa son sugerencias probabilísticas; los hooks son infraestructura. Joongho Ahn y sus coautores lo demostraron con cifras en «From prompts to contracts»: cuando las reglas de negocio viven solo en el prompt, las violaciones llegan al usuario; solo las garantías escritas en código las atajan sin sacrificar utilidad.

Hay un filósofo al que vuelvo cada vez que discuto con un agente sobre si algo está «hecho», y es Wittgenstein. Lo leí por primera vez en una época en que no tenía nada que ver con máquinas, y me pareció un hombre obsesionado con una pregunta que entonces me sonaba lejana: qué relación hay entre lo que decimos y lo que hay. Hoy esa pregunta es mi trabajo diario, porque convivo con un interlocutor que dice muchísimo, con una fluidez que impresiona, y del que no siempre puedo saber qué hay detrás de lo que dice.

El joven y el maduro

Conviene distinguir dos Wittgenstein, porque el segundo corrigió al primero y las dos correcciones me sirven. El joven, el del Tractatus, sostenía que una proposición es una figura de un estado de cosas, que todo cuanto puede decirse puede decirse con claridad, y que de lo que no se puede hablar hay que callar. Era un programa de higiene del lenguaje: separar lo que significa algo porque describe un hecho comprobable de lo que solo lo aparenta. El maduro, el de las Investigaciones filosóficas, se apartó de esa pureza y dijo algo más incómodo y más útil: el significado de una palabra es su uso dentro de un juego de lenguaje, es decir, dentro de una práctica compartida con reglas que los participantes conocen aunque nadie las haya escrito. Y añadió dos ideas que explican, mejor que mi anécdota, por qué las reglas escritas no bastan.

La primera es la del escarabajo en la caja. Imaginemos que cada cual tiene una caja con algo dentro que solo él puede ver, y que todos llamamos «escarabajo» a lo que hay en nuestra caja. La palabra funciona en la conversación, todos la usamos, y sin embargo nada garantiza que las cajas contengan lo mismo, ni que contengan algo. Cuando un agente me dice «hecho», me está enseñando su caja. Lo dice con la misma seguridad cuando ha ejecutado las pruebas que cuando solo ha escrito el código, o cuando ha escrito un resumen de lo que habría hecho. La palabra es idéntica; el contenido de la caja, no. Lo que hace una puerta de verificación es negarse a aceptar la palabra y exigir que el escarabajo se pueda ver desde fuera: el fichero en disco, la salida del comando, el hash del commit, la captura de pantalla. Eso es un criterio público, y sin criterio público «hecho» no significa nada.

La segunda es la paradoja de seguir una regla, que está en el parágrafo 201 y que resume el fracaso de mis siete intentos. Dice Wittgenstein que ninguna conducta puede quedar determinada por una regla, porque toda conducta puede hacerse concordar con la regla mediante alguna interpretación. Es exactamente lo que hacía el agente: leía «el bridge nunca se para a preguntar mientras hay trabajo» y encontraba, cada vez, una lectura según la cual aquella situación concreta no era «trabajo» o aquella pregunta no era «pararse». No era mala fe. Era la paradoja en acción: una regla escrita admite tantas interpretaciones como situaciones nuevas aparezcan, y un modelo de lenguaje es una máquina de encontrar interpretaciones plausibles. La salida que da Wittgenstein es que seguir una regla es una práctica, una costumbre, algo que se hace y no algo que se interpreta. Traducido a mi oficio: la regla deja de ser un texto que se interpreta y se convierte en un mecanismo que se ejecuta. El hook no se interpreta; se dispara.

El prompt es guía, el entorno es ley

De ahí sale el principio que hoy encabeza PRISM: el prompt es guía, el entorno es ley y la prueba en disco es el cierre. Una regla que solo existe como texto no es una regla, es una esperanza. Y de ahí se sigue también un corolario que me costó admitir: si una regla se puede comprobar con código, tiene que existir además como comprobación; si no se puede, conviene preguntarse si de verdad es una regla o es un anhelo.

Popper, Kahneman y Cynefin

Aquí es donde la epistemología deja de ser un lujo. Popper sostenía que una teoría que no puede ser refutada no es ciencia, y yo he acabado aplicándolo a las salvaguardas: una batería de pruebas que jamás se pone en rojo no es una salvaguarda, es un certificado espurio. Por eso en PRISM cada puerta de verificación cuenta, entre sus pruebas, con una tarea concebida para fallar, y si no falla, la puerta está rota. La literatura reciente del harness camina en la misma dirección cuando rehúsa que el modelo califique su propia tarea: la revisión entre modelos engendra falsos consensos que encubren las violaciones, y por eso se reclaman aserciones en código, registros de procedencia del razonamiento y pruebas cerradas con hipótesis falsables. Kahneman me sirve para lo otro: el agente posee un sistema uno formidable, veloz, seguro de sí, y ninguna reticencia a proclamar «hecho» sin haber mirado. Lo que hace una puerta es obligarle a transitar por el sistema dos, con la prueba delante. Y el marco Cynefin de Snowden me ayuda a no exagerar: los protocolos rígidos sirven para lo complicado, donde hay una respuesta correcta que se puede comprobar; para lo complejo, donde la respuesta emerge, lo que procede es explorar con varias cabezas y registrar, no fijar una secuencia. La conflación de ambos dominios es el error más caro que he cometido, y lo cometí levantando una torre de control antes de tener un registro fiable.

El debate abierto

No quiero soslayar que aquí hay un debate abierto y que yo estoy en un lado. Geoffrey Huntley, creador de la técnica del bucle autónomo, y quienes presumen de cien mil líneas en dos semanas abogan por reducir al mínimo la intervención humana y dejar al agente iterar durante horas. El propio Huntley traza el límite que a mí me parece el justo: nunca para arquitectura, para código crítico de seguridad ni para requisitos ambiguos. En la otra orilla, el marco CAAF exige que ante dos restricciones irreconciliables el agente se detenga y presente opciones con sus contrapartidas, elevando a la persona a decisora de política en vez de mecánica de código. Yo he acabado en un punto intermedio que se parece más al segundo: autonomía plena dentro de la secuencia, y una puerta humana en todo lo irreversible, en todo lo que cuesta dinero y en toda ambigüedad que la intención compilada no haya dirimido.

De lo decible a lo comprobable: la escalera

Si las reglas escritas no bastan, la pregunta siguiente es qué hacer con el lenguaje, porque un encargo, una especificación y una prueba son las tres cosas hechas de lenguaje. Mi respuesta es una escalera: del registro más libre al más comprobable, sin renunciar a ninguno.

La prosa libre y por qué no hay que renunciar a ella

Sería fácil concluir de todo esto que hay que desterrar la prosa y especificarlo todo en un lenguaje formal. Sería, además, un error, y lo he cometido en pequeño varias veces. Un encargo llega en prosa libre porque la prosa libre es el registro natural de quien piensa y de quien manda: en ella caben el porqué, la duda, la prioridad relativa, el matiz de «esto no lo toques» y el «si ves algo raro, avísame», que ningún esquema recoge sin empobrecerlos. Es, a la vez, lo más rico y lo menos comprobable que existe. Quitarla es perder la intención; dejarla sola es perder la prueba. El error, otra vez, es la conflación: creer que un registro puede sustituir al otro, cuando lo que hay que hacer es encadenarlos.

Por eso una pieza de PRISM se llama intención compilada. Compilar, en su sentido de siempre, es traducir un lenguaje que las personas escriben con comodidad a otro que una máquina puede ejecutar sin ambigüedad, sin que la traducción destruya el original. La intención compilada hace eso con el encargo: toma la prosa y la traduce a cinco campos con criterio público. Qué se pidió literalmente, para que nadie pueda reescribir el encargo a posteriori. Qué se quiere de verdad, en una a tres frases, porque casi nunca coincide del todo con lo que se pidió. Qué huecos habría señalado alguien avezado, al menos dos, o un «ninguno» con su justificación, porque el encargo siempre olvida algo y el momento de descubrirlo es antes de empezar. Si la secuencia de trabajo elegida puede cerrarse con lo que la orden produce, un sí o un no, y cuando es no, qué secuencia la gobierna de verdad. Y qué existe ya que el encargo deba conocer, citado con su ruta o su nombre, porque construir de cero algo que vivía con otro nombre es el despilfarro más común del trabajo con agentes. Ninguno de los cinco campos sustituye a la prosa; los cinco la acompañan y la hacen comprobable. Y el sistema no deja avanzar sin ellos: un campo vacío, con el texto de plantilla o con un «ninguno» sin justificar, bloquea el commit.

Pongo un ejemplo real, o casi. El encargo dice: «monta el informe de ventas del trimestre para el consejo». Compilado: se pidió un informe de ventas trimestral; lo que se quiere es que el consejo decida si se abre una segunda línea de negocio, así que el informe tiene que comparar líneas, no limitarse a sumarlas; los huecos son que no se ha dicho qué fuente de datos manda cuando el CRM y la contabilidad discrepan, y que el consejo lo lee en el móvil, así que una tabla de treinta columnas no sirve; la secuencia elegida, la de un entregable, sí puede cerrarse con lo que produce; y existe ya una plantilla de informe con la marca de la casa y un cuaderno con los datos del trimestre anterior. Todo eso estaba, de alguna manera, en la cabeza de quien pidió el informe. Nada de eso estaba en la frase.

El arnés cognitivo

Hablo mucho de harness y me gusta traducirlo, cuando explico, como arnés: lo que sujeta a quien trabaja en altura, no para impedirle moverse sino para que pueda hacerlo sin caerse. Pero hay un sentido más preciso que quiero defender: el arnés de PRISM es un arnés cognitivo. No compensa la fuerza del modelo, sino su cognición, y compensa exactamente las carencias que Kahneman describió en las personas. El modelo tiene un sistema uno formidable: responde rápido, con aplomo, reconoce patrones, completa lo que falta, y no siente ninguna reticencia a proclamar «hecho» sin haber mirado. Lo que no trae de serie es el sistema dos: el que se detiene, comprueba, cuenta, compara con la prueba y desconfía de la primera respuesta. El arnés cognitivo es ese sistema dos puesto fuera del modelo, hecho de tipos, de pruebas, de puertas y de registros que no dependen de su buena voluntad.

La idea no es nueva. Atul Gawande contó en El manifiesto checklist cómo una lista de comprobación de diecinueve puntos redujo a la mitad las muertes en quirófanos de ocho hospitales, y cómo los cirujanos que más la despreciaban eran los que más se beneficiaban de ella. La lista no sabe operar; sabe lo que la adrenalina y la costumbre hacen olvidar. Los filósofos Andy Clark y David Chalmers lo llamaron mente extendida: el cuaderno del que no recuerda, la calculadora, el mapa, son parte del sistema cognitivo de quien los usa, no meros accesorios. Un agente con arnés es una mente extendida en la que la parte que verifica está fuera de la parte que genera, y esa separación es la clave: la literatura del harness ha comprobado que cuando el que genera se califica a sí mismo, o lo califica otro modelo de su misma familia, aparecen falsos consensos que encubren las violaciones. Por eso en PRISM el verificador nunca es el mismo que el productor: son pruebas que corre una máquina, hooks que disparan sin preguntar, o una segunda cabeza de otro proveedor.

Lo que el software ya sabía: BDD, Gherkin, tipos y pruebas

El mundo del software resolvió este problema hace veinte años por su cuenta, y no me avergüenza decir que he llegado tarde a leerlo. Dan North formuló a mediados de la década de 2000 el desarrollo guiado por comportamiento, el BDD, por una razón que suena wittgensteiniana: los de negocio y los programadores usaban las mismas palabras con significados distintos, y las pruebas que escribían los programadores no las entendía nadie más. Su propuesta fue escribir el criterio de aceptación en una forma que ambos pudieran leer y que además se pudiera ejecutar: dado un estado inicial, cuando ocurre algo, entonces se espera un resultado. Gojko Adzic lo llamó después especificación por ejemplos: la especificación no es un documento abstracto sino un conjunto de ejemplos concretos que, si se cumplen, demuestran que el sistema hace lo que se quería.

Gherkin es la gramática de ese juego de lenguaje, la que usan herramientas como Cucumber: escenarios con un «dado», un «cuando» y un «entonces». Su gracia no está en la sintaxis, que es trivial, sino en que cada escenario es a la vez tres cosas: una conversación entre negocio y técnica, una especificación y una prueba ejecutable. Un ejemplo: dado un pedido pagado hace menos de catorce días, cuando el cliente solicita la devolución, entonces se emite el abono íntegro y se envía la etiqueta de recogida. Un director comercial lo entiende, un programador lo implementa y una máquina lo comprueba cada noche. Es el escarabajo puesto encima de la mesa.

Los tipos hacen lo mismo un peldaño más abajo, en el propio código. Un tipo es una promesa que el compilador comprueba antes de que el programa corra: que esta función devuelve un importe y no un texto, que este pedido no puede existir sin cliente. Hay una máxima de Yaron Minsky que me parece hermana de la constitución de PRISM: hacer que los estados ilegales sean irrepresentables. Si el error no se puede escribir, no hace falta detectarlo. Y las pruebas cierran la escalera. Kent Beck las puso delante del código con el desarrollo guiado por pruebas, y con ello convirtió la frase «esto funciona» en un hecho con testigo: no funciona porque lo diga el programador, funciona porque una prueba que antes fallaba ahora pasa. Nótese el orden: la prueba tiene que haber fallado antes. Una prueba que nunca ha estado en rojo no demuestra nada, y esa es la misma regla que Popper me dio para las salvaguardas y que PRISM aplica a cada puerta.

La escalera

Visto así, PRISM es una escalera de juegos de lenguaje, del más libre al más comprobable, y cada peldaño traduce el de arriba a un lenguaje que se puede verificar sin sustituirlo. Arriba está la prosa del encargo, con toda su riqueza y toda su ambigüedad. Debajo, la intención compilada, que fija lo que se quiere y lo que falta. Debajo, los criterios de aceptación al modo de Gherkin, que dicen cómo sabremos que está hecho. Debajo, los tipos, que hacen que lo incorrecto no se pueda ni escribir. Debajo, las pruebas, que convierten «funciona» en un hecho. Y al final, la puerta, que no deja cerrar sin todo lo anterior y que deja en disco la prueba de que se cumplió. Cada peldaño reduce ambigüedad y gana verificabilidad, y a cambio pierde riqueza; por eso no se puede prescindir de ninguno. Quien se queda arriba tiene intención sin prueba; quien se queda abajo tiene prueba sin intención, que es como se construyen sistemas perfectos que nadie pidió.

Lo que cambia con los agentes es que, por primera vez, el mismo actor puede escribir todos los peldaños: el modelo redacta la especificación, el código, las pruebas y el informe de que todo pasó. Esa es la razón por la que el arnés tiene que ser externo. Si el que genera es también el que verifica, la escalera se convierte en una caja con escarabajo, elegante y vacía. La separación entre generador y verificador no es una desconfianza hacia el modelo; es la condición para que la palabra «hecho» conserve significado.

Tirar la escalera

Y aquí Wittgenstein me regala la última imagen, la del penúltimo parágrafo del Tractatus: sus proposiciones, dice, son como una escalera que hay que tirar después de haber subido por ella. Es la mejor descripción que conozco de lo que en Atlas llamamos descomplejización. Cada componente del arnés codifica una suposición sobre lo que el modelo no sabe hacer solo, y cada versión nueva del modelo deja obsoleta alguna de esas suposiciones. Anthropic podó más del ochenta por ciento de las instrucciones de su propia herramienta al llegar la generación actual. El andamiaje se desecha a medida que el modelo aprende a subir solo; lo que no se desecha es lo que se vio desde arriba, que es el criterio: qué exigimos, cómo lo comprobamos, qué prueba dejamos. Los peldaños cambian de material; la exigencia de que cada frase pueda comprobarse, no.

De Wittgenstein me quedo además con dos reglas de conducta. Su aversión a multiplicar los nombres cuando lo que hay es un mismo uso es la que aplico cuando alguien propone un protocolo nuevo que comparte seis de siete puertas con otro: no son dos protocolos, es uno con un parámetro sin bautizar. Y su silencio ante lo que no se puede decir es, traducido a mi oficio, la prohibición de declarar hecho lo que no se puede enseñar. No es un principio filosófico colgado en la pared. Es un hook de pre-commit.

Cómo se genera conocimiento en un sistema así

Con el tiempo he visto que PRISM se rige por un ritmo de dos tiempos que la literatura del diseño lleva décadas describiendo: abrir y cerrar, divergir y converger. Guilford distinguió los dos tipos de pensamiento en los años cincuenta y el Design Council los convirtió en el doble diamante. Lo que me ha sorprendido es descubrir que las piezas que ejecutan cada mitad no son las mismas. La divergencia la hacen el cónclave, que es nuestro método para preguntar lo mismo a varios corpus de fuentes y contrastar lo que responden (este artículo ha brotado de uno); el debate entre dos cabezas de proveedores distintos; y una obligación que impuse en cada encargo de consignar qué huecos habría señalado un senior. La convergencia la hacen las puertas, la norma de calidad, las pruebas y la ficha de decisión con sus alternativas desechadas. Divergir con máquinas, converger con puertas: así lo diría hoy.

Lo que permite que la divergencia no se desborde es la ontología, y con esta palabra me he reconciliado tarde. Una ontología, en el sentido técnico que le dio Gruber, es una especificación explícita de qué cosas existen en un dominio y cómo se relacionan. En PRISM está repartida en cuatro vocabularios: las familias de la norma de calidad, el diccionario de conceptos con que componemos los encargos, el glosario de piezas del método y el mapa que traduce cada pieza a su nombre en el mercado. Sin ontología, cuando abro preguntas cosecho prosa; con ella cosecho opciones conmensurables, y solo las opciones conmensurables se pueden cerrar con criterio.

Esto enlaza con dos libros de gestión del conocimiento que releí para escribir esto. Nonaka y Takeuchi explicaron hace treinta años cómo una organización crea conocimiento: lo tácito se vuelve explícito, lo explícito se combina, y lo combinado se vuelve a interiorizar como oficio. Mis correcciones reiteradas durante meses eran conocimiento tácito. La constitución, la norma y las decisiones registradas las hicieron explícitas. Lo que espero del equipo es que las interiorice hasta engendrar correcciones nuevas que yo no habría visto, y que esas vuelvan a explicitarse. Davenport y Prusak añaden la advertencia que más me conviene tener presente: la tecnología del conocimiento solo cuaja si entra en las rutinas y en las decisiones de la gente, y los sistemas de reglas explícitas naufragan cuando pretenden suplantar el juicio tácito. Un método no es una verdad; es una manera ordenada de seguir aprendiendo, y el juicio sigue siendo de las personas.

Y hay una consecuencia que me parece la más sugestiva de todas: los protocolos nuevos no se inventan, se reforman. Cuando alguien reclama un protocolo que no existe, lo primero es demostrar que no existe con otro nombre; lo segundo, comprobar que no es un protocolo existente con un parámetro sin bautizar, que es la regla de Wittgenstein contra la inflación del lenguaje; lo tercero, dejar una ficha de decisión con lo desechado; y lo cuarto, una prueba que sepa fallar. Con esos cuatro frenos, generar protocolos deja de ser magia y pasa a ser una reforma constitucional menor: el generador de motores de la fábrica, con las mismas dos salidas de entonces, o las variables estaban mal medidas o ha aparecido una familia nueva. Un catálogo que engorda deprisa no es indicio de riqueza, sino de vocabulario exiguo.

Qué sabe el agente cuando empieza, y cuánto cuesta que lo sepa

De todas las piezas, esta es la que declaro abiertamente como reto, no como módulo. Un agente no recuerda nada entre sesiones. Cuanto sabe se lo entrego al abrir: instrucciones, reglas, memoria de sesiones anteriores, inventarios de herramientas. Medí hace unos días un puesto real y el resultado me sonrojó un poco: lo que el agente sabe de mí como usuario pesa unas veinte veces más que lo que sabe del proyecto en el que va a trabajar. Para una persona sola puede valer; para un equipo, la proporción tiene que invertirse.

El problema no es la escasez de contexto, sino su exceso. Una regla caducada se acata con la misma diligencia que una vigente; lo vi con seis reglas que seguían ordenando usar una herramienta retirada meses antes. Y cada regla que añado se paga en cada sesión y en cada subagente, a perpetuidad. Es el efecto látigo del que hablé al principio, aplicado a las instrucciones: una variación exigua arriba se amplifica en cada eslabón de abajo. La investigación sobre la degradación del contexto (Chroma la bautizó «context rot») mide cómo el rendimiento decae a medida que crece lo que el modelo tiene delante, y el hallazgo de Letta de que un agente con solo un sistema de ficheros y una búsqueda aventaja a memorias mucho más sofisticadas me confirma que el disco es la memoria y el contexto es un paraje hostil donde las cosas se pudren. Anthropic lo ha teorizado como ingeniería de contexto: contexto mínimo de alta señal, herramientas que se cargan cuando hacen falta, subagentes que devuelven resúmenes y no volcados.

Mi respuesta provisional es la postergación de la fábrica aplicada al contexto: perfiles de arranque elegidos por la encomienda y no por la memoria de quien la lanza, medición de qué se carga y qué se usa de veras, y retirada registrada de cuanto no se usa. Y sobre todo, admitir que aquí es donde el criterio se convierte en coste. Si PRISM es una distribución, este módulo es el instalador que decide qué parte de la política entra en cada sesión. Es el producto de verdad, y todavía no lo tengo.

Quién responde cuando actúan

No quiero terminar sin la parte incómoda. Cuando un agente hace algo, quién responde. La respuesta técnica es la que Atlas recoge como arquitectura canónica para operar agentes como empresa: registro de agentes, identidad por agente, puerta humana antes de la acción irreversible, rastro de auditoría. La regulación europea ya obliga a parte de ello para los sistemas de alto riesgo. Pero la respuesta que me importa es anterior a la técnica. Mi constitución dispone que toda acción irreversible o con dinero pase por una persona, y que nada se declare hecho apoyándose solo en el autoinforme de quien lo hizo. No es recelo hacia los agentes; es la misma desconfianza constructiva que la aviación profesa al piloto avezado, y que el piloto avezado agradece.

De ahí nace también mi posición sobre la autoría. Los agentes firman commits en mi repositorio, y me parece bien que quede constancia de la herramienta. Pero no son autores, porque no pueden responder de nada, y responder es el criterio de autoría en cualquier convención seria. Las personas que trabajen en PRISM a partir de ahora sí lo serán, con su rol y en la versión en que entraron, igual que en una publicación científica se distingue quién concibió, quién diseñó el método y quién escribió el código. La propiedad ya la resolvimos con una licencia abierta y una empresa como titular; el crédito es otra capa, y prefiero que sea generosa y precisa antes que ambigua.

Cómo visualizo la evolución

Atisbo cuatro movimientos, y ninguno lleva fecha, porque en el trabajo con agentes las fechas las ponen las dependencias y no el calendario.

El primero es que los grandes van a fabricar el andamiaje. Ya lo están haciendo: cada herramienta de agente absorbe un tramo más de lo que hoy hago a mano, y cada modelo nuevo se entrena justamente para necesitar menos ayuda. Mi trabajo no es competir con eso, sino apalancarme en ello: cada vez que el núcleo mejora, sube el valor relativo de la política. Por eso PRISM es deliberadamente autocontenido y no se acopla a ningún motor: vocabulario sí, dependencia no.

El segundo es que el registro precede al panel, la lección de la torre de control que conté al principio. La plataforma empieza por abajo, con un registro automático de cada petición y cada ejecución, con el modelo real que se usó, y una vista sencilla solo cuando los datos existan y merezcan la pena.

El tercero es que pasa de mi casa al equipo. Lo que hoy es un sistema personal, con mis reglas y mis memorias, tiene que funcionar en la máquina de cualquiera sin una sola cuenta ni infraestructura mía. Esa prueba de independencia es la que separa un hábito de un producto, y es la que ahora preparo.

El cuarto es que el ecosistema se compone. PRISM no es una aplicación sino un núcleo con extensiones: la constitución, las secuencias, las puertas y la norma en el centro; en derredor, formas de trabajar que se acoplan (los bridges entre sesiones y entre repositorios, la orquestación con varios proveedores, los bots que recorren el producto como usuarios); y fuera, un taller de herramientas ajenas que el método cita en sus puertas pero jamás reimplementa. Con una regla que lo mantiene sano: un solo dueño por capa, nunca dos sistemas dirimiendo lo mismo. Y en la entrada, algo que me parece la ventaja menos evidente frente a cualquier herramienta genérica: el agente no arranca en blanco, arranca conociendo el ADN del proyecto, para quién es, con qué voz y con qué promesa.

No me enrollo más. Si algo he aprendido en estos meses es que el trabajo con agentes no va de agentes. Va de qué exiges, cómo lo compruebas y qué prueba dejas. Lo sabían los ingenieros de calidad hace cincuenta años, los pilotos hace setenta y los científicos desde Popper. Lo inédito es que ahora hay que explicárselo a una tripulación que cada mañana empieza de cero, y que lo hará bien si la forma de trabajar se hace cumplir sola. Sigo aprendiendo y lo comparto; si andas en lo mismo, me gustaría saber qué preguntas te haces.

Fuentes y lecturas

Libros:

• Kyle Stratis, AI Agents with MCP (O’Reilly, 2026, edición temprana): la responsabilidad en la aplicación anfitriona y en la persona; los límites del protocolo no los hace cumplir el protocolo.
• Ken Kousen, Claude Code: Up and Running (O’Reilly, 2026): los ficheros de instrucciones dan contexto, no imposición.
• Chip Huyen, AI Engineering (O’Reilly, 2025).
• Maarten Grootendorst y Jay Alammar, An Illustrated Guide to AI Agents (O’Reilly, 2026).
• Ikujiro Nonaka y Hirotaka Takeuchi, The Knowledge-Creating Company (1995).
• Thomas Davenport y Laurence Prusak, Working Knowledge (1998).
• Karl Popper, Conjeturas y refutaciones (1963) y La lógica de la investigación científica (1934).
• Daniel Kahneman, Pensar rápido, pensar despacio (2011).
• Taiichi Ohno, Toyota Production System (1978).

Papers y textos de harness engineering:

• Tianbao Zhang, «Harness as an Asset: Enforcing Determinism via the Convergent AI Agent Framework» (arXiv 2604.17025, 2026).
• Jiahang Lin, Shichun Liu, Chengjun Pan y otros, «Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses» (arXiv 2604.25850, 2026).
• Joongho Ahn y otros, «From Prompts to Contracts: Harness Engineering for Auditable Agents» (arXiv 2607.08028, 2026).
• Vispute y Kadam, «Reasoning Provenance for Autonomous AI Agents» (arXiv 2603.21692, 2026).
• «SafeHarness: Lifecycle-Integrated Security for LLM Agents» (arXiv 2604.13630, 2026).
• «Why do multi-agent LLM systems fail?» (MAST, arXiv 2503.13657, 2025).
• «Do androids dream of breaking the game?» (BenchJack, arXiv 2605.12673, 2026) y Berkeley RDI, «How we broke top AI agent benchmarks».
• Geoffrey Huntley, «Everything is a Ralph loop»; Alex Lavaee, «How I shipped 100k LOC in two weeks with coding agents»; Simon Willison, «Designing agentic loops».

Doctrina de los fabricantes y de los dos bandos:

• Anthropic, «Building effective agents» (diciembre de 2024).
• Anthropic, «Effective context engineering for AI agents» y Thariq Shihipar, «The new rules of context engineering for Claude 5 generation models» (2026).
• Anthropic, «Effective harnesses for long-running agents» y «Harness design for long-running application development».
• Cognition, «Don’t build multi-agents» y Anthropic, «How we built our multi-agent research system».
• Equipo de Manus, «Context Engineering for AI Agents: Lessons from Building Manus» (2025).
• Chroma, «Context Rot: How Increasing Input Tokens Impacts LLM Performance» (2025); Charles Packer y otros, «MemGPT: Towards LLMs as Operating Systems» (arXiv 2310.08560); Qizheng Zhang y otros, «Agentic Context Engineering» (arXiv 2510.04618).

Epistemología, diseño y operaciones:

• Thomas Gruber, «A translation approach to portable ontology specifications» (1993).
• Dave Snowden y Mary Boone, «A leader’s framework for decision making» (Harvard Business Review, 2007).
• Joy Paul Guilford, «The structure of intellect» (1956) y Design Council, «The double diamond» (2005).
• Ludwig Wittgenstein, Tractatus logico-philosophicus (1921) e Investigaciones filosóficas (1953): la escalera, el silencio ante lo indecible, el significado como uso y el escarabajo en la caja.
• Dan North, «Introducing BDD» (2006) y la gramática Gherkin de Cucumber: el criterio de aceptación como conversación y prueba a la vez.
• Marshall Fisher, «What is the right supply chain for your product?» (Harvard Business Review, 1997).

Trabajo propio:

• Higini Moré, PRISM: a first principles meta-framework for cognitive delegation (paper, versión 1.1, enero de 2026).
• Atlas Agéntico, «Estado del arte del campo agéntico 2026», segunda edición (agosto de 2026): siete tesis, ocho capas y posición razonada.
• PRISM-DevMet, constitución y registro de decisiones (repositorio, septiembre de 2026).
• Cónclave CX-0065, «Desarrollo agéntico como forma de trabajar» (24 de septiembre de 2026): dos rondas a cuatro corpus, con las fuentes que citó cada uno.