Cómo construir un outcome verifier para agentes que compruebe el mundo después de cada acción importante

Paso 1 — Escribe el estado final como datos observables. Toma una habilidad real y evita frases como “publicar correctamente”. Define campos que puedan leerse: accountid, assetid, status, scheduledat, contenthash y cualquier propiedad de negocio relevante. Separa condiciones obligatorias de preferencias. El verificador no necesita entender toda la intención del usuario; necesita decidir si un conjunto de invariantes se cumple. Cuando no exista una API directa, usa una fuente secundaria confiable o un readback de la misma interfaz, pero documenta sus limitaciones. Si no puedes formular una condición verificable, marca esa parte como juicio humano y no la escondas bajo un score automático.

Paso 2 — Captura un snapshot antes del efecto. Lee el destino y guarda IDs, versión, hash o campos relevantes. Este snapshot permite detectar concurrencia, rollback y duplicados. Por ejemplo, antes de actualizar un registro registra su versión; antes de publicar busca si ya existe un asset con el runkey; antes de reemplazar un archivo guarda FileId y hash actual. La lectura previa también define qué cambió realmente. Sin baseline, una verificación posterior puede confirmar que algo existe, pero no que nuestra ejecución lo creó una sola vez ni que preservó propiedades que debían permanecer constantes.

Paso 3 — Ejecuta una mutación y haz readback independiente. No aceptes success=true como prueba suficiente. Después de la escritura, vuelve a leer desde el sistema destino y compara con el estado esperado. Para bytes, usa hash y longitud; para objetos, compara campos y versiones; para transacciones, usa identificadores y estado de conciliación. La lectura debe venir después de que el sistema haya confirmado persistencia y, si existe consistencia eventual, aplicar una política acotada de espera. No reconstruyas el resultado a partir de los datos enviados: el propósito es observar qué quedó realmente almacenado o ejecutado.

Paso 4 — Modela fallos parciales e idempotencia. Define qué pasa si la mutación ocurrió y el readback falló, si el readback confirmó pero la notificación no, o si una fase secundaria no se completó. Cada estado debe decir qué acciones son seguras en un retry. Usa runkey o idempotencykey para reconocer trabajo previo y nunca regeneres efectos solo porque el agente perdió contexto. Prueba interrupciones artificiales entre fases. Un sistema robusto debe reanudar completando piezas faltantes, no empezar desde cero. Esta prueba es especialmente importante en workflows con pagos, mensajes, publicaciones o archivos donde duplicar tiene consecuencias visibles.

Paso 5 — Añade process traces sin confundirlos con éxito. Guarda llamadas a herramientas, errores, recuperaciones y pasos redundantes para debugging. Calcula tool-call precision, argument accuracy y steps per success si aportan información. Pero el release gate permanece en el outcome. Un agente que usó una herramienta innecesaria puede aprobar si el resultado es correcto, aunque deba optimizarse; uno con trayectoria elegante falla si el estado final no coincide. Esta separación facilita mejorar eficiencia sin relajar calidad. También permite saber si una regresión vino de razonamiento, integración, herramienta o verificador.

Paso 6 — Convierte el verificador en parte del producto. Muestra al usuario evidencia proporcional: “publicado” con ID y hora, “archivo reemplazado” con hash, “CRM actualizado” con campos clave. Internamente conserva el ledger completo. Mide success rate con rango entre trials, costo por éxito y tiempo hasta outcome verificado. Crea fixtures de estados correctos e incorrectos para probar el verificador cada vez que cambie la API destino. En Goatify, una habilidad solo debería graduarse a producción cuando tiene un outcome verifier y una prueba de reanudación. El modelo puede cambiar cada semana; el contrato que demuestra que el trabajo terminó debe ser más estable.