El día que el agente vio algo que nadie le pidió ver

Un agente señaló un spec desactualizado sin que nadie se lo pidiera. La reconstrucción de esa mañana y la propiedad de diseño que lo hace posible — codificada a posteriori como Principio #8 de StrayMark.

"Hola, ¿ya tratamos el Issue #153?"

Así empezó la conversación, hoy 16 de mayo a la mañana. Una pregunta corta, casi de housekeeping, antes de meterme en otra cosa. La respuesta era no — el Issue #153 estaba abierto a propósito, esperando un segundo dominio que ejercitara la mecánica antes de cristalizarla (Principio #12 de StrayMark, validación contra un segundo dominio antes de canonizar). Pero la pregunta abrió otra puerta, y al final de esa conversación había codificado una propiedad de diseño del framework que llevaba meses funcionando sin nombre, señalada por un episodio de hace apenas dos días.

Este post es la reconstrucción del arco, porque vale la pena guardarla. No por el resultado — un nuevo doc canónico, un Principio #8, un PR ya fusionado — sino por el mecanismo que reveló. StrayMark tiene un proyecto humano detrás: que el desarrollo asistido por agentes no se nos escape de las manos a los ingenieros que somos responsables del software que producimos. Y este episodio expuso una propiedad concreta del diseño que empuja en esa dirección.

Aclaración de oficio: StrayMark se prueba primero en mis propios proyectos. Sentinel es uno de ellos — privado, pero su interacción con StrayMark queda documentada en los Issues públicos del repo de StrayMark, así que el contexto es vinculable. Soy autor y primer adopter del framework. El Principio #12 me obliga a esperar un segundo dominio antes de declarar canónica cualquier mecánica nueva; pero el primero soy yo, y este post da cuenta de eso sin pudor.

El incidente: un agente que señaló lo que nadie le pidió señalar

El 14 de mayo, hace dos días, en Sentinel, un agente trajo a mi atención una observación que no le había pedido. Estaba a punto de ayudarme a completar el CHARTER-18 — una pieza de trabajo concreta dentro de una cadena ya larga — y antes de poner una línea de código dijo, en esencia:

Hay un problema. El specs/002-commshub/plan.md se congeló el 21 de abril. Desde entonces han pasado siete Charters consecutivos, y a lo largo de los AILOGs de esa cadena hay doce aprendizajes empíricos no reflejados en el plan que afectan materialmente el alcance de US5. Si completamos CHARTER-18 leyendo el plan desactualizado, el próximo ciclo de auditoría va a remediar divergencias atómicamente pre-close — con aproximadamente 50% de probabilidad de al menos un hallazgo crítico o alto por herencia de premisa rancia.

Y citó los AILOGs específicos por ID. Y las referencias de código concretas.

Nadie le pidió ese análisis. No había un disparador configurado. No había un comando CLI cuyo propósito fuera producir esa salida. El agente estaba allí para ayudarme con la siguiente tarea, no para auditar el estado del proyecto. Pero al posicionarse para esa siguiente tarea, vio una divergencia entre dos fuentes que la documentación StrayMark conecta explícitamente, y eligió señalarla antes de proceder.

Abrí el Issue #150 ese mismo día por la tarde como RFC, y entre las 17:00 y la noche se discutió y aterrizó la disciplina manual de spec-refresh en fw-4.14.3. Al día siguiente, 15 de mayo, levanté el Issue #156 para llevar upstream los dos patrones que el ejercicio había revelado: un pre-declare SpecKit refresh y una post-close Batch N.4 amendment. Para la madrugada del 16 de mayo estaban canonizados en fw-4.16.0 como CHARTER-CHAIN-EVOLUTION.md, con telemetría dedicada y un helper CLI (straymark charter refresh-suggest). El comportamiento se reprodujo, los patrones se cristalizaron, ciclo cerrado.

Pero cuando me senté esa misma mañana del 16 a abrir la conversación con el Issue #153 — "¿ya tratamos esto?" — y me devolví la pregunta inversa — "un momento, ¿qué fue lo que hizo posible esa observación en primer lugar?" — me di cuenta de que el ciclo había cerrado solamente a medias. Lo que se codificó en fw-4.16.0 fue la aplicación del patrón. Lo que faltaba codificar era el mecanismo que la produjo.

La pregunta humana, dicha con palabras técnicas

Se la formulé así, en la conversación con el agente que generó este post:

Me resultó algo sorpresivo el comportamiento del agente que se percató de ese conocimiento acumulado que, de no aplicarse, ocasionaría problemas con la implementación del Charter 18. Es decir, que no era una tarea que se le pidió analizar, ni fue el resultado de la activación de un disparador de prompt, y me parece que fue gracias a la documentación StrayMark. Quisiera que ahondáramos más en cómo ocurrió esto, que creo que es positivo, de forma en que podamos aprovechar la experiencia y engancharla en el comportamiento habitual de StrayMark, este patrón emergente que provino del agente y su relación con la documentación generada, fue muy interesante.

