Audit your own stack: a guided self-check for the 4 Meta-Software categories
Cómo usar este self-check
No te quiero dar un score. Te quiero ayudar a ver tu propia matriz. La diferencia importa: un score colapsa la información en un número y te invita a competir con un benchmark inexistente. Una matriz te muestra dónde estás bien y dónde no, sin promediar lo importante con lo trivial.
La estructura es simple: cuatro sub-categorías de Meta-Software × tres preguntas cada una = doce checkpoints. Responde sí / no / no sé. No busques matiz, busca el binario honesto. Si dudas entre "sí" y "sí pero", marca "no sé". Si dudas entre "no" y "no del todo", marca "no". El instrumento solo funciona si lo respondes sin auto-engañar.
Y aquí va el punto que me importa más: cualquier "no sé" es señal más fuerte que cualquier "no". Un "no" significa que sabes que algo falta. Un "no sé" significa que ni siquiera tienes visibilidad para responder. Y el control vacuum vive escondido exactamente ahí — en las áreas donde la organización no tiene manera de saber qué está pasando. Doce minutos. Sin prisa.
Sub-categoría 1 — Functional Observability
Pregunta 1: ¿Puedo ver qué intención el agente creía estar cumpliendo cuando ejecutó la última acción impactante? No "qué hizo". Qué creyó que estaba haciendo. La diferencia es la que separa una traza de ejecución de una traza de razonamiento. Si solo tienes lo primero, vas a tener que reverse-engineerar la intención cuando algo salga mal — y eso es caro, lento, y propenso a error.
Pregunta 2: ¿Sé qué porcentaje de acciones agénticas pasan por un sistema que las correlaciona con su outcome real? Es decir: no solo logueo la acción, sino que cierro el loop con lo que pasó después. Si el agente aprobó un refund, ¿se conectó esa aprobación con la satisfacción del cliente, con la disputa que vino o no vino, con el costo real? Sin ese cierre de loop, observability es solo logging — y logging sin correlación no es observability funcional, es archivo.
Pregunta 3: Si un agente toma una decisión hoy a las 14:00, ¿en cuánto tiempo sabría yo si fue incorrecta? Si la respuesta es "semanas" o "cuando un cliente se queje", tienes una latencia de detección que la velocidad de producción agéntica va a exceder. La pregunta no es si vas a detectar — es si vas a detectar antes de que la cantidad de decisiones malas acumule deuda imposible de pagar.
Sub-categoría 2 — Structural Validation
Pregunta 1: ¿Tengo evals que detecten cuándo el output del agente viola constraints estructurales del dominio? No sintácticas. Estructurales. Un eval sintáctico verifica que el JSON sea válido, que el endpoint responda 200, que la firma de la función sea correcta. Un eval estructural verifica que el agente no esté violando una invariante del negocio — que no esté creando un pedido sin cliente, que no esté aprobando un crédito que rompe el límite regulatorio.
Pregunta 2: ¿Las evals corren al ritmo de la producción agéntica, o se quedan atrás? Esto es lo que casi nadie mide. Si tu agente produce cien decisiones por hora y tus evals corren una vez al día, tienes una ventana de ocho horas durante la cual ochocientas decisiones pasaron sin validar. Esa ventana es donde la deuda silenciosa nace y crece.
Pregunta 3: ¿Sé qué categorías de violación mis evals no cubren — o asumo que cubren todo lo importante? La asunción es el riesgo. Una buena disciplina de evals incluye un mapa explícito de "esto cubrimos / esto no cubrimos / esto no sabemos si cubrimos". Sin ese mapa, la confianza en las evals es exactamente la falsa seguridad que precede a los incidentes que más duelen.
Sub-categoría 3 — Contextual Continuity
Pregunta 1: ¿El agente tiene acceso a un corpus de executable knowledge actualizado con las convenciones, arquetipos y decisiones de mi organización? No me refiero a documentación. Me refiero a conocimiento ejecutable — algo que el agente pueda leer y aplicar al momento de actuar. Si tu corpus es un wiki que nadie actualiza, no cuenta. Si es un conjunto de specs vivas que el agente consulta y respeta, sí cuenta.
Pregunta 2: ¿Ese corpus se mantiene activamente, o es un snapshot que se está poniendo rancio? La continuidad contextual no es estática. Es un proceso. Si nadie tiene la responsabilidad de actualizarlo cuando la organización cambia decisiones, el corpus se desincroniza, y el agente empieza a operar con un mapa del territorio de hace seis meses. Que, en un dominio agéntico, es un mapa irreconocible.
Pregunta 3: Si un agente hace algo "raro pero técnicamente correcto", ¿sé si le falta contexto o si el contexto está mal? Esta pregunta diagnóstica vale oro. Distingue entre "el agente no sabía" (problema de cobertura) y "el agente sabía mal" (problema de calidad). Las dos requieren intervenciones distintas. Y si no puedes distinguirlas, vas a aplicar la intervención equivocada y a frustrarte cuando no funcione.
Sub-categoría 4 — Automated Governance
Pregunta 1: ¿Las políticas que aplican a humanos (seguridad, compliance, costo) aplican también al output agéntico — automáticamente, no por review? El "por review" es la trampa cómoda. Suena prudente y es escalable solo hasta que el agente produce más rápido que tu capacidad de revisar. Lo cual ocurre antes de lo que crees. Las políticas tienen que estar codificadas y enforced, no recordadas y aplicadas.
Pregunta 2: ¿Hay un kill-switch funcional al nivel de capability del agente, no solo al nivel de servicio? La diferencia: apagar el servicio mata todas las capabilities del agente, incluidas las que están funcionando bien. Apagar una capability específica — "el agente ya no puede tomar refunds, pero sigue respondiendo consultas" — te permite contener el blast radius sin paralizar la operación. Si no tienes esta granularidad, tu única opción ante un problema es el corte total.
Pregunta 3: ¿Sé qué pasa cuando dos agentes toman decisiones contradictorias — quién resuelve, en qué tiempo? Esta pregunta parece exótica y va a ser muy común. Multi-agente no es un futuro lejano; ya está pasando. Y la gobernanza multi-agente — cuando el agente A aprueba y el agente B niega — necesita resolución explícita. Si tu respuesta es "todavía no nos ha pasado", la pregunta sigue siendo válida.
Cómo leer tu matriz
Verde (sí, confirmado con evidencia): el área está cubierta. Monitor it. No bajes la guardia, pero no inviertas más recursos ahí ahora.
Ámbar (sí parcial, o "no estoy seguro"): zona de potencial inversión. Empieza acá. Es donde tienes señales pero te falta consolidación. La inversión marginal en ámbar produce más retorno que la inversión marginal en rojo, porque ya tienes algo sobre lo cual construir.
Rojo (no confirmado o "no sé"): control vacuum localizado. Nómbralo antes de planificar. La tentación es pasar directo a soluciones — pero si el rojo es "no sé", primero necesitas visibilidad, no acción. Comprar una herramienta para resolver un "no sé" es una manera cara de seguir sin saber.
Lo que este audit NO te dice
No te da prioridad relativa entre las cuatro sub-categorías. Eso depende de tu dominio. Una fintech regulada va a priorizar Automated Governance. Una empresa de e-commerce con agentes de soporte va a priorizar Functional Observability. La matriz te muestra dónde estás; tu contexto decide dónde inviertes primero.
No te dice qué herramienta usar. La categoría es organizacional, las herramientas son contingentes. Las herramientas cambian cada dieciocho meses; las categorías sobreviven más. Si gastas más tiempo eligiendo herramienta que entendiendo qué problema resuelve, te equivocaste de orden.
No reemplaza una conversación con tu equipo. Es un disparador, no un reporte. La utilidad real aparece cuando te sientas con tu CTO, tu VP Eng, tu jefe de plataforma, y comparan matrices. Donde hay desacuerdo entre matrices del mismo equipo, ahí está la conversación más valiosa.
Postura honesta
Las cuatro sub-categorías son un corte útil, no una derivación cerrada. Si encuentras que falta una pregunta, o que sobra, escríbeme. El audit se refina con uso. Lo que tengo es la versión 1, no la final.
El objetivo es que tú veas tu matriz, no que tú valides el framework. Si después de responder las doce preguntas el framework te parece menos útil, esa también es información valiosa — para ti y para mí. Esto ya estaba en ti — si conoces tu organización, ya tienes intuiciones sobre dónde están los rojos. El audit solo te ayuda a nombrarlos.
Responde las doce preguntas y mándame un DM o contáctame por los canales en rlabs.cl con cuántos rojos te salieron (sin nombrar cuáles) — quiero ver la distribución agregada.