El agente dice que algo sucedió
Cada una de esas escenas comienza de la misma manera: prosa fluida afirmando un hecho. “Citado: Varghese v. China Southern Airlines.” “Agregué 5 pruebas y todas pasan.” “v2.1 está listo para enviar.”
El modo de fallo no es que los agentes mientan más de lo que solían. Es que el sistema circundante trata la oración como un hecho. Nada en “todos pasan” lleva la ejecución de la prueba, el compromiso contra el que se ejecutó, o quién lo observó. Una afirmación es una propuesta sobre la realidad, y una propuesta necesita algo fuera del proponente antes de convertirse en verdad operativa.
La proposición que importa
El primer paso es decidir a qué se compromete realmente la oración y escribirlo como condiciones escritas:
Claim: "I added 5 tests and they all pass."
C1: new_test_count == 5
C2: all(required_test_status == PASSED)
C3: tested_commit_digest == delivery_commit_digest
Cada condición nombra un dominio de observación cerrado (un conteo entero, un enum de estado, un resumen de ancho fijo) y un predicado sobre él. No hay lugar para “aproximadamente cinco” o “principalmente aprobado”, y no hay coerción implícita que decida tarde si 1 es igual a 1.0. Nota C3: nada en la frase original mencionaba compromisos, pero “aprobado” no tiene sentido sin “aprobado en qué”. Escribir las condiciones es donde las suposiciones silenciosas se convierten en obligaciones explícitas.
Evidencia
Las condiciones se cumplen mediante evidencia, y la evidencia nunca recibe el beneficio de la duda. Cada pieza lleva sus hechos abiertamente: cómo llegó (enviada por el arnés de llamada, o adquirida de una fuente local declarada), de qué se trata exactamente (qué ejecución, qué compromiso, qué cuenta), cuándo fue observada, qué protecciones de integridad la cubren, y cuán independiente es su fuente del agente que se está verificando.
Esos hechos no se colapsan en una única puntuación de confianza. La política de uso de evidencia de una condición nombra la combinación que es suficiente para esa afirmación en ese contexto. Un flujo de trabajo de desarrollo puede aceptar el propio informe de prueba del agente; un flujo de trabajo de lanzamiento puede requerir un recibo de un sistema independiente, vinculado al commit exacto. El mismo valor booleano, bajo dos políticas, lleva dos cantidades diferentes de prueba — y el sistema mantiene esa distinción en lugar de suavizarla.
Presente, ausente, faltante, insuficiente
Cuando una condición solicita evidencia, la respuesta se resuelve exactamente de una de cuatro maneras:
| Resolución | Significado |
|---|---|
| Presente | Un valor que satisface la política está disponible. |
| ObservadoAusente | Una observación completa prueba la ausencia en un universo declarado. |
| Falta | Nunca se suministró ni se adquirió nada para este objetivo. |
| Insuficiente | Existe evidencia, pero ninguna de ella satisface la política. |
Las dos filas del medio son donde los sistemas ordinarios exageran. Una consulta de registro que se agota no prueba nada. Una búsqueda que no devolvió filas pero nunca terminó de paginar no prueba nada. Solo una consulta completa sobre un universo declarado puede probar que un registro está ausente — que es exactamente la verificación que necesitaba la escena de citaciones fabricadas: no “no lo encontramos”, sino “una búsqueda completa del reportero prueba que no está allí.”
Verdadero, Falso, Desconocido
Un predicado tipado sobre una resolución válida produce uno de tres resultados semánticos:
| Resultado | Significado |
|---|---|
| Verdadero | La evidencia satisface el predicado. |
| Falso | La evidencia contradice el predicado. |
| Desconocido | La evidencia admisible no decide el predicado. |
Desconocido es el estado de trabajo, no un error. Los sistemas de dos valores deben redondearlo — no probado se convierte en falso (los datos faltantes se castigan como fallo) o no probado se convierte en verdadero (el progreso no respaldado se acepta). Tres valores permiten que la puerta se mantenga: la afirmación del agente de codificación sin informe de prueba no es falsa, es indecisa, y el flujo de trabajo puede indicar con precisión qué obligación está abierta.
Los fallos permanecen fuera de este triángulo. Un error de análisis, un tiempo de espera, una autorización denegada: esos son eventos operativos con su propio manejo. Nunca se disfrazan de Unknown, y nunca se convierten silenciosamente en False.
Requisitos
Las condiciones individuales se combinan en requisitos: la lógica de “hecho”:
ALL(C1, C2, C3) -- every obligation holds
ALL(tests_passed, coverage_met,
critical_findings == 0) -- the release gate from the overview
QUORUM(2 of: alice_approved,
bob_approved,
carol_approved) -- human sign-off as evidence
La evaluación de requisitos es determinista y preserva Unknown: un requisito cuyos inputs aún no pueden decidirlo permanece indeciso en lugar de predeterminarse. La aprobación humana se compone como cualquier otra condición: una firma registrada es evidencia, una falta de ella mantiene la puerta cerrada, y dos de tres quorums dejan de significar “quien respondió primero en Slack”.
Los flujos de trabajo son gráficos
El trabajo real no es una línea recta. Las pruebas y un escaneo de seguridad pueden ejecutarse en paralelo; la aprobación espera en ambos; la entrega espera la aprobación. Decision Gate modela un flujo de trabajo como un gráfico de dependencias sobre etapas:
build --> verify-tests ----+
+--> approval --> bind-artifact --> release
build --> security-scan ---+
Un escenario no está listo, preparado, abierto o completado — y la preparación deriva del progreso completado aceptado, no de la narrativa de nadie al respecto. El progreso solo avanza: una vez que un escenario está listo porque sus requisitos previos se han completado, el progreso posterior en otros lugares no puede deshacerlo. Terminar la última caja no prueba nada por sí mismo; el escenario declara su propia ley de finalización sobre las etapas completadas.
Progreso aceptado
La evaluación produce un resultado; la aceptación lo convierte en historia. Cada ejecución mantiene un registro aceptado de lo que se estableció: qué condiciones se resolvieron, de qué evidencia, bajo qué política, completando qué etapas. Las reclamaciones probadas se registran con su prueba. Las reclamaciones no probadas se mantienen —cerradas por fallo— con la obligación no resuelta nombrada. Nada avanza porque una sentencia suene terminada.
El registro se construye para ser verificado más tarde: lo que se reclamó, lo que se observó y lo que se decidió puede ser re-verificado sin confiar en el sistema que lo registró. Eso es lo que convierte “el agente lo dijo” en “la ejecución lo muestra”.
Sigue adelante
Applications muestra estas piezas dentro de superficies de productos reales. How It Works argumenta rigurosamente — incluyendo lo que esta maquinaria deliberadamente no afirma. La Documentación contiene la referencia completa.