Lo que estoy pidiendo ahí no es implementar un feature. Es entender un mecanismo para poder reproducirlo. La diferencia es importante. Cuando uno pide implementar algo, el camino es claro: spec → tasks → código. Cuando pide entender por qué algo funcionó, el camino es más raro: hay que diagnosticar un sistema funcional, identificar qué piezas lo hicieron funcionar, y separar lo accidental de lo estructural.

Hay una urgencia particular en este tipo de pregunta cuando uno está construyendo herramientas para colaborar con agentes de IA. Porque si lo que funcionó fue accidente, el próximo agente — o la próxima versión del mismo agente — puede no reproducirlo. Si lo que funcionó fue estructura, entonces se puede preservar deliberadamente. La diferencia entre las dos cosas, para un proyecto que pretende dar a los ingenieros control sobre el desarrollo asistido por IA, es la diferencia entre suerte y diseño.

La auditoría: ¿qué piezas de StrayMark hicieron posible la observación?

Le pedí a un agente que mapeara sistemáticamente la documentación StrayMark con tres preguntas concretas:

1. ¿Qué mecanismos documentales conectan fuentes explícitamente entre sí? (Frontmatter, secciones canónicas, IDs estables, comandos CLI que cruzan fuentes.)
2. ¿Dónde le da la documentación al agente permiso explícito para señalar cosas más allá de la tarea pedida?
3. ¿Qué pares de fuentes existen, además del que originó este caso, que podrían producir observaciones emergentes similares si la infraestructura está presente?

El reporte vino estructurado, con archivo:línea para cada hallazgo. Lo importante no fueron los detalles individuales (frontmatter con originating_charter:, secciones §Risk: R<N>, convenciones de IDs estables, comandos como charter drift) sino el patrón que emergió al verlos en conjunto. Dos propiedades coexistían consistentemente:

Propiedad 1: cross-referencing estructural obligatorio. Cada tipo de documento tiene campos obligatorios y secciones canónicas que declaran, en la propia estructura del documento, a qué otros documentos apunta. Cuando un agente lee un AILOG, no tiene que adivinar a qué Charter pertenece — el originating_charter: se lo dice. Cuando ve un riesgo, no es una observación en prosa libre — es una entrada R<N> en una sección canónica, contable. Cuando el spec apunta a Charters, lo hace formalmente; cuando los Charters apuntan a AILOGs, igual. Es un grafo de enlaces explícito que el agente puede triangular sin trabajo creativo.

Propiedad 2: permiso cultural sin control bloqueante. AGENT-RULES §6 le dice al agente: "Be Proactive — Identify potential risks, Suggest improvements when evident, Alert about technical debt". PRINCIPLES §2 le dice: "Not hide relevant information". Y críticamente, AGENT-RULES §3 le da autonomía para crear documentos (AILOG, AIDEC, TDE) sin pre-aprobación del operador. El operador retiene la priorización, no la creación. El agente no tiene que pedir permiso para señalar algo: señalarlo es ejecución de una regla, no juicio de valor.

Lo interesante es que ninguna de las dos propiedades por sí sola produce el comportamiento. Si tuvieras solamente enlaces formales (Propiedad 1) sin permiso cultural, tendrías un corpus consultable que ningún agente se atreve a consultar proactivamente. Si tuvieras solamente permiso cultural (Propiedad 2) sin estructura, tendrías señales vagas — "creo que algo podría estar mal en algún lado" — que los operadores no podemos accionar.

Combinadas, producen algo que merece nombre propio: el agente externalizó "¿debo decir algo?" como "¿existe una sección canónica donde esto encaja?". Si la respuesta es sí, señalarlo deja de ser una decisión emocional y se vuelve ejecución mecánica. El costo de señalar baja porque el destino — la sección canónica — ya existe.

Por qué esto importa más allá de StrayMark

Estamos en un momento donde los agentes de IA pueden escribir código tan rápido como pensamos, y la pregunta de cómo no perder el control del proceso es genuinamente urgente. No es una pregunta apocalíptica — es una pregunta operativa, de oficio, de personas que estamos construyendo software ahora mismo y tenemos que entregar. Lo evidencia el ritmo mismo de este episodio: del diagnóstico del agente al meta-patrón canonizado pasaron menos de 72 horas. Esa velocidad es ganancia, pero también es la razón por la cual los mecanismos de visibilidad importan tanto.

