Cuando el costo se desvía sin que cambie el resultado, el incidente vive en la capa de control y no en la inteligencia del agente

Una prueba funcional puede declarar verde mientras la factura está roja. Si un agente abre un contenedor, ejecuta su trabajo y devuelve el archivo correcto, los tests tradicionales pueden considerar la ejecución exitosa. Sin embargo, la misma sesión puede quedar mal medida, conservar recursos facturables o registrar unidades que no corresponden a la realidad. Esa separación crea una clase de incidente silencioso: no afecta el output, pero sí la economía del sistema. En productos agentic donde cada tarea puede activar cómputo variable, el costo deja de ser una métrica administrativa posterior y se convierte en una propiedad que también necesita pruebas de corrección.

El metering debería tener invariantes verificables. Algunas reglas pueden ser simples: una sesión cerrada no sigue acumulando tiempo; la memoria facturada no supera el máximo permitido por el perfil; una herramienta no aparece dos veces por un retry idempotente; el total de una factura se puede reconstruir desde eventos de run. Estas invariantes no requieren conocer la lógica interna del modelo. Son propiedades del sistema distribuido que lo rodea. Cuando se rompen, una alerta puede activarse antes de que un cliente detecte el problema en su estado de cuenta.

La reconciliación necesita dos fuentes de verdad. Confiar únicamente en el contador que genera la factura dificulta detectar sus propios errores. Conviene mantener telemetría operacional independiente: timestamps de inicio y cierre, asignación de recursos, llamadas y lifecycle. Después se compara ese registro con las unidades facturables. No tienen que ser idénticos en formato, pero deben poder reconciliarse dentro de tolerancias explícitas. En una plataforma multicloud o multimodelo, esta práctica también permite normalizar proveedores distintos y explicar por qué una tarea cuesta diferente según runtime o ruta.

Los presupuestos por run son mejores que las sorpresas mensuales. Un límite mensual ayuda a finanzas, pero llega tarde para descubrir que una sola ejecución se volvió anómala. El sistema puede estimar un rango antes de empezar y revisar consumo durante el run. Si la desviación supera un umbral, cambia a un estado controlado: pausa, reduce paralelismo o solicita autorización. Esto no debe convertirse en un kill switch ciego que deje efectos a medias. La habilidad necesita checkpoints donde pueda detenerse sin duplicar acciones ni corromper estado. Cost control y diseño de reanudación están directamente conectados.

La unidad útil es costo por outcome verificado. Comparar precio por token o por vCPU ayuda a infraestructura, pero el negocio compra resultados. Un agente barato que falla y necesita tres reintentos puede costar más que una ruta inicialmente cara. Por eso el dashboard debería combinar consumo con tasa de éxito, tiempo y calidad. Para workflows repetibles, se puede calcular un rango esperado por outcome y detectar regresiones cuando una nueva versión se aleja. Esa métrica también reduce discusiones engañosas sobre proveedores: no se pregunta quién tiene el precio unitario menor, sino qué arquitectura entrega el resultado aprobado con menor costo total.

Implicación para Goatify. Podemos construir FinOps en el runtime desde el principio. Cada habilidad declara expectedcostrange, checkpoints y acción de degradación. Cada run produce eventos independientes y un recibo final reconciliado. Un servicio de anomalías compara costo por outcome a través del tiempo y distingue cambios por modelo, herramientas o infraestructura. Así, un problema de metering no queda escondido detrás de una respuesta correcta. La confianza empresarial aumenta cuando el cliente puede auditar no solo qué hizo el agente, sino por qué la factura asociada a esa acción tiene sentido.