Facturar un agente de IA sin romper su bucle de herramientas
BailingHub 0.9.0 publica su contrato de facturación de modelos: medir el uso del agente sin que la pasarela se quede con el control de la tarea.
Un agente de escritorio recibe la petición de preparar una promoción: inspeccionar productos, mirar inventario, redactar el texto y generar una imagen candidata, todo sujeto a la aprobación de negocio de siempre. Es una sola petición del usuario, pero por debajo hay varias llamadas al modelo, ejecuciones de herramientas locales y una generación de imagen. Si entre el agente y su proveedor se coloca una pasarela de facturación que cuenta cada petición como un turno nuevo, o que retiene el resultado hasta cuadrar el cobro, el agente se para a mitad del flujo aunque la cuenta tenga saldo. BailingHub ha publicado en su versión 0.9.0 el contrato de facturación de modelos que describe cómo separar ambas responsabilidades.
Un solo dueño del bucle
Cuando la orquestación es local, el host del agente es quien manda: monta el contexto, entrega los esquemas de herramientas, interpreta las respuestas, ejecuta las herramientas autorizadas y decide si hace falta otra llamada al modelo. La pasarela de facturación tiene un trabajo mucho más estrecho: autenticar a quien llama, comprobar el acceso al servicio y su cuota, reenviar la petición, conservar el resultado y contabilizar el uso.
Que la misma plataforma preste la pasarela y el camino de ejecución de negocio no las convierte en lo mismo. Pagar por acceder a un modelo no da permiso para cambiar el precio de un producto. Si al añadir el cobro aparece un segundo planificador o un segundo bucle de herramientas, algo se ha asignado mal.
Resultado y cobro no van juntos
«Petición» se usa para demasiadas cosas. Hay tres vidas distintas: el turno del usuario, la operación de modelo (una inferencia o una generación de imagen) y la invocación de negocio, como cambiar la descripción aprobada de un producto. Un turno contiene muchas operaciones y una respuesta puede proponer varias llamadas a herramientas; parte del trabajo local no consume cuota del proveedor.
El host crea un identificador de operación de modelo solo cuando hay una petición nueva de verdad, y lo persiste antes de enviarla. Para recuperar una respuesta perdida se usa ese identificador. Va ligado al usuario autenticado y a la cuenta de uso; las coordenadas de conversación y turno correlacionan, no son la clave de facturación. Reutilizarlo con contenido distinto es un conflicto. Las escrituras de negocio llevan su propia identidad: un recibo de modelo no prueba que el inventario se actualizara.
Hay dos preguntas que necesitan respuestas separadas: qué resultado hay disponible y si su uso ya se ha tarificado. Una imagen válida puede llegar sin medición suficiente para liquidar el cargo: la imagen está, la contabilidad no. Meter ambas cosas en un único indicador de pendiente hace que la aplicación actúe como si la generación no hubiera terminado.
La secuencia es persistir la operación y la instantánea de precios y despachar una vez; devolver aceptado o pendiente con el identificador original; guardar la imagen de forma duradera; que el host la recoja y siga su flujo; y liquidar cuando haya medición suficiente. Si no la hay, el cobro queda pendiente, pero no se oculta la imagen ni se regenera.
Sacar la liquidación de la ruta de respuesta no libera a la pasarela de su base de datos: hay que conservar resultado y medición para sobrevivir a una caída. En streaming, los eventos del proveedor se entregan según llegan, sin esperar al cálculo final del libro mayor, pero el adaptador del host decide si la respuesta sirve. Ejecutar una herramienta exige la respuesta completa, no un fragmento de argumentos a medio llegar.
El problema de fondo no es de latencia ni de una función que falte: es de propiedad. Añadir medición cambia quién controla el trabajo, y eso se decide a propósito, no por accidente. El contrato de 0.9.0 fija esas fronteras y viene con su guía de actualización emparejada.