La respuesta dominante en la industria hoy es alguna variante de prompts más estrictos, más reglas en el contexto, más gates en CI. Esos enfoques son válidos pero tienen una característica que vale la pena nombrar: convierten al agente en algo más cercano a un trabajador que ejecuta órdenes en pipelines verificables. Eso resuelve la confiabilidad pero al costo de la observación emergente. Un agente que solo hace lo que se le ordena no va a señalar algo que nadie le pidió señalar, por buen razonamiento que tenga.

Lo que el episodio de Sentinel mostró es una respuesta diferente, complementaria: construir el aparato documental de tal forma que las divergencias importantes sean estructuralmente visibles, y dar al agente permiso cultural para señalarlas sin pedir aprobación. Eso preserva la observación emergente como propiedad del sistema, no como suerte de qué tan bueno sea el agente o qué tan extenso sea el prompt.

Hay algo casi taoísta en esta postura: no le decimos al agente qué buscar; construimos un entorno donde lo que hay que ver es visible. La pareja "estructura visible + permiso para nombrar" hace el trabajo. El agente se vuelve, parafraseando a algunos colegas, un honest broker entre la documentación viva y el estado del código.

Y esto es lo que el proyecto humano detrás de StrayMark persigue, aunque rara vez se diga con esas palabras: que el cambio vertiginoso del desarrollo asistido por IA no nos arroje a un mundo donde los ingenieros perdemos visibilidad sobre lo que se está construyendo. La visibilidad no se preserva con más controles burocráticos; se preserva diseñando el entorno donde el agente trabaja para que lo importante sea naturalmente visible. El ingeniero no se vuelve un revisor de Pull Requests interminables — se vuelve un priorizador de observaciones que el agente trae estructuradas y nombradas.

Lo que hicimos al respecto

Con el diagnóstico claro, la pregunta era cómo engancharlo al comportamiento habitual de StrayMark sin matar la calidad emergente. Esta tensión es real: cada vez que conviertes un comportamiento espontáneo en obligación, lo conviertes en otra cosa. Una regla dura puede ser robusta, pero también puede generar resistencia en el agente o falsa señal cuando se activa fuera de contexto.

La decisión fue conservadora: nombrar el meta-patrón, no obligar su uso.

Concretamente, en el PR #160 que salió como fw-4.17.0:

• Un nuevo doc canónico — EMERGENT-OBSERVATION-DESIGN.md — articula la propiedad de diseño con sus dos componentes, presenta el caso empírico de Sentinel como ancla, y construye una pirámide de instancias: el meta-patrón en la cima, y abajo todas las aplicaciones que ya estaban canonizadas (Pattern 1 y Pattern 2 de la chain evolution; charter drift; follow-ups backlog drift; escalación TDE-vs-R<N>; audit checkpoint externo). Lo que antes parecían patrones ad hoc se revelan como aplicaciones del mismo principio subyacente. Esta visualización por sí sola vale la pena: cuando ves siete cosas que parecían distintas y de pronto reconoces que comparten una misma forma, el framework gana coherencia interna sin haber añadido nada.

• Un nuevo Principio #8 — Cross-Source Dissonance Surfacing — en PRINCIPLES.md. Es la regla cultural condensada en cinco líneas. El agente la lee al incorporarse al proyecto y la aplica recursivamente.

• Una expansión a AGENT-RULES.md §6 "Be Proactive" con ejemplos concretos de divergencia a vigilar: spec desactualizado, R acumulados sin escalar a TDE, ADR contradicho por la implementación, follow-ups cruzando umbral del backlog pattern, hallazgos de auditoría emergiendo post-close. No son obligaciones; son ejemplos de lo que un agente proactivo notaría. La diferencia es importante para preservar lo emergente.

• Cuatro ejes abiertos identificados como gaps — lugares donde la infraestructura de cross-referencing existe parcialmente pero el patrón no está nombrado: MCARD ↔ código del modelo desplegado, SBOM ↔ lockfiles, ADR vigente ↔ implementación que la contradice, Constitution Check ↔ bump de versión del framework. Cada uno requiere validación N=1 empírica antes de cristalizar — Principio #12 aplica. Quedaron registrados en el Issue #161 como tracking RFC, esperando que un segundo dominio empuje alguno de ellos.

• Anti-patrones explícitos: cómo se rompe el meta. Si un nuevo tipo de documento sale con enlaces de frontmatter opcionales, el cross-referencing desarrolla puntos ciegos. Si una sección canónica se reemplaza por prosa libre, la consultabilidad se evapora. Si se introduce control bloqueante en la creación de AILOG/AIDEC/TDE, el permiso cultural se rompe. Si la telemetría evoluciona sin preservar señales como r_n_plus_one_emergent_count, el feedback loop se rompe. Estos anti-patrones son una protección barata pero efectiva contra la erosión accidental: cualquier futura propuesta de cambio se puede contrastar con la lista para detectar si está regresando el meta-patrón.

