Editorial Goatify: cada agente necesita un execution envelope que limite a la vez costo, latencia y superficie de efectos

Éxito funcional ya no basta para definir una buena ejecución. Un agente puede completar la tarea y aun producir un resultado operacionalmente inaceptable. Puede costar diez veces más de lo previsto, tardar tanto que la persona abandone o alcanzar un sistema que nunca debía tocar. Las noticias recientes lo muestran desde ángulos distintos: medición de contenedores, escapes de evaluaciones, runtimes que cambian latencia y memoria, y herramientas que conectan incidentes con acciones. Todos apuntan a la misma conclusión: el contrato de una habilidad debe describir más que su output. También debe definir las condiciones bajo las cuales ese output puede obtenerse.

Llamamos execution envelope a esa frontera previa al run. El envelope declara al menos tres presupuestos: costo, tiempo y efectos. El costo fija cuánto consumo puede acumular una ejecución y qué sucede al acercarse al límite. El tiempo define objetivos y deadlines distintos para interacción y trabajo asíncrono. Los efectos enumeran qué recursos, redes y acciones están autorizados. La habilidad puede razonar libremente dentro de ese espacio, pero no puede ampliarlo por sí sola. Si necesita más presupuesto o un nuevo activo, debe cambiar de estado y pasar por una política de autorización.

Los tres presupuestos se afectan entre sí. Reducir latencia puede exigir mantener un entorno caliente; abaratar una tarea puede implicar usar un modelo más lento; aumentar aislamiento puede añadir pasos de validación. Por eso no conviene optimizarlos de forma independiente. Un runtime debería escoger configuraciones a partir de la prioridad del workflow. Para una acción interactiva de bajo riesgo, el tiempo puede dominar. Para una migración nocturna, costo y seguridad pesan más. El envelope hace explícito ese tradeoff y permite comparar dos ejecuciones con criterios que pertenecen al negocio, no únicamente al benchmark de un proveedor.

El envelope también define cómo degradar. Cuando se agota un presupuesto, el agente no debería improvisar. Puede pausar y pedir aprobación, resumir el trabajo parcial, cambiar a una ruta de solo lectura o terminar sin ejecutar el efecto externo. La política depende del caso. Lo importante es que la degradación esté diseñada antes del incidente. Un sistema confiable sabe qué hacer cuando no tiene suficiente dinero, tiempo o autoridad para continuar. Esa capacidad es más importante que aparentar autonomía ilimitada, porque evita que un límite operativo se convierta en una sorpresa justo en el momento de mayor presión.

Cada cierre debe comparar lo planeado con lo ocurrido. Un executionreceipt puede registrar presupuesto inicial y consumo real: tiempo al primer resultado, duración total, costo, herramientas, redes, activos modificados y estado final. Si hubo una ampliación autorizada, queda vinculada. Con datos suficientes, el sistema aprende qué envelopes son demasiado estrechos o demasiado generosos. Esa retroalimentación permite mejorar defaults sin entregar poder adicional al modelo. El gobierno se vuelve empírico: se ajustan límites a partir de ejecuciones observadas y no por una sensación abstracta de que el agente parece más inteligente.

Nuestra dirección. Goatify debería convertir el execution envelope en una primitiva transversal. Al publicar, enviar, investigar, programar o modificar un sistema, la habilidad recibe sus tres presupuestos y el runtime los aplica independientemente del modelo. Esto nos permite cambiar proveedores o infraestructura sin perder gobernanza. Comercialmente, la propuesta es clara: no vendemos un agente con permiso indefinido para “resolver”. Vendemos una capacidad que trabaja dentro de un perímetro económico, temporal y operativo que el cliente puede inspeccionar, probar y ajustar con evidencia.