Editorial Goatify: el verificador debe diseñarse antes que el agente porque una tarea sin prueba de cierre no puede automatizarse con confianza

La mayoría de los agentes se diseñan en el orden equivocado. El equipo empieza preguntando qué modelo usar, qué prompt escribir y qué herramientas conectar. Solo al final aparece la pregunta más importante: ¿cómo sabremos que la tarea quedó bien? Ese orden produce demos convincentes y operaciones frágiles. Un agente puede describir que envió, publicó, actualizó o investigó sin que el mundo coincida con su narración. Proponemos invertir el proceso. Antes del primer prompt, cada habilidad debe declarar el estado observable que demuestra éxito, los estados que representan fallo parcial y la evidencia mínima que permitirá a otra pieza del sistema comprobarlos.

El outcomecontract es más estable que el modelo. Un workflow para programar una publicación puede cambiar de GPT a Grok o a otro motor, pero el éxito sigue siendo el mismo: el contenido correcto existe en la cuenta correcta, con una fecha concreta, una identidad verificable y sin duplicados. Esa definición pertenece al negocio, no al proveedor de IA. Si la expresamos como contrato, podemos sustituir modelos, harnesses y herramientas sin reescribir la semántica del outcome. El verificador se convierte en una interfaz estable entre intención y efecto. Esta separación también evita que una mejora de benchmark cambie silenciosamente qué significa terminar una tarea.

La evidencia debe generarse como parte del efecto, no reconstruirse después. Un verificador fuerte necesita IDs, hashes, timestamps, estados, recibos o lecturas del sistema destino. Si esperamos hasta que algo falle para buscar evidencia, quizá ya no exista. Cada acción crítica debería producir un proofrecord en el mismo flujo. Para un archivo puede ser FileId, hash y readback; para un CRM, recordId y campos observados; para una campaña, assetId, status y presupuesto; para una investigación, URLs y fecha de consulta. La evidencia no tiene que ser enorme, pero debe permitir que una segunda función compruebe el resultado sin confiar en texto generado.

Los estados parciales merecen nombre propio. Muchas tareas fallan después de un efecto real: el archivo se publicó pero el correo de confirmación no salió, el pago se inició pero falta conciliación, el PR se creó pero no pasó tests. Reducir todo a success o failure puede llevar a repetir acciones que ya ocurrieron. El outcome contract debe incluir estados como effectverifiednotificationpending o writesucceededreconciliationfailed, según el dominio. Así el sistema sabe qué completar en un reintento y qué no debe tocar. La idempotencia nace de esta precisión, no de repetir el mismo prompt esperando que el modelo recuerde lo anterior.

El verificador también limita la autonomía de manera útil. Si una habilidad no puede demostrar una condición, no debería expandir sus efectos por intuición. Puede detenerse, conservar el trabajo y pedir revisión. Este patrón reduce la necesidad de reglas infinitas porque el sistema tiene un principio simple: no cerrar ni encadenar el siguiente efecto hasta que el estado previo sea verificable. En workflows largos, cada checkpoint puede tener su propio contrato. La autonomía se vuelve acumulativa: el agente avanza libremente entre fronteras comprobables. Es más robusto que entregar acceso amplio y auditar al final, cuando ya se han propagado múltiples errores.

Nuestra dirección. Goatify debería exigir un outcome contract al crear cualquier habilidad con efectos externos. El diseñador define qué leer antes, qué mutar, qué leer después, qué evidencia guardar y cómo reanudar. Después elegimos el modelo que mejor ejecuta dentro de ese marco. Comercialmente, esto nos diferencia de una automatización que solo encadena APIs o clicks. Podemos mostrar al cliente no solo la acción, sino su prueba. Cuando una demo termine, el panel debe poder responder: qué se pidió, qué cambió, cómo se comprobó y qué queda pendiente. Esa es una forma concreta de convertir autonomía en confianza operativa.