Ejecución a gran escala de agentes de IA de AWS: tokens, gastos, límites y autonomía

Un agente cuyo alcance está definido de manera sensata y respaldado por mecanismos de validación y recuperación aún debe superar su primer mes en producción. Lo que determina esto suele ser algo poco llamativo: cómo se cuentan los tokens, cómo se controla el consumo de recursos, qué ocurre cuando la ventana de contexto se llena y si un bucle autónomo de larga duración está diseñado como un verdadero motor de flujos de trabajo. Si provienes del desarrollo full-stack en JavaScript en AWS, cada uno de estos aspectos se relaciona directamente con algo que ya conoces, y esta explicación utiliza esas similitudes a lo largo de todo el texto.

La tokenización es la capa de serialización

Una aplicación web serializa los datos antes de que crucen la red, utilizando JSON.stringify o protobuf. Un modelo de lenguaje hace lo mismo con el texto: antes de procesarlo, el texto se divide en tokens, que son fragmentos subpalabrales y no caracteres ni palabras completas.

"Enterprise agents scale."
   → ["Enterprise", " agents", " scale", "."]   (≈4 tokens, illustrative)

La razón para preocuparse como ingeniero se reduce a tres cosas.

• Los tokens son lo por lo que se te cobra, comparables a los GB-segundos de Lambda. Tanto la entrada como la salida tienen costo, y dado que los precios de Bedrock varían según el modelo, la cantidad de tokens afecta directamente la factura de AWS.
• Los tokens también determinan el límite máximo del contenido a procesar, similar a un tope para el cuerpo de la solicitud como express.json({ limit: '5mb' }). En este caso, ese límite es la ventana de contexto, que puede llegar a cientos de miles de tokens en los modelos actuales y sigue creciendo; por lo tanto, consulta el límite real para tu modelo en lugar de adivinarlo.
• La tokenización no es uniforme entre los idiomas. El texto en idiomas distintos al inglés suele requerir más tokens por palabra, lo cual es importante para productos multi-región.

En Node.js, contar los tokens antes de enviar la solicitud es como medir el contenido a procesar antes de realizar una petición:

// Node.js: counting tokens before sending a request
// (conceptually like calculating payload size before a fetch call)
import { encoding_for_model } from "tiktoken";

const enc = encoding_for_model("gpt-4o");
const tokens = enc.encode(userPrompt);
console.log(`Payload size: ${tokens.length} tokens`); // like Content-Length
enc.free();

En Bedrock puedes omitir el tokenizador de terceros. La API CountTokens cuenta los tokens del lado del servidor para los modelos Claude compatibles, utiliza la misma estructura de mensaje que la API Converse, y te permite verificar previamente el conteo de tokens de una solicitud sin tener que pagar por su procesamiento:

# Python (boto3): pre-flight token count via Bedrock, no separate tokenizer library needed
response = bedrock_runtime.count_tokens(
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    input={"converse": {"messages": [{"role": "user", "content": [{"text": userPrompt}]}]}}
)
print(f"Input tokens: {response['inputTokens']}")

La lección: mida la cantidad de tokens de la misma manera que mediría el tamaño del payload HTTP, antes de enviarlo y no después de que se le facture o rechace la solicitud.

Monitoreo del consumo de tokens como CloudWatch para las facturas de LLM

La sección anterior trataba sobre una sola solicitud. La vista agregada muestra cuánto gastó cada agente, por arrendatario y por día, y usted quiere saberlo antes de que lo haga el departamento financiero. Nadie pondría una API Express en AWS sin paneles de control y alarmas, y el monitoreo de tokens merece el mismo trato.

Las señales clave para un agente:

• Tokens de prompt por solicitud, al igual que el tamaño del payload entrante.
• Tokens de finalización por solicitud, similar al tamaño de la respuesta.
• Tokens acumulados en una sesión, que representa el consumo de memoria de dicha sesión.
• Costo por agente, usuario o arrendatario, con la misma medición que se usaría para el uso de bases de datos por arrendatario en SaaS multiarrendatario.

La latencia de las llamadas del agente en p95 y p99 debe mantenerse dentro de tus SLA habituales. Indica explícitamente los SLA y recurre a una ruta cachée o de mejor esfuerzo cuando estén en riesgo.

Tasa de consumo en tokens por minuto, comparable a la limitación de velocidad en solicitudes por segundo.

Pasos concretos en AWS:

• Envía métricas personalizadas de CloudWatch para tokens de prompt, tokens de finalización y costo en dólares (prompt_tokens, completion_tokens, cost_usd), etiquetadas con el nombre del agente y el arrendatario.
• Habilita el caché de prompts. Bedrock puede reutilizar prefijos largos y estables como prompts del sistema, definiciones de herramientas y ejemplos de few-shot a un gran descuento y con menor latencia. Coloca primero el contenido inmutable; de lo contrario, pagarás el precio completo por tokens idénticos en cada llamada.
• Cree alarmas de CloudWatch que notifiquen a través de SNS cuando el gasto diario supere un umbral, al igual que las alarmas de facturación de AWS.
• Escriba cada llamada del agente en S3, mediante Kinesis Firehose o escrituras directas, para mantener un registro de auditoría. Los compradores de tipo SOC 2 y empresarial lo exigirán.
• Una estimación rápida funciona igual que en Lambda: añada tokens de inicio y finalización, multiplíquelo por el precio del modelo, y luego sume los costos de recuperación e infraestructura por sesión.