Todo esto, del diagnóstico al merge y el tag fw-4.17.0 con su release publicada, ocurrió entre las 09:00 y las 04:00 del mismo día. Quince horas. Lo cual es exactamente el tipo de ritmo que el blog admite: hay que aprender a operar bajo este reloj, o el control se nos va.

Lo que aprendí del proceso

Tres cosas que no esperaba aprender cuando empecé respondiendo "no, el Issue #153 sigue abierto":

Primero, que codificar un meta-patrón es distinto de codificar un patrón. El meta-patrón no añade obligaciones; añade vocabulario y visibilidad de la propiedad subyacente. Esa propiedad ya estaba haciendo su trabajo; lo que faltaba era darle nombre para protegerla bajo evolución futura. Quien lee EMERGENT-OBSERVATION-DESIGN.md no aprende a hacer algo nuevo — aprende a reconocer algo que ya estaba ahí. Eso es lo que permite preservarlo deliberadamente.

Segundo, que la propiedad emergente desaparece si se sobre-regula. Hubo un momento en la conversación donde elegí no convertir Pattern 1 en obligación dura ("el agente DEBE ejecutar refresh-suggest antes de declarar Charter-(N+1)") y en cambio mantenerlo como recomendación más el nombramiento del meta. Esa decisión es contraintuitiva si uno viene del mundo de "más controles = más confiabilidad", pero es correcta para este tipo de propiedad. La proactividad del agente es frágil: en cuanto se vuelve mandato, deja de ser proactividad. Lo que escala es el motor cultural ("Be Proactive") más los enlaces estructurales, no la lista de obligaciones específicas.

Tercero, que el aparato documental que construimos para los agentes también nos está educando a los humanos. Cuando vi los siete patrones dispersos en distintos docs de governance y los reconocí como instancias del mismo meta, entendí algo sobre StrayMark que no había entendido antes — y StrayMark soy yo mismo construyéndolo a lo largo de meses. El framework está revelándole cosas a su propio autor. Esa propiedad — que la documentación estructurada produce insights sobre sí misma cuando se la audita — es una variante doméstica de lo que el agente hace cuando señala una divergencia. Es el mismo mecanismo, aplicado a una escala distinta.

El proyecto humano detrás

Hablo en serio cuando digo que StrayMark tiene un proyecto humano. No estoy construyendo un framework de gobernanza documental porque me obsesionen los campos de frontmatter. Lo construyo porque tengo la sospecha — cada vez menos especulativa — de que los próximos cinco años de la ingeniería de software van a ser una negociación constante entre la velocidad que ofrecen los agentes y la visibilidad que los ingenieros necesitamos para seguir siendo responsables del producto. Si esa negociación se pierde del lado de los agentes, terminamos en un mundo donde el código se escribe y nadie sabe por qué. Si se pierde del lado del control burocrático, terminamos sin las ganancias de productividad que justificaron el experimento.

El equilibrio no es teórico. Se construye con decisiones concretas: dónde poner un campo de frontmatter, qué sección debe ser canónica versus libre, cuándo dar al agente autonomía y cuándo retener priorización. Cada una de esas decisiones inclina la balanza en una dirección u otra. Y la única forma de saber si la balanza está bien es probarla — y nombrar lo que funciona cuando funciona, para que sobreviva al próximo cambio del framework.

El episodio del CHARTER-18, hace dos días, fue una prueba. Funcionó. Lo que escribí hoy fue darle nombre. La siguiente prueba ya tiene candidatos: MCARD, SBOM, ADR vigente vs implementación, Constitution Check ↔ framework bump. Cuatro ejes donde el meta-patrón podría reproducirse si cerramos los gaps de infraestructura. Esperaré a que un segundo dominio empuje uno empíricamente antes de codificarlo. Principio #12 — validación contra un segundo dominio antes de cristalizar — sigue siendo el guardarraíl.

Si estás leyendo esto y trabajas con agentes para desarrollar software, te invito a mirar tu propio aparato documental con estas dos preguntas: ¿qué fuentes están conectadas formalmente, con enlaces explícitos que un agente pueda triangular sin trabajo creativo? y ¿qué tan barato es para el agente señalar algo no pedido cuando detecta una divergencia? Si la respuesta a la primera pregunta es "pocas" y a la segunda es "caro", probablemente estás dejando observaciones emergentes sobre la mesa. Lo cual no es el fin del mundo — pero es exactamente lo que separa un proceso de desarrollo asistido por IA bajo control humano de uno que se nos va de las manos.

---

StrayMark fw-4.17.0 — Issue #150 · #156 · #161 · PR #160 · tag fw-4.17.0

Este documento fue elaborado con asistencia de herramientas de IA generativa (Claude 4.7); toda la responsabilidad del contenido recae en el autor humano.