The four sub-categories of Meta-Software, and where each one breaks

Llevo un tiempo intentando darle forma a algo que veo todas las semanas en orgs que ya tienen agentes en producción: la sensación de que hay control, pero nadie sabe nombrar dónde exactamente. La instrumentación está, los dashboards están, los reviews ocurren — y aun así, cuando algo se cae, la respuesta más honesta es "no sabíamos que esa capa la teníamos abierta".

Por eso intenté descomponer el segundo pilar — Meta-Software — en cuatro sub-categorías. No porque cuatro sea un número mágico. Sino porque cada una responde a una pregunta distinta que un output agéntico abre, y cuando alguna queda sin dueño, ahí aparece el vacío de control. Lo que sigue es un primer corte. Sirve para mapear tu stack esta noche, y también es honesto decir que no es una derivación cerrada — es la versión que mejor me funciona hasta hoy.

Why Four and Not Three or Five

La pregunta no es matemática, es funcional. Cada sub-categoría resuelve un tipo distinto de vacío de control. Si la junto con otra, pierdo resolución; si la separo más, gano granularidad pero también ruido. Cuatro fue el corte donde dejé de poder colapsar y todavía no necesitaba ramificar.

De fondo, son las cuatro preguntas naturales que uno se hace frente a cualquier output agéntico: ¿hizo lo correcto?, ¿está estructuralmente sano?, ¿con qué contexto?, ¿bajo qué reglas? Una observabilidad funcional responde la primera. Una validación estructural responde la segunda. Una continuidad contextual responde la tercera. Una gobernanza automatizada responde la cuarta. Si falta una, hay una pregunta que ningún sistema está haciendo, y eso significa que la respuesta es "depende de que alguien se acuerde".

El número puede moverse. La lógica no. Si mañana descubro una quinta pregunta irreductible, será una quinta sub-categoría. Si demuestro que dos colapsan, serán tres. Lo que no cambia es el ejercicio: nombrar qué pregunta queda sin responder cuando el agente actúa solo.

Functional Observability

Esta es la que más gente cree tener y menos gente tiene. La observabilidad funcional mira lo que el output agéntico hace por el usuario, no lo que hace el servidor. Es la diferencia entre "el endpoint devuelve 200" y "el endpoint resolvió la intención del ticket".

Es una diferencia que suena académica hasta que uno la vive. Un agente puede responder al 100% de los requests con latencia perfecta y estar resolviendo mal el 30% de los casos. Los gráficos de infra muestran verde. El cliente está enojado. Nadie miente — simplemente se está midiendo lo que el servidor hace, no lo que la tarea resolvía.

Donde más se rompe esto es por herencia. Heredamos décadas de observabilidad técnica — latencia, errores, throughput — y damos por hecho que cubre el lado funcional. No cubre. Cubre la salud del proceso, no la salud del propósito. Y eso, en un mundo donde el agente decide qué proceso correr, deja de alcanzar.

Structural Validation

La validación estructural revisa que el output respete los arquetipos, contratos y bordes que el equipo definió. No es lint — el lint es sintáctico. Esto es semántico-arquitectural. Es la diferencia entre "el código compila" y "el código respeta la dirección de las dependencias que decidimos como equipo".

En la práctica, esto significa reglas vivas sobre cómo se acoplan los módulos, qué patrones están prohibidos, qué contratos no se pueden romper sin un cambio explícito. Reglas que un humano senior aplicaría sin pensar, codificadas para que un agente no las viole sin que alguien lo note.

Donde se rompe es brutal: una validación que se salta categorías enteras de violación es peor que no tener nada. Manufactura falsa confianza. El equipo cree que el filtro está puesto, despliega sin mirar dos veces, y cuando aparece el problema la postura es "pero si pasó las validaciones". Sí, pasó las que existían. Las que faltaban no avisan que faltan.

Contextual Continuity

La continuidad contextual es la capacidad del sistema de mantener contexto a través de sesiones, agentes y partes del sistema. Sin esto, cada interacción agéntica empieza de cero y los errores se repiten. Es el equivalente organizacional al "déjame explicártelo de nuevo" — solo que multiplicado por miles de interacciones por día.

Lo que más he visto fallar acá es sutil: el contexto se guarda, pero los agentes no lo leen cuando actúan. Es una biblioteca sin lector. Hay logs, hay memoria vectorial, hay historiales — y aun así el siguiente agente toma una decisión como si fuera la primera vez que el sistema toca ese caso.

La continuidad no es solo persistencia de datos. Es disciplina de lectura. Es la respuesta a la pregunta "cuando este agente actúa, ¿con qué memoria viene cargado?". Si la respuesta es "con la del prompt", el sistema vive en presente puro. Y los sistemas que viven en presente puro repiten errores que ya pagaron.

Automated Governance

La gobernanza automatizada son reglas sobre quién puede ejecutar qué, bajo qué condiciones, con qué auditoría. Es policy-as-code escalado al nivel agéntico, con human-in-the-loop como circuit breaker para los casos donde la decisión necesita un humano que firme.

Lo difícil acá no es técnico. Es interpretativo. Las reglas tienen que ser lo suficientemente explícitas para que un agente las pueda evaluar y lo suficientemente expresivas para que cubran casos que nadie anticipó cuando se escribieron. Es un equilibrio incómodo.

Donde más se rompe: gobernanza que solo restringe pero no explica. El agente recibe un "no", no entiende por qué, y termina buscando rutas alternativas que cumplen la regla literal y violan el espíritu. No por mala fe — porque no tiene cómo distinguir. La gobernanza que funciona enseña al agente qué busca proteger, no solo qué busca bloquear.

How to Apply the Diagnostic This Week

Esta noche, lista tu stack agéntico. Cada componente que toma decisiones sin un humano detrás. Mapéalo contra las cuatro sub-categorías. Para cada celda, puntúa tres cosas: cobertura — qué porcentaje del comportamiento toca; latencia — corre al ritmo de producción o llega tarde; tasa de falsos positivos/negativos — entrega confianza real o ruido.

No busques un score agregado. Busca los rojos. Cualquier rojo en cualquier sub-categoría es un vacío de control localizado. No necesariamente una catástrofe — la catástrofe depende de qué tan crítica sea la decisión que pasa por ahí — pero tampoco invisible. Lo que no quieres es seguir creyendo que ese rojo no existe.

El diagnóstico no se hace para entregar un reporte. Se hace para que la próxima conversación de roadmap incluya "acá tenemos un vacío y vamos a decidir si lo cerramos o lo aceptamos a sabiendas". Cualquiera de las dos respuestas es mejor que no haber visto el vacío.

The Honesty of a First Cut

Estas cuatro pueden no ser el corte correcto. Puede aparecer una quinta — algo sobre alineamiento de objetivos a largo plazo, por ejemplo, que hoy no logro separar limpiamente del resto. Pueden colapsar tres en una si descubro que mi distinción entre validación estructural y gobernanza era más nominal que real.

Lo que sobrevive a cualquier reordenamiento es la pregunta que el ejercicio fuerza: si un output agéntico se salta cualquiera de las cuatro guardas, ¿quién o qué lo agarra? Esa pregunta no depende del número. Depende de que alguien la esté haciendo de forma sistemática y no como reacción a un incidente.

Esta es la lógica que desarrollé en el paper §4, y es exactamente eso — un primer corte revisable, no una verdad cerrada. Si te sirve para mapear tu stack, ya cumplió su función.

Corre el diagnóstico 4×3 en tu org y mándame por DM cuál celda salió más roja. Sin juicio — quiero entender el patrón en orgs reales.

#TechLeadership #AI #Architecture #Compliance