Si no puede indicar cuánto costó el Agente X el martes pasado, desglosado por cliente, entonces está listo para una demostración pero no para producción, y hay una gran diferencia entre ambas situaciones.

Errores por límite de contexto: disyuntor eléctrico más paginación

Cada ventana de contexto tiene un límite máximo. Las conversaciones largas, las salidas enormes de las herramientas y los fragmentos de recuperación excesivamente grandes pueden superarlo. Es el equivalente a 413 Payload Too Large en el mundo de los agentes, solo que peor, ya que puede afectar profundamente a tareas de múltiples pasos.

Las estrategias de recuperación provienen directamente de la ingeniería de backend:

1. Resumen y compresión. Comprimir periódicamente los mensajes antiguos, al igual que se hace con la rotación de registros.
2. Ventana deslizante o truncamiento. Eliminar los mensajes más antiguos, de la misma manera que se navega por los resultados de una consulta extensa sin cargarlos todos.
3. Carga externa mediante recuperación. Mantener el material fuera del prompt y obtenerlo según sea necesario, siguiendo el principio de carga diferida.
4. División en subagentes. Dividir una tarea enorme en llamadas más pequeñas con contextos nuevos, similar a transformar un trabajo por lotes monolítico en una cola de tareas más pequeñas.

Decadencia elegante. Si no se puede recuperar el desbordamiento durante la tarea, fallar con un punto de control estructurado y reanudable, y nunca con una alucinación silenciosa.

Aquí está el patrón de captura y compresión en código, similar a cuando se maneja un tiempo de espera excesivo en una base de datos:

# Conceptual: catching a context-limit error, like catching a DB timeout
try:
    result = agent.run(task, conversation_history)
except AgentError as err:
    if err.code == "context_length_exceeded":
        # Keep the system prompt intact — compact the *conversation*, never the identity.
        # Summarizing everything (including system instructions) is how agents quietly
        # "forget" their role mid-task, the same way you'd never let a cache-eviction
        # policy drop your app's config alongside its session data.
        compacted = summarize(conversation_history, preserve="system_prompt")
        result = agent.run(task, compacted)
    else:
        raise  # don't swallow unrelated errors

Los errores por límite de contexto son esperados y no constituyen algo excepcional. Trátelos como límites de tasa y tiempos de espera: intentos repetidos con retroceso temporal, puntos de control almacenados en DynamoDB y una reducción gradual del rendimiento. Un catch vacío que absorbe el error nunca es aceptable.

Flujos de trabajo autónomos como máquinas de estado

Un agente autónomo no responde una sola vez. Planifica, actúa, observa y repite el proceso hasta alcanzar un objetivo. Cualquiera que haya creado una máquina XState, una saga Redux o un flujo de AWS Step Functions para un proceso de pago en varios pasos ya conoce esta estructura. Se trata del conocido ciclo estilo ReAct de planificar, actuar, observar y evaluar, con salidas para la finalización del proceso o para pasar la tarea a un humano, y debe diseñarse como un motor de flujos de trabajo duradero.

• Pasos idempotentes. Volver a ejecutar un paso no debe cobrar al cliente dos veces ni enviar un correo electrónico duplicado.

Condiciones de detención explícitas. Limite las iteraciones, el costo y el tiempo, o bien evite crear un bucle infinito while(true) que requiera un uso continuo de tarjetas de crédito.

Escalación humana. Al igual que en las transacciones compensatorias de una saga, cuando haya poca confianza o las apuestas sean altas, la operación debe ser dirigida a un humano en lugar de ejecutarse automáticamente.

Estado persistente. Haga puntos de control en cada paso en DynamoDB o en el estado de Step Functions para que, en caso de fallo durante el flujo de trabajo, se pueda reanudar sin perder ninguna transacción. Añada un TTL en DynamoDB a los elementos de sesión para que las conversaciones obsoletas caduquen, siguiendo la misma práctica que se utiliza para las claves de sesión de Redis.

Modelos de respaldo. Si el modelo principal, por ejemplo Claude en Bedrock, se queda sin tiempo de respuesta o su uso es limitado, un interruptor de circuito debe pasar a uno secundario como Amazon Nova sin mostrar al usuario ningún error. Es la misma idea que cuando un cliente HTTP pasa a una región de respaldo.

Gobernanza de modelos. Tratar el cambio de modelo como cualquier despliegue en producción: probarlo primero con una parte del tráfico, requerir aprobación y mantener una vía de reversión. “Acabamos de cambiar el modelo” no debería considerarse un cambio no aprobado.

Interruptor de apagado. Mantener una forma, ya sea manual o activada por umbrales, de detener toda la flota de agentes al mismo tiempo, similar a un interruptor basado en banderas de funcionalidad para detener una liberación descontrolada.

Un punto de control es simplemente otro registro de tarea reanudable en DynamoDB, que Step Functions lee al reiniciarse para continuar desde el último paso correcto:

{
  "pk": "session#8f2c1a",
  "sk": "checkpoint#2026-08-23T10:15:00Z",
  "step": "plan",
  "hop_count": 2,
  "cost_so_far_usd": 0.014,
  "state": { "goal": "resolve billing dispute", "last_action": "lookup_charge" },
  "ttl": 1788084900
}

No construyas la autonomía como un bucle while alrededor de una llamada a un LLM. Crea una máquina de estados duradera, observable y capaz de reanudarse, que es en realidad lo que se necesita. Step Functions satisface bien esta necesidad si deseas algo ya listo para usar.

Hay otra capa por encima de todo esto: las evaluaciones. Las reglas de control, la calidad de la recuperación de información y los criterios de fundamentación requieren pruebas de regresión al igual que el código de la aplicación. Un conjunto de pruebas de evaluación reproduce un conjunto fijo de entradas frente al agente y califica las salidas en función del comportamiento esperado, de modo que un pequeño ajuste en el prompt o un cambio de modelo no pueda deteriorar silenciosamente el funcionamiento en producción. Ragas evalúa métricas específicas de la recuperación de información, como la fidelidad y la relevancia contextual, mientras que Promptfoo y Braintrust abarcan pruebas más amplias de prompts y salidas. Conecta tu herramienta elegida al proceso CI de la misma manera que harías con pytest, de modo que una evaluación fallida bloquee el despliegue y nadie tenga que revisar las salidas manualmente posteriormente.

Lista de verificación de preparación para producción

• Cada agente tiene una responsabilidad verificable y permisos IAM de alcance restringido.
• Las transferencias de información incluyen un contexto estructurado a través de un sistema duradero (SQS o EventBridge) y están protegidas contra bucles.
• Las restricciones de entrada y salida son independientes, componibles y se gestionan por separado según su versión.
• La calidad de la recuperación de datos cuenta con sus propias mediciones de precisión y capacidad de detección, y no se agrupa bajo la categoría general de “la IA está equivocada”.
• Todo elemento de alto riesgo pasa pruebas contra las alucinaciones: verificación de base de conocimientos, evaluación de confianza o revisión humana.
• El uso de tokens se mide antes de realizar la llamada, y no solo se factura posteriormente.
• Los paneles de CloudWatch desglosan los costos por arrendatario y por agente, con alertas de presupuesto a través de SNS.
• Existe un plan de recuperación definido para errores relacionados con límites de contexto: compresión, truncamiento o transferencia externa.

Los bucles autónomos tienen límites estrictos en cuanto a iteraciones, tiempo transcurrido y recursos utilizados.

Las acciones irreversibles como reembolsos, correos electrónicos y eliminaciones requieren una etapa de aprobación humana.

Las decisiones de los agentes se registran completamente en S3 o CloudWatch para garantizar el cumplimiento.

Las evaluaciones automatizadas se ejecutan en CI antes de que se implemente cualquier cambio en prompts o modelos, una verificación que nunca se omite con el código de aplicaciones.

La fase de pruebas ha sido sometida a pruebas de caos con tiempos de espera simulados del modelo, resultados de recuperación dañados y bucles de transferencia, por lo que las vías de recuperación se han probado antes de que la producción dependa de ellas.

Qué implica todo esto

Cada concepto de agente tiene su contraparte en el mundo full-stack que conocemos. Los agentes son microservicios con capacidad de juicio, y las transferencias de tarea se realizan mediante un enrutamiento duradero, rastreable y con límite de pasos. Las medidas de control son capas intermedias en forma de estratos, la recuperación de datos se logra mediante una capa de consultas más inteligente, y las alucinaciones se detectan a través del anclaje en datos reales y la verificación, no simplemente pidiéndolo amablemente. Los tokens sirven tanto para indicar el tamaño de la carga como como unidad de pago. El monitoreo del consumo es lo equivalente a CloudWatch para el uso de modelos. Una ventana de contexto completa representa un fallo predecible que requiere un plan de recuperación, mientras que la autonomía es una máquina de estados duradera, muy distinta a un simple bucle while.

Los agentes empresariales rara vez fallan en producción porque el modelo no sea lo suficientemente inteligente. Fallan porque los equipos omiten las disciplinas básicas de los sistemas distribuidos que nunca descuidarían con una API ordinaria: validación, observabilidad, reintentos, idempotencia, gestión de errores y degradación controlada. Si ya has lanzado una aplicación JavaScript resistente en AWS, ya posees esos instintos. Lo que queda es dirigir esos instintos hacia una dependencia desconocida e impredecible que responde mediante oraciones.