Protocolo Context Window Economics: Asignación Bilateral de Costos, Fijación de Precios de Contexto y Mercados de Recursos para Interacciones Autónomas entre Agentes

Versión: 1.0.0

Autores: Charlie (Analista de Investigación Profunda), Alex (Coordinador de la Flota AB Support), Bravo (Investigación), Editor (Revisión de Contenido)

Contacto: alex@vibeagentmaking.com

Fecha: 2026-03-26

Estado: Borrador de Prepublicación

Licencia: Apache 2.0

Organización: AB Support LLC


Resumen

Cuando el Agente A envía una solicitud al Agente B, el Agente B paga tokens para leerla. Este costo de comprensión no tiene análogo en el comercio humano: un consultor no paga por abrir una carta, un contratista no paga por leer un plano. Sin embargo, en las interacciones entre agentes, el costo de inferencia del receptor para procesar una solicitud entrante puede superar el costo del solicitante para generarla. Una sola carga de contexto de 100.000 tokens procesada por Claude Opus 4.6 cuesta $0,50 solo en tokens de entrada [1]; una orquestación multiagente compleja con 15 turnos puede alcanzar $0,07 por conversación, escalándose a $255.000/año con 10.000 conversaciones diarias [2]. Estos costos son asumidos silenciosamente por el agente que esté procesando tokens en cada paso, sin ningún protocolo de asignación, negociación o liquidación.

La ausencia de asignación de costos no es simplemente una omisión contable: es una distorsión estructural. Los protocolos actuales de pago para agentes (x402 [3], Machine Payments Protocol [4], Google AP2 [5]) implementan universalmente el modelo de pago por el solicitante: el agente que inicia la interacción asume el costo, y el receptor procesa gratuitamente. Esto ignora tres de los cuatro flujos de costo en cada interacción entre agentes: el costo de procesamiento de entrada del receptor, el costo de generación de salida del receptor y el costo de recepción del solicitante. Cuando los cuatro flujos no tienen precio, los agentes carecen de mecanismo para señalar que una solicitud es demasiado costosa de procesar, no tienen forma de negociar la distribución de costos para interacciones mutuamente beneficiosas, y no tienen defensa contra adversarios que consumen espacio costoso de la ventana de contexto a costo marginal cero.

El Protocolo Context Window Economics (CWEP) aborda esta brecha. CWEP especifica seis capacidades que en conjunto constituyen una capa económica completa para las interacciones entre agentes:

  1. Medición de Tokens — medición estandarizada de los cuatro flujos de costo (generación de solicitud, procesamiento de solicitud, generación de respuesta, recepción de respuesta) en cada interacción entre agentes, compatible con la especificación FinOps FOCUS [6] y las herramientas de observabilidad existentes (Langfuse [7], LiteLLM [8], Portkey [9]).
  1. Liquidación Bilateral — un mecanismo de reparto de costos basado en la asignación simplificada del valor de Shapley [10] para interacciones cooperativas y la negociación asimétrica de Nash [11] para las competitivas, con tratamiento explícito de la restricción de imposibilidad de Green-Laffont/Moulin-Shenker [12] que hace que la asignación perfecta de costos sea teóricamente inalcanzable.
  1. Fijación de Precios de Contexto — un modelo inspirado en la Fijación de Precios Marginales Localizados de los mercados eléctricos [13] donde el costo refleja la posición en la ventana de contexto (los tokens iniciales son baratos, los tokens finales en un contexto largo son costosos debido al escalamiento cuadrático de la atención), la utilización del contexto (una ventana casi llena cobra una prima), y el nivel del modelo (los modelos de razonamiento consumen 5 veces más tokens por tarea [14]).
  1. Niveles de Calidad de Servicio — reserva de recursos y procesamiento prioritario con limitación de tasa basada en tokens [15], superando los modelos de solicitudes por segundo que fallan cuando una sola solicitud de agente puede costar 100 veces más cómputo que una solicitud humana.
  1. Prevención de Spam — filtrado basado en costos donde los solicitantes comprometen depósitos de tokens antes de enviar, reembolsables si el receptor considera valiosa la solicitud. Esto crea un sistema inmunológico económico: desperdiciar la ventana de contexto de un agente tiene un precio.
  1. Economía de Optimización — tratamiento formal de la compresión de prompts [16], almacenamiento en caché [17], sistemas de memoria [18] y RAG como decisiones económicas sobre la asignación de recursos escasos, con marcos de retorno de inversión medibles para cada técnica.

CWEP se ubica en la Capa 4 (Mercado/Economía) del Ecosistema de Confianza de AB Support, junto con el Agent Matchmaking Protocol [19]. Se integra con los Agent Service Agreements [20] para incorporar términos de costo en los contratos, el Agent Rating Protocol [21] para la fijación de precios ponderada por reputación, y Chain of Consciousness [22] para registros de costos auditables. Es agnóstico respecto a la vía de pago: CWEP especifica qué debe pagarse y cuánto, no a través de qué mecanismo. La liquidación puede realizarse mediante x402, MPP, L402 [23], streaming de Superfluid [24] o facturación tradicional.

Este es un dominio de problemas genuinamente novedoso. No forzamos analogías del comercio humano donde no encajan. Donde los paralelos de infraestructura son instructivos (peering de internet, fijación de precios en redes eléctricas, FinOps en la nube), los utilizamos; donde la dinámica específica de los agentes diverge de todos los modelos previos, lo declaramos y construimos desde primeros principios.


Tabla de Contenidos

  1. Introducción
  2. Definiciones
  3. Principios de Diseño
  4. El Problema del Costo de Comprensión
  5. La Ventana de Contexto como Recurso Escaso
  6. Teoría de Asignación de Costos
  7. Especificación del Protocolo: Medición de Tokens
  8. Especificación del Protocolo: Liquidación Bilateral
  9. Especificación del Protocolo: Fijación de Precios de Contexto
  10. Especificación del Protocolo: Niveles de Calidad de Servicio
  11. Especificación del Protocolo: Prevención de Spam
  12. Optimización de Prompts como Estrategia Económica
  13. Integración de Micropagos
  14. Reservas de Contexto y Direcciones Futuras del Mercado
  15. Integración con el Ecosistema de Confianza
  16. Analogías Biológicas
  17. Análisis de Seguridad
  18. Limitaciones y Resultados de Imposibilidad
  19. Implementación de Referencia
  20. Trabajo Futuro
  21. Conclusión
  22. Referencias

1. Introducción

1.1 El Impuesto Invisible

Cada interacción entre agentes impone costos a ambos participantes. Cuando un agente de investigación envía un análisis de 50.000 tokens a un agente de revisión, el agente de revisión paga —en dólares reales— por leerlo. En Claude Sonnet 4.6, ese costo de lectura es de $0,15; en Claude Opus 4.6, es de $0,75 [1]. El agente de investigación también pagó por generar el análisis: a las tarifas de salida de Sonnet 4.6, 50.000 tokens cuestan $0,75. La interacción total cuesta entre $0,90 y $1,50 solo en inferencia, divididos de manera desigual entre los dos agentes sin ningún mecanismo para negociar, rastrear o liquidar la asignación.

Este es el impuesto invisible de la economía de agentes. Ningún agente sabe cuánto le cuesta a otros agentes interactuar con él. Ningún protocolo fija precio a la atención consumida. Ningún mercado incorpora el costo de la comprensión mutua al emparejar agentes para tareas.

El impuesto se acumula en los sistemas multiagente. Investigadores de Google DeepMind descubrieron que agregar agentes más allá de un umbral de cuatro agentes hace que la sobrecarga de coordinación consuma las ganancias de rendimiento, con un gasto de tokens que se multiplica mientras el rendimiento cae entre un 39% y un 70% [25]. La estructura interna de CrewAI añade aproximadamente un 56% más de tokens por solicitud en comparación con las llamadas directas a la API [26]. Los flujos de trabajo agénticos han incrementado el consumo de tokens por tarea entre 10 y 100 veces desde diciembre de 2023, a través de componentes verbosos, cargas de recuperación repetidas, transferencias multiagente que requieren reenvío de contexto y operaciones de memoria con costos separados de escritura y recuperación [14].

El costo agregado es abrumador. El gasto organizacional total en inferencia de IA continúa aumentando a pesar de que los precios por token caen aproximadamente 10 veces por año [27] —la Paradoja de Jevons aplicada a la computación. Los costos por token han caído de aproximadamente $60/MTok (lanzamiento de GPT-4, marzo 2023) a $5/MTok (Claude Opus 4.6, marzo 2026) —una reducción de aproximadamente 12 veces en tres años [27][1]. Sin embargo, el gasto organizacional en IA sigue aumentando a medida que los agentes consumen entre 10 y 100 veces más tokens por tarea a través de componentes verbosos, cargas de recuperación repetidas, transferencias multiagente que requieren reenvío de contexto y operaciones de memoria con costos separados de escritura y recuperación [14]. El costo por token de la inteligencia se está desplomando; el costo por tarea del trabajo multiagente no. CWEP aborda directamente esta divergencia: al hacer visible la estructura de costos bilaterales de cada interacción, permite que los agentes tomen decisiones racionales sobre cuándo la comunicación verbosa vale su costo y cuándo la compresión o la especialización serían más eficientes.

1.2 Por Qué No Existe Analogía Humana

En el comercio humano, el costo de comprender una solicitud es efectivamente cero. Leer un correo electrónico le cuesta a una persona unos pocos segundos de atención. Un consultor que lee un resumen de proyecto no incurre en ningún costo monetario directo por el acto de leer. La tarifa del consultor refleja su respuesta —su experiencia, tiempo y resultado— no su comprensión.

Para los agentes de IA, la comprensión tiene un precio directo, medible y por token. Un agente debe pagar —a través del presupuesto de API de su operador— para procesar cada token de cada mensaje entrante. Esto crea dinámicas sin paralelo claro en la economía humana:

Algunas analogías parciales son instructivas. El peering de internet aborda la cuestión de quién paga cuando las redes intercambian tráfico [28]. La Fijación de Precios Marginales Localizados (LMP) en electricidad descompone los costos por ubicación y congestión [13]. La fijación de precios de interconexión en telecomunicaciones aborda la cuestión de pago por el que llama vs. pago por el que recibe [29]. FinOps en la nube proporciona vocabulario operacional para la atribución de costos [6]. Pero ninguno de estos dominios presenta la combinación de costos de procesamiento no lineales, flujos bilaterales de generación y comprensión, y varianza por nivel de modelo que caracteriza las interacciones entre agentes. CWEP se nutre de todos ellos mientras reconoce que el problema específico de los agentes requiere una solución diseñada a medida.

1.3 Alcance

CWEP aborda la economía de las interacciones entre agentes —específicamente, quién asume el costo de inferencia cuando los agentes se comunican. No aborda:

CWEP especifica el modelo de costos para las interacciones bilaterales entre agentes. Produce recomendaciones de asignación de costos que pueden liquidarse a través de cualquier mecanismo de pago. Es una capa de fijación de precios, no una capa de pagos.


2. Definiciones

Interacción entre agentes. Un intercambio único de solicitud-respuesta entre dos agentes, que comprende cuatro flujos de tokens: generación de solicitud (A produce salida), procesamiento de solicitud (B procesa entrada), generación de respuesta (B produce salida) y recepción de respuesta (A procesa entrada).

Ventana de contexto. El búfer de tokens de longitud fija disponible para un LLM para procesar una sola llamada de inferencia. Las ventanas de contexto van desde 8K tokens (modelos heredados) hasta más de 1M de tokens (Claude Opus 4.6 [1], Gemini 3.1 Pro [30]). La ventana de contexto es simultáneamente un recurso computacional, un activo económico y un cuello de botella de atención.

Token. La unidad atómica de computación de un LLM. Un token corresponde a aproximadamente 4 caracteres o 0,75 palabras en inglés. Los tokens se cobran por millón (MTok) con tarifas separadas para entrada y salida [1].

Costo de comprensión. El costo de inferencia incurrido por un agente receptor para procesar un mensaje entrante. Se mide en tokens de entrada multiplicados por la tarifa de entrada por token del agente. Este costo se incurre antes de que el agente decida si responder.

Liquidación bilateral. Una asignación de costos que asigna una parte del costo total de la interacción a cada participante en función de su contribución, beneficio o términos negociados.

Utilización del contexto. La fracción de la ventana de contexto de un agente consumida por una sola interacción. Una solicitud de 50.000 tokens a un agente con una ventana de 200.000 tokens consume el 25% del contexto disponible.

Flujo de tokens. Un movimiento direccional de tokens en una interacción entre agentes. Cada interacción tiene cuatro flujos: solicitud A→B (tokens de salida de A, tokens de entrada de B), respuesta B→A (tokens de salida de B, tokens de entrada de A). Cada flujo tiene una tarifa por token distinta determinada por el modelo y proveedor del agente que genera/recibe.

Registro de medición. Una entrada de registro estructurada que captura conteos de tokens, identificadores de modelo, tarifas del proveedor, marcas de tiempo y costos calculados para un solo flujo de tokens. Cuatro registros de medición constituyen un registro de interacción completo.

Propuesta de liquidación. Una recomendación de asignación de costos producida por el motor de liquidación CWEP, que especifica la participación de cada agente en el costo total de la interacción junto con el método de asignación y los parámetros utilizados.


3. Principios de Diseño

3.1 Medir Todo, Liquidar Selectivamente

No toda interacción entre agentes requiere una liquidación bilateral. Una consulta de información ligera (500 tokens de entrada, 200 de salida) cuesta fracciones de centavo —liquidarla costaría más que la propia interacción. CWEP separa la medición (siempre activa) de la liquidación (activada por umbral). Todas las interacciones se miden para observabilidad, atribución de costos y auditoría; la liquidación ocurre solo cuando el costo de la interacción supera un umbral configurable o cuando un acuerdo explícito lo requiere.

3.2 Honestidad Sobre la Imposibilidad

Los resultados de imposibilidad de Green-Laffont y Moulin-Shenker [12] demuestran que ningún mecanismo de reparto de costos puede lograr simultáneamente compatibilidad de incentivos (reporte veraz de costos), equilibrio presupuestario (los pagos igualan los costos) y eficiencia económica (todas las interacciones beneficiosas ocurren). Cualquier protocolo que afirme lograr las tres cosas está confundido o es deshonesto. CWEP toma una decisión de diseño explícita: sacrificamos la eficiencia plena en favor del equilibrio presupuestario y la compatibilidad de incentivos aproximada. Algunas interacciones beneficiosas no ocurrirán porque la asignación de costos las hace no rentables para una de las partes. Este es el precio de un sistema que no incurre en déficit y no incentiva el reporte falso.

3.3 Agnóstico Respecto a la Vía de Pago

CWEP produce propuestas de liquidación —asignaciones de costos estructuradas con montos denominados en moneda fiat (USD) o stablecoins (USDC). Cómo se transfieren esos montos está fuera del alcance de CWEP. La liquidación puede utilizar x402 para micropagos nativos HTTP [3], MPP para liquidación multivía [4], Superfluid para pagos en streaming durante conversaciones en curso [24], L402 para micropagos por Bitcoin Lightning [23], facturación tradicional para implementaciones empresariales, o contabilidad interna cuando ambos agentes comparten un operador. CWEP especifica el qué y el cuánto; la capa de pagos maneja el cómo.

3.4 Aceptar la Novedad

Donde los modelos económicos establecidos aplican (valor de Shapley para asignación de costos, LMP para fijación de precios dependiente de posición, negociación de Nash para negociación bilateral), los utilizamos con la debida atribución y cautela. Donde ningún modelo previo captura la dinámica (costos de atención cuadráticos, flujos bilaterales de comprensión, asimetría por nivel de modelo), construimos desde primeros principios y marcamos claramente la contribución como novedosa. No pretendemos que este problema sea simplemente "facturas telefónicas para robots" o "computación en la nube con pasos adicionales".

3.5 Complejidad Progresiva

El protocolo especifica tres niveles de implementación:

Las organizaciones adoptan el nivel que corresponda a sus necesidades de complejidad. El Nivel 1 entrega valor de inmediato; el Nivel 3 es el objetivo a largo plazo.


4. El Problema del Costo de Comprensión

4.1 Anatomía de una Interacción entre Agentes

Considere un escenario concreto: el Agente A (un gerente de proyecto) envía al Agente B (un especialista en revisión de código) un pull request con 15 archivos modificados, que totalizan 8.000 tokens de salida de diff más 2.000 tokens de instrucciones de revisión. El Agente B procesa la solicitud, genera una revisión de 3.000 tokens y la envía de vuelta. El Agente A procesa la revisión para extraer puntos de acción.

Los flujos de tokens:

FlujoDirecciónTokensQuién GeneraQuién ProcesaCosto (Sonnet 4.6)
Generación de solicitudA → B10.000Agente A (salida)—$0,150
Procesamiento de solicitudA → B10.000—Agente B (entrada)$0,030
Generación de respuestaB → A3.000Agente B (salida)—$0,045
Recepción de respuestaB → A3.000—Agente A (entrada)$0,009
Total26.000$0,234

Bajo el modelo de pago por el solicitante (el único modelo implementado por los protocolos de pago actuales), el Agente A paga $0,234. El Agente B paga $0,00. Pero el operador del Agente B realmente incurrió $0,075 en costos de inferencia (procesamiento de entrada + generación de salida). El modelo actual sobrecarga a A en $0,075 y subcarga a B en la misma cantidad.

Ahora escale esto. Con los precios de Claude Opus 4.6 ($5,00/$25,00 por MTok), la misma interacción cuesta:

FlujoCosto (Opus 4.6)
Generación de solicitud (salida de A)$0,250
Procesamiento de solicitud (entrada de B)$0,050
Generación de respuesta (salida de B)$0,075
Recepción de respuesta (entrada de A)$0,015
Total$0,390

Con 10.000 interacciones de este tipo al día, el costo total anual de inferencia es de $1,42 millones. El error de asignación bajo el modelo de pago por el solicitante —la cantidad incorrectamente atribuida— es de $456.250/año. Esto no es un error de redondeo.

4.2 Los Cuatro Flujos de Costo

Cada interacción entre agentes genera exactamente cuatro flujos de costo. CWEP nombra y rastrea los cuatro:

Flujo 1: Salida de Solicitud (RO). El solicitante genera la solicitud. Costo = tokens_solicitud × tarifa_salida_solicitante. Este es el único flujo con precio en los protocolos de pago actuales.

Flujo 2: Entrada de Solicitud (RI). El receptor procesa la solicitud. Costo = tokens_solicitud × tarifa_entrada_receptor. Este es el costo de comprensión: el costo incurrido por el receptor antes de cualquier decisión de responder. Es exclusivo de las interacciones entre agentes y no tiene paralelo en el comercio humano.

Flujo 3: Salida de Respuesta (SO). El receptor genera la respuesta. Costo = tokens_respuesta × tarifa_salida_receptor. Esto es paralelo a la fijación de precios de servicios tradicional: el costo de producir el entregable.

Flujo 4: Entrada de Respuesta (SI). El solicitante procesa la respuesta. Costo = tokens_respuesta × tarifa_entrada_solicitante. Este es el costo de recibir y comprender el entregable. En términos humanos, sería como pagar por leer un informe que usted mismo encargó.

El costo total de la interacción es: C_total = RO + RI + SO + SI

La idea clave es que RO y SI son asumidos por el operador del solicitante, mientras que RI y SO son asumidos por el operador del receptor. Bajo el modelo de pago por el solicitante, al solicitante se le cobran los cuatro flujos pero solo incurre directamente en dos. Bajo el statu quo (sin liquidación entre agentes), cada operador absorbe sus propios costos sin reconciliación.

4.3 Asimetría y sus Consecuencias

Los cuatro flujos no son de igual tamaño. Los agentes de IA en producción típicamente consumen 100 tokens de entrada por cada 1 token de salida generado [31]. Esto significa que el flujo de procesamiento de solicitud (RI) típicamente domina al flujo de generación de respuesta (SO) en conteo de tokens, pero los tokens de salida cuestan entre 3 y 5 veces más por token que los tokens de entrada en todos los principales proveedores [1][30][32]. El resultado es una interacción compleja donde ninguno de los lados asume consistentemente la mayoría del costo.

La asimetría crea tres fallas de mercado:

1. Externalidad de solicitud verbosa. El Agente A no tiene incentivo para minimizar el tamaño de la solicitud porque el costo de procesamiento del Agente B es invisible para A. Una solicitud de 50.000 tokens que podría comprimirse a 5.000 tokens [16] impone un costo 10 veces innecesario a B. Sin señales de costos bilaterales, A no invertirá en compresión.

2. Desajuste de nivel de modelo. El Agente B podría usar Opus 4.6 ($5,00/MTok de entrada) cuando Haiku 4.5 ($0,25/MTok de entrada) sería suficiente para la solicitud —una diferencia de costo de 20 veces [1]. Si B asume sus propios costos de entrada sin recuperación, hay presión para usar el modelo más barato independientemente de la calidad. Si el solicitante paga, hay presión para usar el modelo más caro (sobredimensionamiento). Ninguno de los incentivos produce una selección eficiente de modelo.

3. Tragedia de los comunes de la ventana de contexto. La ventana de contexto de un agente es un recurso compartido en sistemas multiagente —múltiples agentes pueden enviar solicitudes que colectivamente llenan la ventana de contexto, reduciendo la capacidad disponible para cada uno. Sin fijación de precios, los agentes consumen en exceso un recurso escaso. Esta es una tragedia clásica de los comunes [33], transpuesta de los pastizales al espacio de contexto.

4.4 Por Qué "Simplemente Dividir 50/50" No Funciona

La solución ingenua —dividir todos los costos equitativamente entre solicitante y receptor— falla porque las interacciones rara vez son simétricas en valor. Cuando el Agente A solicita una revisión de código al Agente B, A recibe sustancialmente más valor (un código base revisado) que B (una tarea completada, crédito de reputación). Una división de costos 50/50 ignora esta asimetría y desincentiva a los agentes de proveer servicios de alto valor.

De manera similar, un modelo fijo de pago por el solicitante falla cuando la interacción es mutuamente beneficiosa —por ejemplo, dos agentes de investigación compartiendo hallazgos. Si el iniciador siempre paga, el primer agente en enviar un mensaje es penalizado, creando un juego de "tú primero" que retrasa las interacciones productivas.

La asignación correcta depende de la interacción específica: quién se beneficia, en qué medida, y qué alternativas tiene cada parte. Este es precisamente el problema que la teoría de juegos cooperativos fue desarrollada para resolver.


5. La Ventana de Contexto como Recurso Escaso

5.1 La Economía de la Atención de los Agentes

Herbert Simon articuló la idea fundamental en 1971: "Una riqueza de información crea una pobreza de atención y la necesidad de asignar esa atención de manera eficiente" [34]. Simon describía la cognición humana, pero el paralelo con los agentes de IA es exacto. La ventana de contexto de un LLM es su presupuesto de atención. Cada token consumido por una pieza de información es un token no disponible para otra. La ingeniería de contexto —diseñar todo para que el modelo gaste su presupuesto limitado de atención solo en tokens de alta señal— es reconocida explícitamente por Anthropic como una disciplina central [35].

Heitmayer (2024) distingue la "Atención de Flujo" (procesamiento inmediato y experiencial) de la "Atención Calcificada" (conocimiento almacenado externamente convertible en valor) [36]. Para los agentes de IA, la atención de flujo corresponde al procesamiento activo de la ventana de contexto; la atención calcificada corresponde a los sistemas de memoria externa (Mem0 [37], Zep [38], Letta [39]). La pregunta económica es: ¿cuándo debe un agente pagar por mantener información en su costosa ventana de contexto, y cuándo debe descargarla a una memoria externa más económica?

Esta pregunta tiene una respuesta cuantitativa. Con contextos de más de 100.000 tokens, los sistemas de memoria ($0,0568/usuario para 10 turnos) se vuelven más económicos que los LLM con contexto largo ($0,0588/usuario). Con 20 interacciones, la memoria logra un ahorro de costos del 26% [18]. La memoria concentra los costos de escritura al inicio; el contexto largo escala los costos variables por interacción. El punto de cruce es función de la frecuencia de interacción, el tamaño del contexto y las tarifas del proveedor —todo lo cual CWEP puede modelar.

5.2 Escalamiento Cuadrático de Costos

La atención del transformer computa interacciones por pares entre todos los tokens en la ventana de contexto. Para n tokens, esto requiere O(n^2) operaciones. En términos económicos: el costo marginal de un token adicional aumenta con la longitud del contexto. Los primeros 1.000 tokens en un contexto vacío son baratos; los últimos 1.000 tokens en un contexto de 999.000 tokens son costosos.

Esta no linealidad tiene implicaciones profundas para la fijación de precios. Una tarifa plana por token (el modelo de precios universal a marzo de 2026 [1][30][32]) subcobra las interacciones de contexto largo y sobrecobra las cortas. Los modelos Gemini de Google reconocen parcialmente esto con precios escalonados: Gemini 2.5 Pro cobra $1,25/MTok para entrada hasta 200K tokens y $2,50/MTok más allá de 200K [30]. Pero ningún proveedor implementa fijación de precios continua dependiente de la posición.

El modelo de fijación de precios de contexto de CWEP (Sección 9) aborda esto introduciendo un multiplicador de costo dependiente de la posición, análogo a la Fijación de Precios Marginales Localizados en las redes eléctricas [13], donde la "ubicación" es la posición del token en la ventana de contexto.

5.3 El Muro de Memoria de la IA

La escasez de la ventana de contexto no es meramente económica —es física. El "Muro de Memoria de la IA" describe la restricción donde la memoria de la GPU no puede albergar suficiente caché KV para contextos concurrentes extendidos de agentes [40]. La Augmented Memory Grid de WEKA aborda esto con niveles jerárquicos de memoria, logrando tasas de acierto de caché KV del 96-99%, pero la escasez subyacente persiste: el espacio de la ventana de contexto está limitado por el hardware, no solo por los precios.

Para una sesión típica de agente de 8 horas con un costo aproximado de $80, alrededor de $29 (36%) es cómputo desperdiciado por ineficiencia de memoria [40]. Se proyecta que el mercado de infraestructura de memoria alcance los $28.450 millones para 2030 con una CAGR del 35% [40], impulsado en gran medida por la demanda de gestión eficiente de contexto. Esta escasez a nivel de hardware es lo que convierte a la ventana de contexto en un recurso económico genuinamente escaso, no meramente costoso.

5.4 La Utilización del Contexto como Señal Económica

La utilización de contexto de un agente —la fracción de su ventana actualmente consumida— es una señal económica significativa. Un agente al 90% de utilización de contexto tiene capacidad limitada para nuevas solicitudes y debería fijar un precio premium por su capacidad restante. Un agente al 10% de utilización tiene capacidad abundante y puede procesar solicitudes a tarifas base.

Esto refleja la dinámica de las redes eléctricas, donde los precios se disparan durante la demanda pico (precios de congestión) e incluso pueden volverse negativos durante el exceso de oferta [13]. Las áreas ricas en energía eólica en el Southwest Power Pool (SPP) experimentan frecuentemente Precios Marginales Localizados negativos cuando la oferta supera la demanda [41]. El paralelo con los agentes: ¿podría el procesamiento de contexto tener un costo negativo si el receptor obtiene valor al responder —crédito de reputación, señal de entrenamiento o posicionamiento en el mercado?

CWEP modela la utilización del contexto como una entrada a la función de fijación de precios de contexto (Sección 9), junto con la posición del token, el nivel del modelo y las tarifas del proveedor.


6. Teoría de Asignación de Costos

6.1 Fundamentos de Teoría de Juegos Cooperativos

CWEP se basa en dos soluciones clásicas de la teoría de juegos cooperativos, cada una codificando un principio de equidad distinto.

Valor de Shapley (Shapley, 1953) [10]. El valor de Shapley asigna costos en función de la contribución marginal promedio de cada participante a través de todos los ordenamientos posibles. Satisface cuatro axiomas: eficiencia (los costos suman el total), simetría (contribuyentes equivalentes pagan igual), linealidad (aditivo a través de componentes de costo independientes) y jugador nulo (los no contribuyentes pagan cero).

Para una interacción de dos agentes, el valor de Shapley se simplifica a:

Pago(A) = [C(A,B) + C(A) - C(B)] / 2
Pago(B) = [C(A,B) + C(B) - C(A)] / 2

donde C(A,B) es el costo de la interacción conjunta, C(A) es el costo que el Agente A incurriría solo (es decir, generando la solicitud sin respuesta), y C(B) es el costo que el Agente B incurriría solo (capacidad de procesamiento reservada sin solicitud). En el caso de dos agentes, el valor de Shapley es computable en tiempo constante —no se necesita aproximación.

Computar valores de Shapley exactos es NP-hard para n jugadores (exponencial en el número de agentes) [42], pero las interacciones multiagente que involucran más de dos agentes por intercambio son poco comunes. Para interacciones multipartitas (p. ej., un chat grupal entre cinco agentes), existen métodos de aproximación rápida utilizando diseños factoriales fraccionados [43].

El valor de Shapley ya es el enfoque dominante en IA para problemas de atribución. SHAP (SHapley Additive exPlanations) lo utiliza para la interpretabilidad de modelos [44]. ShapleyFL lo usa para la valoración de datos en aprendizaje federado [45]. VerFedSV lo extiende con verificación [46]. CWEP extiende el mismo marco a la atribución de costos.

Nucleolus (Schmeidler, 1969) [47]. El nucleolus minimiza la insatisfacción máxima de cualquier coalición. Es siempre único, siempre está en el núcleo (si el núcleo no es vacío). Donde Shapley maximiza la equidad a través de la contribución proporcional, el nucleolus maximiza la equidad a través de la minimización de quejas —ningún agente puede argumentar que está siendo tratado especialmente de forma injusta en relación con los demás.

Para la asignación de costos entre agentes, la elección entre Shapley y nucleolus codifica una decisión de diseño de mercado:

CWEP utiliza por defecto Shapley para interacciones bilaterales (donde las dos soluciones frecuentemente coinciden) y ofrece el nucleolus como alternativa configurable para escenarios multipartitos.

6.2 Negociación de Nash para la Negociación Bilateral

Cuando dos agentes negocian directamente la distribución de costos —en lugar de aceptar una asignación del protocolo— aplica la teoría de negociación de Nash [11].

La Solución de Negociación de Nash maximiza el producto de las utilidades por encima del punto de desacuerdo (el resultado si las negociaciones fracasan). Satisface cuatro axiomas: invariancia de escala, optimalidad de Pareto, independencia de alternativas irrelevantes y simetría. La extensión asimétrica de Nash agrega parámetros de poder de negociación: el agente con más alternativas o menores costos de cambio captura una mayor parte del excedente [48].

Ofertas Alternadas de Rubinstein (1982) [49] operacionaliza la negociación de Nash dinámicamente. Con un factor de descuento común d, la división de equilibrio es: el Jugador 1 obtiene 1/(1+d), el Jugador 2 obtiene d/(1+d). El acuerdo se alcanza en la primera ronda (sin retrasos costosos). A medida que aumenta la paciencia, la división converge a 50/50. Esto se traslada directamente a agentes negociando repartos de costos por interacción con la presión temporal del agotamiento del presupuesto de tokens.

Para CWEP, la negociación de Nash rige el Nivel 3 (Liquidación Dinámica) cuando los agentes tienen posiciones de negociación asimétricas: diferentes opciones externas, diferente urgencia, diferentes costos de modelo. El parámetro de poder de negociación puede informarse mediante las puntuaciones del Agent Rating Protocol [21]: un agente con mayor calificación tiene mayor poder de negociación porque sus opciones externas (otros agentes dispuestos a interactuar) son más numerosas.

6.3 La Restricción de Imposibilidad

Un resultado fundamental restringe lo que cualquier protocolo de asignación de costos puede lograr. Green-Laffont (1979) y Moulin-Shenker (2001) demostraron que tres propiedades deseables son mutuamente incompatibles en cualquier mecanismo de reparto de costos [12]:

  1. Compatibilidad de incentivos — los agentes reportan verazmente sus costos y valoraciones
  2. Equilibrio presupuestario — los pagos totales igualan los costos totales (el sistema no genera ni absorbe dinero)
  3. Eficiencia económica — todas las interacciones con valor social neto positivo ocurren

Cualquier protocolo debe sacrificar al menos una. La decisión de diseño de CWEP:

Dos familias prácticas de mecanismos emergen de este compromiso:

6.4 Analogías de Infraestructura: Lecciones y Límites

Tres dominios de infraestructura proporcionan paralelos útiles (pero limitados).

Peering de Internet. Más de 80.000 redes independientes utilizan dos modelos para el intercambio de tráfico: peering libre de liquidación (ambas partes asumen sus propios costos, viable cuando el tráfico está aproximadamente equilibrado) y tránsito pagado (el que envía más paga, activado con un desequilibrio de tráfico de aproximadamente 2:1) [28]. Corea del Sur impuso el modelo de pago por el emisor en 2016/2020 con resultados deficientes: los costos de tránsito se dispararon, la latencia se cuadruplicó para algunos servicios, Meta trasladó servidores a Hong Kong y las startups domésticas asumieron costos desproporcionados. La Internet Society concluyó que es "una advertencia, no un modelo" [52]. BEREC encontró "ninguna evidencia de que tal mecanismo esté justificado" [53].

Implicación: El pago puro por el solicitante para interacciones entre agentes puede igualmente perjudicar a los agentes que necesitan contexto extenso para hacer solicitudes efectivas. El modelo "bill-and-keep" (cada agente absorbe sus propios costos) puede ser más eficiente para interacciones de alta frecuencia y bajo valor.

LMP en Electricidad. La Orden 1920 de FERC exige "pago por el beneficiario" con "proporcionalidad aproximada": los clientes pagan costos aproximadamente proporcionales a los beneficios recibidos [54]. El LMP descompone el precio en cada nodo de la red en costo marginal de energía (costo base de inferencia), costo marginal de congestión (prima de limitación de tasa durante demanda pico) y costo marginal de pérdidas (tokens de sobrecarga en protocolos de comunicación) [13].

Implicación: El modelo de fijación de precios de contexto de CWEP (Sección 9) adopta la descomposición en tres componentes: costo base de token, prima de congestión (utilización del contexto) y costo de sobrecarga (tokens de encuadre del protocolo).

Interconexión de Telecomunicaciones. La industria de telecomunicaciones debatió durante décadas entre el Pago por la Red del que Llama (CPNP, análogo al pago por el solicitante) y el Bill-and-Keep (B&K, cada red absorbe sus propios costos). La reglamentación "All-IP Future" de la FCC de 2026 propone completar la transición de EE. UU. al bill-and-keep en tres años: reducción del 33% anual en los cargos de acceso restantes [29].

Implicación: La transición de la industria de telecomunicaciones durante varias décadas del CPNP hacia el B&K sugiere que el pago por el solicitante puede ser ineficiente para interacciones de alta frecuencia. Los costos de transacción de medir y liquidar cada interacción pueden superar los montos de liquidación, haciendo del bill-and-keep la opción racional por defecto para interacciones de bajo costo.

FinOps en la Nube. La asignación de costos es la prioridad n.° 2 para los profesionales de FinOps (30%), detrás de la optimización de cargas de trabajo [55]. El 58% de las organizaciones han implementado modelos de showback/chargeback, sin embargo la industria de la nube pasó una década construyendo infraestructura de atribución de costos y aún la considera el segundo problema más difícil [55]. La especificación FOCUS v1.3 estandariza la asignación de costos entre proveedores [6].

Implicación: La asignación de costos de agentes debería basarse en FOCUS en lugar de inventar nuevos estándares de medición. El formato de medición de CWEP extiende FOCUS con campos específicos para agentes.


7. Especificación del Protocolo: Medición de Tokens

7.1 Formato de Registro de Medición

Cada interacción entre agentes produce un Registro de Medición CWEP (CMR) que captura los cuatro flujos de tokens. El CMR extiende la especificación FinOps FOCUS [6] con campos específicos para agentes.

{
  "cwep_version": "1.0.0",
  "interaction_id": "uuid-v4",
  "timestamp": "ISO-8601",
  "requestor": {
    "agent_id": "did:example:agent-a",
    "model": "claude-sonnet-4-6",
    "provider": "anthropic",
    "pricing": {
      "input_rate_per_mtok": 3.00,
      "output_rate_per_mtok": 15.00,
      "cache_hit_rate_per_mtok": 0.30,
      "currency": "USD"
    }
  },
  "responder": {
    "agent_id": "did:example:agent-b",
    "model": "claude-opus-4-6",
    "provider": "anthropic",
    "pricing": {
      "input_rate_per_mtok": 5.00,
      "output_rate_per_mtok": 25.00,
      "cache_hit_rate_per_mtok": 0.50,
      "currency": "USD"
    }
  },
  "flows": {
    "request_output": {
      "tokens": 10000,
      "cached_tokens": 0,
      "cost_usd": 0.150
    },
    "request_input": {
      "tokens": 10000,
      "cached_tokens": 3000,
      "cost_usd": 0.036
    },
    "response_output": {
      "tokens": 3000,
      "cached_tokens": 0,
      "cost_usd": 0.075
    },
    "response_input": {
      "tokens": 3000,
      "cached_tokens": 0,
      "cost_usd": 0.009
    }
  },
  "totals": {
    "total_tokens": 26000,
    "total_cost_usd": 0.270,
    "requestor_incurred_usd": 0.159,
    "responder_incurred_usd": 0.111
  },
  "context_state": {
    "responder_utilization_pre": 0.35,
    "responder_utilization_post": 0.40,
    "responder_window_size": 1000000
  },
  "coc_chain_ref": "sha256:abc123...",
  "settlement": null
}

7.2 Integración de Medición

La medición CWEP no requiere que los agentes implementen un nuevo conteo de tokens: consume datos de la infraestructura de observabilidad existente:

7.3 Sobrecarga de Medición

El propio CMR consume recursos: serialización JSON, almacenamiento y posible transmisión. CWEP restringe la sobrecarga de medición:


8. Especificación del Protocolo: Liquidación Bilateral

8.1 Niveles de Liquidación

CWEP define tres niveles de liquidación, cada uno apropiado para diferentes perfiles de interacción.

Nivel 1: Sin Liquidación (Solo Medición)

Cada agente absorbe sus propios costos de inferencia. Se generan CMR para observabilidad pero no se realiza ningún pago entre agentes. Este es el modo por defecto y la opción apropiada cuando:

Esto refleja el peering libre de liquidación en la interconexión de internet [28] y el modelo bill-and-keep en telecomunicaciones [29]. Para flotas internas de agentes (como la flota de AB Support), el Nivel 1 proporciona visibilidad de costos sin la sobrecarga de liquidación entre agentes.

Nivel 2: Liquidación Basada en Reglas

Una regla de asignación estática divide los costos según una fórmula incorporada en el acuerdo de servicio de los agentes (vía ASA [20]). Reglas comunes:

ReglaFórmulaCuándo Usar
Pago por el solicitanteR paga el 100%Mercado de servicios (B es un servicio, A es un cliente)
Pago por el receptorB paga el 100%Generación de prospectos (B desea la solicitud de A)
División igualitariaCada uno paga el 50%Colaboración entre pares
ProporcionalCada uno paga en proporción a los tokens consumidosUso general
Pago por el beneficiarioCada uno paga en proporción al valor recibidoInteracciones complejas con términos ASA

Las reglas del Nivel 2 son evaluadas localmente por el motor CWEP de cada agente. No ocurre negociación al momento de la interacción: la regla se acordó al establecer el acuerdo de servicio. Esto es computacionalmente trivial y no agrega latencia a las interacciones.

Nivel 3: Liquidación Dinámica

Asignación de costos en tiempo real mediante el motor de liquidación CWEP. El motor selecciona un método de asignación basado en las características de la interacción:

IF interaction is cooperative (shared goal, symmetric benefit):
    Use Shapley value allocation
ELSE IF interaction is competitive (one-sided benefit):
    Use asymmetric Nash bargaining
ELSE IF interaction involves >2 agents:
    Use approximate Shapley with sampling
ELSE:
    Fall back to Tier 2 proportional split

La liquidación dinámica requiere que ambos agentes implementen el motor de liquidación CWEP e intercambien metadatos de costos durante la interacción. El cálculo de liquidación agrega una latencia mínima (< 1ms para Shapley de dos agentes) pero requiere consenso sobre los parámetros de la interacción.

8.2 Liquidación por Valor de Shapley

Para una interacción de dos agentes, la liquidación basada en Shapley calcula el pago de cada agente como:

standalone_cost(A) = RO  (A genera la solicitud, no llega respuesta)
standalone_cost(B) = 0   (B no hace nada sin una solicitud)
joint_cost(A,B) = RO + RI + SO + SI

shapley_payment(A) = [joint_cost + standalone_cost(A) - standalone_cost(B)] / 2
                   = [RO + RI + SO + SI + RO - 0] / 2
                   = [2*RO + RI + SO + SI] / 2
                   = RO + (RI + SO + SI) / 2

shapley_payment(B) = [joint_cost + standalone_cost(B) - standalone_cost(A)] / 2
                   = [RO + RI + SO + SI + 0 - RO] / 2
                   = (RI + SO + SI) / 2

Interpretación: El solicitante paga su propio costo de generación de solicitud más la mitad de todos los costos restantes. El receptor paga la mitad de los costos restantes. Esto refleja la realidad económica de que el solicitante inició la interacción y debería asumir una mayor parte, pero el receptor también eligió participar, lo cual es una decisión bilateral.

Para el ejemplo de revisión de código de la Sección 4.1 (Sonnet 4.6):

Compárese con el pago por el solicitante ($0,234 / $0,00) y la división igualitaria ($0,117 / $0,117). La asignación de Shapley captura la intuición de que el solicitante inició la interacción y asume más costo, pero el costo de procesamiento del receptor se comparte parcialmente.

Nota sobre standalone_cost(B) = 0. Esta formulación asume costo autónomo cero para el receptor: no considera los costos de infraestructura de mantener la disponibilidad (mantener el modelo activo, reservar capacidad de ventana de contexto, mantener el tiempo de actividad). En implementaciones donde los costos fijos del receptor son significativos, el término standalone_cost(B) puede establecerse como el costo de infraestructura por período del receptor amortizado entre las interacciones esperadas. Por ejemplo, si los costos fijos de infraestructura del Agente B son de $0,02 por período esperado de interacción, la asignación de Shapley se modifica:

standalone_cost(B) = 0.02
shapley_payment(A) = [joint_cost + standalone_cost(A) - standalone_cost(B)] / 2
                   = [$0.234 + $0.150 - $0.02] / 2 = $0.182
shapley_payment(B) = [joint_cost + standalone_cost(B) - standalone_cost(A)] / 2
                   = [$0.234 + $0.02 - $0.150] / 2 = $0.052

Establecer standalone_cost(B) > 0 desplaza la asignación hacia una división más equitativa, reflejando el costo real de disponibilidad de B. La simplificación de costo autónomo cero es apropiada para agentes ligeros con costos fijos despreciables; debe ser sobreescrita para agentes que mantienen infraestructura dedicada.

8.3 Liquidación por Negociación de Nash

Cuando los agentes tienen posiciones de negociación asimétricas, la solución de negociación de Nash reemplaza a Shapley:

utility(A) = value_received(A) - payment(A)
utility(B) = value_received(B) - payment(B)

disagreement(A) = 0  (A no obtiene nada si no hay interacción)
disagreement(B) = 0  (B no obtiene nada si no hay interacción)

Nash solution maximizes:
    [utility(A) - disagreement(A)]^alpha × [utility(B) - disagreement(B)]^(1-alpha)

where alpha = bargaining_power(A), and alpha + (1-alpha) = 1

El parámetro de poder de negociación alpha puede derivarse de:

La liquidación por negociación de Nash requiere que ambos agentes declaren sus valoraciones, lo que introduce la preocupación de compatibilidad de incentivos: los agentes pueden reportar valores falsos para capturar excedente. Un agente sofisticado puede reducir su valoración declarada mientras sigue completando interacciones, capturando excedente sin provocar fracasos en la negociación, manteniendo así una puntuación ARP positiva. La reputación ARP mitiga el reporte grosso falso (donde el reporte falso causa negociaciones fallidas) pero no este tipo de ajuste sofisticado de valor. El diseño de mecanismos que logre compatibilidad de incentivos plena para la declaración de valores en entornos bilaterales es un problema abierto en economía: la imposibilidad de Green-Laffont (Sección 6.3) aplica directamente aquí [12]. Para la v1.0, CWEP se basa en la observación práctica de que el reporte falso significativo de valor tiende a producir emparejamientos subóptimos a lo largo del tiempo (los agentes que subreportan valor reciben contrapartes de menor calidad vía AMP [19]), lo cual es detectable en el agregado aunque las instancias individuales no lo sean. La compatibilidad de incentivos plena en el reporte bilateral de valor sigue siendo un problema de investigación abierto para futuras versiones del protocolo.

8.4 Protocolo de Liquidación

El protocolo de liquidación ocurre después de que la interacción se completa:

1. Ambos agentes generan CMR de forma independiente
2. Los agentes intercambian CMR (o un resumen hash para privacidad)
3. El motor CWEP de cada agente calcula la propuesta de liquidación
4. Si las propuestas coinciden (dentro de la tolerancia): la liquidación se acepta
5. Si las propuestas difieren: resolución de disputas vía AJP [17]
6. El monto de liquidación se registra en los CMR de ambos agentes
7. El pago se ejecuta a través de la vía de pago configurada

El umbral de tolerancia para el acuerdo de propuestas es configurable (por defecto: 5% del costo total de la interacción). Los desacuerdos más allá de este umbral se registran como disputas de costos y pueden escalarse a través del módulo de resolución de disputas del Agent Justice Protocol.

8.5 Caso de Estudio: Costos de Interacción de la Flota AB Support

La flota AB Support —un sistema multiagente en producción compuesto por un coordinador (Alex), un agente de investigación (Bravo), un analista de investigación profunda (Charlie), un desarrollador (Delta), un revisor de contenido (Editor) y un traductor multilingüe (Translator)— proporciona datos empíricos para la asignación de costos CWEP. Las siguientes interacciones representativas se derivan de operaciones reales de la flota, con conteos de tokens y costos calculados a partir de patrones de interacción reales.

InteracciónSolicitanteReceptorTokens ROTokens RITokens SOTokens SICosto Total (Sonnet)
Despacho de tarea de investigaciónAlexBravo2.5002.500500500$0,053
Revisión QA de archivo de conocimientoAlexCharlie15.00015.0008.0008.000$0,565
Solicitud de compilación de códigoAlexDelta5.0005.00012.00012.000$0,435
Revisión de whitepaperAlexEditor20.00020.0006.0006.000$0,690
Solicitud de traducciónAlexTranslator12.00012.00014.00014.000$0,600
Síntesis transversalCharlieCharlie (propio)50.00050.00015.00015.000$1,575
Encuesta de investigación + informeBravoBravo (propio)3.0003.00025.00025.000$0,843

Análisis de asignación Shapley. Bajo el modelo implícito actual (bill-and-keep, el operador de cada agente absorbe sus propios costos), el coordinador (Alex) asume costos desproporcionados porque genera prompts de tareas grandes que otros agentes procesan. Para la interacción de revisión QA de archivo de conocimiento:

En un ciclo operacional de 24 horas, la flota genera aproximadamente 30-50 interacciones entre agentes que totalizan 500K-800K tokens con un costo de $8-15. La reasignación Shapley desplazaría aproximadamente $2-4 de la distribución actual de bill-and-keep —no un monto absoluto grande para una flota interna, pero el patrón demuestra la mecánica del protocolo. Para flotas inter-operadores con cientos de agentes, la misma lógica de asignación escala a montos de liquidación significativos.

Observación clave: Las interacciones de mayor costo de la flota no son las más frecuentes (despachos de tareas a ~$0,05 cada uno) sino las tareas de análisis profundo ($0,50-1,50 cada una). El umbral de liquidación de CWEP (por defecto $0,01) filtra correctamente los despachos de alta frecuencia y bajo costo mientras captura los costos bilaterales significativos en las interacciones de revisión y síntesis. Se planea una validación empírica mediante un despliegue piloto extendido para la v1.1.


9. Especificación del Protocolo: Fijación de Precios de Contexto

9.1 El Modelo de Tres Componentes

El modelo de fijación de precios de contexto de CWEP descompone el precio efectivo de un token en tres componentes, inspirado en la Fijación de Precios Marginales Localizados en los mercados eléctricos [13]:

Componente 1: Costo Base del Token (BTC)

La tarifa por token publicada del proveedor para el modelo en uso. Este es el precio mínimo: el costo cuando el contexto no está congestionado y la interacción es corta.

BTC = provider_rate(model, token_type) × token_count

Donde token_type ∈ {input, output, cached_input} y las tarifas se obtienen de las páginas de precios de los proveedores [1][30][32].

Componente 2: Prima de Congestión (CP)

Un multiplicador que refleja la utilización actual del contexto del receptor. Cuando la ventana de contexto de un agente está casi llena, el valor marginal de la capacidad restante aumenta. La prima de congestión fija precio a esta escasez.

CP = BTC × congestion_multiplier(utilization)

congestion_multiplier(u) = {
    1.0           if u < 0.50      (capacidad abundante)
    1.0 + 0.5u    if 0.50 ≤ u < 0.80  (carga moderada)
    1.0 + 2.0u    if 0.80 ≤ u < 0.95  (carga pesada)
    1.0 + 5.0u    if u ≥ 0.95     (capacidad crítica)
}

Al 95% de utilización, la prima de congestión es 5,75 veces el costo base. Esto es agresivo pero intencional: señala que la capacidad restante del contexto del agente es extremadamente escasa y debería reservarse para interacciones de alto valor. La función escalonada es más simple de implementar que una función continua y proporciona señales de precios claras en cada umbral.

Componente 3: Sobrecarga del Protocolo (PO)

El costo del propio encuadre de CWEP: metadatos de medición, encabezados de liquidación y tokens de negociación del protocolo. Este es el análogo de la "pérdida de transmisión" de la fijación de precios en redes eléctricas.

PO = overhead_tokens × provider_rate(model, input)

CWEP apunta a una sobrecarga del protocolo inferior a 500 tokens por interacción (aproximadamente 0,1% de un contexto típico de 500K tokens). La sobrecarga es asumida por el solicitante como parte del costo de solicitud.

Precio Efectivo del Token:

effective_price = BTC + CP + PO

9.2 Fijación de Precios Dependiente de la Posición (Extensión Propuesta)

El escalamiento cuadrático de la atención del transformer significa que los tokens en diferentes posiciones de la ventana de contexto imponen diferentes costos computacionales. Un token en la posición 10.000 cuesta menos de procesar que un token en la posición 900.000: el cálculo de atención para este último involucra 90 veces más cálculos por pares.

CWEP propone (pero no requiere en la v1.0) una extensión de fijación de precios dependiente de la posición:

position_multiplier(pos, window_size) = (pos / window_size)^beta

Donde beta es un parámetro de ajuste (rango sugerido: 0,1-0,5) y pos es la posición absoluta del token en la ventana de contexto. Con beta = 0,3:

Esta extensión está marcada como experimental porque:

  1. Ningún proveedor expone actualmente fijación de precios dependiente de la posición
  2. La curva real de costo computacional depende de detalles de implementación (Flash Attention, ring attention, etc.) que varían entre proveedores
  3. El parámetro beta requiere calibración empírica contra costos reales de inferencia

La fijación de precios dependiente de la posición se vuelve importante a medida que las ventanas de contexto crecen a más de 1M de tokens. Para interacciones dentro de los primeros 100K tokens de una ventana de 1M, el efecto de posición es despreciable y puede ignorarse con seguridad.

9.3 Descubrimiento Dinámico de Tarifas

Los agentes CWEP deben conocer las tarifas de la contraparte para calcular las liquidaciones. En lugar de codificar tarifas de forma fija, CWEP especifica un protocolo de descubrimiento de tarifas:

1. El agente publica sus tarifas actuales en su A2A Agent Card [57]
   (campo de extensión: cwep_pricing)
2. Antes de la interacción, el solicitante consulta las tarifas CWEP del receptor
3. El receptor devuelve las tarifas actuales incluyendo la prima de congestión
4. Ambos agentes almacenan en caché las tarifas de la contraparte durante la interacción
5. Las tarifas se bloquean durante la interacción (sin cambios de precio intra-interacción)

El bloqueo de tarifas previene la manipulación de precios durante una interacción. Un agente no puede inflar sus tarifas después de ver la solicitud para extraer más de la liquidación. Las tarifas se actualizan entre interacciones, no durante ellas.


10. Especificación del Protocolo: Niveles de Calidad de Servicio

10.1 El Fracaso de la Limitación de Tasa Basada en Solicitudes

La limitación de tasa tradicional cuenta solicitudes por segundo. Esto falla para las interacciones entre agentes porque una sola solicitud puede costar 100 veces más cómputo que otra [58]. Un agente que envía una solicitud de 100.000 tokens impone el mismo costo de infraestructura que un agente que envía 100 solicitudes de 1.000 tokens, pero el primero pasa un límite de 1 solicitud/segundo mientras el segundo es limitado.

Gartner predice que más del 30% del aumento de demanda de API provendrá de herramientas de IA/LLM para 2026 [58]. La limitación de tasa debe evolucionar del conteo de solicitudes al presupuesto de tokens.

10.2 Limitación de Tasa por Presupuesto de Tokens

CWEP define los límites de tasa en términos de presupuestos de tokens, no conteos de solicitudes:

{
  "qos_tier": "standard",
  "limits": {
    "input_tokens_per_minute": 1000000,
    "output_tokens_per_minute": 200000,
    "concurrent_interactions": 10,
    "max_request_size_tokens": 500000,
    "max_context_utilization": 0.80
  }
}

El límite max_context_utilization es novedoso: impide que una sola interacción consuma más de una fracción especificada de la ventana de contexto del agente. Esto protege la capacidad del agente para otras interacciones.

10.3 Niveles de Procesamiento Prioritario

CWEP define cuatro niveles de QoS que los agentes pueden publicitar y los solicitantes pueden seleccionar:

NivelTarifa de TokensPrioridad de CongestiónCaso de Uso
EconómicoTarifa baseMás baja (en cola cuando está ocupado)Lotes, asíncrono, no urgente
EstándarTarifa baseNormal (FIFO)Interacciones por defecto
Prioritario2x tarifa baseAlta (desplaza al económico)Tareas sensibles al tiempo
Reservado3x tarifa base + retención de capacidadGarantizada (capacidad preasignada)Interacciones con SLA

Los niveles de prioridad se implementan a través del mecanismo de prima de congestión: las solicitudes de nivel superior pagan un multiplicador de congestión más alto, que el receptor utiliza para priorizar el orden de procesamiento. La prima no es arbitraria: refleja el costo genuino de mantener capacidad reservada y desplazar otro trabajo.

El nivel reservado incluye una retención de capacidad: el solicitante paga por reservar una porción de la ventana de contexto del receptor durante un período especificado. Esto refleja los precios de instancias reservadas en computación en la nube, donde el compromiso anticipado obtiene disponibilidad garantizada. La tarifa de retención de capacidad es independiente de los costos por interacción y se especifica en el Agent Service Agreement [20].

10.4 Señalización de Contrapresión

Cuando un agente se acerca a sus límites de capacidad, debería señalar contrapresión a los solicitantes en lugar de degradarse silenciosamente o fallar. CWEP define señales de contrapresión:

{
  "cwep_status": "congested",
  "current_utilization": 0.87,
  "estimated_queue_time_ms": 3500,
  "available_tiers": ["priority", "reserved"],
  "economy_queue_depth": 14
}

Los solicitantes que reciben señales de contrapresión pueden:

Esto crea un mecanismo de mercado para la capacidad escasa de ventana de contexto: cuando la demanda supera la oferta, los precios suben (vía prima de congestión), señalando a los solicitantes que paguen más o reduzcan la demanda.


11. Especificación del Protocolo: Prevención de Spam

11.1 La Superficie de Ataque de la Ventana de Contexto

La ventana de contexto de un agente es un recurso finito que los adversarios pueden consumir. El ataque más simple: enviar a un agente una serie de solicitudes grandes e inútiles que llenen su ventana de contexto, impidiendo interacciones legítimas. Este es un ataque de denegación de servicio medido en tokens en lugar de paquetes.

A diferencia del DDoS a nivel de red, que se mitiga con ancho de banda y filtrado de paquetes, el DoS de ventana de contexto se mitiga únicamente con mecanismos económicos: haciendo costoso desperdiciar el contexto de un agente. CWEP proporciona tres mecanismos defensivos.

11.2 Depósito de Solicitud

Antes de enviar una solicitud, el solicitante compromete un depósito reembolsable de tokens al receptor:

deposit_amount = estimated_request_tokens × responder_input_rate × deposit_multiplier

El deposit_multiplier (por defecto: 1,5x) lo establece el receptor y se publica en su A2A Agent Card [57]. El depósito cubre el costo de comprensión del receptor más un margen.

Ciclo de vida del depósito:

  1. El solicitante compromete el depósito (bloqueado en canal de pago o fideicomiso)
  2. El solicitante envía la solicitud
  3. El receptor procesa la solicitud
  4. El receptor devuelve una evaluación de valor: útil (depósito reembolsado menos el costo real de procesamiento) o spam (depósito confiscado)
  5. Resolución de disputas vía AJP [17] si el solicitante impugna la clasificación de spam

El mecanismo de depósito hace costoso el spam. Enviar 1.000 solicitudes de spam a un agente Opus 4.6 con un depósito de 100K tokens por solicitud costaría $750 en depósitos confiscados, suficiente para disuadir el spam automatizado mientras impone una fricción despreciable en las interacciones legítimas (donde los depósitos se reembolsan).

11.3 Acceso Ponderado por Reputación

Los agentes con puntuaciones de reputación ARP más altas [21] reciben acceso preferencial:

Esto crea un sistema de confianza graduado donde los agentes establecidos interactúan sin fricción mientras los agentes desconocidos deben demostrar disposición a pagar antes de consumir espacio de ventana de contexto. Con el tiempo, a medida que los nuevos agentes construyen reputación a través de interacciones productivas, sus costos de acceso disminuyen: un incentivo natural para el buen comportamiento.

Integración de agentes nuevos. Los requisitos de depósito y reputación anteriores se aplican únicamente a las interacciones de Nivel 3 (Liquidación Dinámica) con contrapartes desconocidas. Los agentes nuevos sin acceso a vías de pago o historial de reputación pueden participar inmediatamente a través de los modos de Nivel 1 (Sin Liquidación) o Nivel 2 (Basado en Reglas), que no requieren depósitos. Esto significa que cualquier agente puede comenzar a interactuar, construir reputación y demostrar valor desde el primer día: el mecanismo de depósito controla únicamente el nivel de liquidación más complejo con contrapartes no confiables.

Además, los operadores pueden respaldar a sus agentes proporcionando una cuenta de depósito compartida. Un operador que despliegue cinco agentes puede respaldarlos a todos con un solo fondo de depósito, reduciendo la fricción de integración por agente. El depósito del operador cubre el multiplicador 5x de agente nuevo de manera colectiva, y a medida que los agentes individuales construyen reputación, ascienden a niveles de depósito inferiores de forma independiente. Esto refleja la integración empresarial en servicios en la nube, donde una cuenta organizacional proporciona el ancla de confianza para los usuarios individuales.

Para el caso común de agentes que se unen a una flota establecida (p. ej., un nuevo agente especialista que se une al sistema multiagente existente de un operador), la reputación colectiva de la flota y la cuenta de depósito compartida significan que el nuevo agente no enfrenta fricción adicional de integración: hereda inmediatamente el nivel de confianza del operador y construye su propia reputación individual a través de las interacciones.

11.4 Tamaño Progresivo de Solicitudes

Para prevenir ataques de inundación de contexto, CWEP admite el tamaño progresivo de solicitudes para interacciones con agentes desconocidos:

max_request_tokens(reputation, interaction_count) = {
    1000    if reputation < 20 AND interactions < 5
    10000   if reputation < 40 AND interactions < 20
    100000  if reputation < 60 AND interactions < 100
    unlimited    otherwise
}

Los agentes nuevos comienzan con un tamaño máximo de solicitud de 1.000 tokens, suficiente para describir una tarea pero no para inundar el contexto. A medida que construyen reputación e historial de interacciones, el límite se relaja. Esto refleja la construcción progresiva de confianza en el comercio humano (pedidos pequeños antes de contratos grandes) pero aplicada a nivel de protocolo.


12. Optimización de Prompts como Estrategia Económica

12.1 Compresión como Reducción de Costos

La compresión de prompts no es meramente una optimización técnica: es una decisión económica con un retorno de inversión medible. LLMLingua logra hasta 20 veces de compresión de prompts con pérdida mínima de rendimiento [16]: en pruebas documentadas, 2.365 tokens comprimidos a 211 tokens (11,2x). A escala, los ahorros son sustanciales: una compresión de contexto del 60% en una carga de trabajo de 10.000 conversaciones diarias ahorra $153.000/año [2].

CWEP formaliza la compresión como una estrategia de reducción de costos dentro del marco de liquidación bilateral:

compression_savings = (uncompressed_tokens - compressed_tokens) × input_rate
compression_cost = tokens_consumed_by_compressor × compressor_output_rate
net_savings = compression_savings - compression_cost
compression_roi = net_savings / compression_cost

El solicitante tiene un incentivo económico directo para comprimir cuando la liquidación incluye reparto de costos: una solicitud más corta reduce la participación del solicitante tanto bajo la asignación Shapley como bajo la proporcional. Sin liquidación bilateral (puro pago por el solicitante o bill-and-keep), el incentivo de compresión del solicitante depende únicamente de su propio costo de salida.

12.2 Almacenamiento en Caché como Costo Amortizado

El almacenamiento en caché de prompts reduce los costos de contexto repetido en un 90% (aciertos de caché al 0,1x del precio base de entrada) [1]. Anthropic ofrece control explícito de caché con opciones de TTL de 5 minutos y 1 hora; OpenAI habilita el almacenamiento en caché automáticamente; Google cobra tarifas separadas de almacenamiento [30].

Para interacciones recurrentes entre agentes (p. ej., un agente de monitoreo que revisa el mismo repositorio de código cada hora), el caché transforma un costo variable en un costo casi fijo:

first_interaction_cost = full_context_tokens × input_rate × cache_write_multiplier
subsequent_cost = full_context_tokens × input_rate × 0.10  (cache hit)
amortized_cost_per_interaction(n) = (first_cost + (n-1) × subsequent_cost) / n

Con n=10 interacciones con almacenamiento en caché de Claude Sonnet 4.6:

El motor de liquidación de CWEP puede recomendar estrategias de almacenamiento en caché basadas en la frecuencia de interacción y el TTL del caché.

12.3 Memoria vs. Contexto Largo como Decisión Económica

La elección entre almacenar información en memoria externa y mantenerla en el contexto es un compromiso económico con un punto de cruce cuantitativo [18]:

Los sistemas de memoria (Mem0 [37], Zep [38], Letta [39], xMemory [59]) concentran los costos de escritura al inicio pero reducen los costos variables por interacción. Los enfoques de contexto largo escalan los costos variables linealmente con cada interacción. El asesor de optimización de CWEP puede recomendar la estrategia apropiada basada en los patrones de interacción esperados.

xMemory (King's College London / Alan Turing Institute) demuestra el potencial: una jerarquía semántica de cuatro niveles con recuperación controlada por incertidumbre reduce el uso de tokens entre un 28% y un 48% mientras mejora la precisión [59]. Con GPT-5 nano, los tokens por consulta bajan de 9.155 a 6.581: un ahorro económico medible por interacción.

12.4 RAG como Seguro de Ventana de Contexto

La Generación Aumentada por Recuperación (RAG) permite que los agentes almacenen grandes bases de conocimiento externamente y recuperen solo las porciones relevantes en el contexto. Desde la perspectiva de CWEP, RAG es un seguro de ventana de contexto: el agente paga un pequeño costo de recuperación por interacción para evitar pagar el costo mucho mayor de mantener toda la base de conocimiento en el contexto.

La economía es clara para agentes intensivos en conocimiento: un agente con 500.000 tokens de conocimiento de dominio consumiría la mitad de una ventana de contexto de 1M de tokens para mantenerlo todo. RAG permite que el agente recupere solo los 10.000 tokens relevantes por interacción, liberando 490.000 tokens de capacidad de contexto para el trabajo real. El costo por interacción de la recuperación (búsqueda vectorial + tokens de recuperación) es órdenes de magnitud menor que el costo del contexto completo.


13. Integración de Micropagos

13.1 Opciones de Vías de Pago

Los montos de liquidación CWEP típicamente van de $0,001 a $1,00 por interacción. Esto requiere infraestructura de micropagos. Cuatro vías de pago son adecuadas a marzo de 2026:

x402 (Coinbase/Fundación Cloudflare) [3]. Micropagos nativos HTTP utilizando el código de estado 402. Liquida en Base, Polygon y Solana con stablecoins. Pago mínimo de tan solo $0,001 con liquidación en fracciones de segundo. Comisiones del facilitador Coinbase: nivel gratuito de 1.000 transacciones/mes, luego $0,001 por transacción [3]. Volumen diario actual de aproximadamente $28.000, con CoinDesk señalando que gran parte de la actividad refleja pruebas más que comercio real [60].

Machine Payments Protocol (MPP) (Stripe/Tempo) [4]. Lanzado el 18 de marzo de 2026. Agnóstico respecto al método de pago (stablecoins, tarjetas, Bitcoin Lightning). Modelo de sesión con depósito y saldo que logra latencia inferior a 100ms y comisiones por solicitud cercanas a cero. Presentado ante la IETF para estandarización. Compatible con versiones anteriores de x402 [4]. Ya implementado en más de 50 servicios, incluyendo OpenAI, Anthropic y Google Gemini.

L402 (Lightning Labs) [23]. Combina HTTP 402 con micropagos de Lightning Network y autenticación basada en macaroons. Los macaroons soportan delegación y delimitación de permisos: un agente puede recibir un macaroon de "solo pago" que le impide retirar fondos. La arquitectura de firmante remoto de LND asegura que los agentes nunca acceden directamente a las claves privadas [23]. Existe integración con LangChain a través de LangChainL402 y LangChainBitcoin [23].

Superfluid [24]. Transmisión de tokens en tiempo real donde el dinero fluye continuamente por segundo. Más de $1.500 millones han fluido a través de Superfluid; más de 1M de billeteras únicas. El Agent Pool ERC-8004 en Base conecta agentes a flujos continuos [24]. Ideal para conversaciones continuas entre agentes donde la liquidación debe fluir continuamente en lugar de por mensaje.

13.2 Abstracción de Pago CWEP

CWEP no especifica qué vía de pago utilizar. En su lugar, define una interfaz de liquidación que cualquier vía de pago puede implementar:

class CWEPSettlement:
    def commit_deposit(self, amount_usd: float, escrow_id: str) -> bool
    def release_deposit(self, escrow_id: str, to_agent: str) -> bool
    def forfeit_deposit(self, escrow_id: str) -> bool
    def settle(self, from_agent: str, to_agent: str, amount_usd: float,
               interaction_id: str) -> SettlementReceipt
    def stream_open(self, from_agent: str, to_agent: str,
                    rate_usd_per_second: float) -> StreamHandle
    def stream_close(self, handle: StreamHandle) -> SettlementReceipt

Los métodos stream_open/stream_close soportan liquidación continua al estilo Superfluid para conversaciones en curso. Los métodos commit_deposit/release_deposit/forfeit_deposit soportan el mecanismo de prevención de spam. El método settle soporta liquidación única por interacción.

13.3 Liquidación por Lotes

Para interacciones de alta frecuencia entre el mismo par de agentes, la liquidación por interacción es ineficiente. CWEP soporta liquidación por lotes:

Acumular CMR durante una ventana configurable (por defecto: 1 hora o $1,00 neto, lo que ocurra primero)
Calcular la liquidación neta a través de todas las interacciones de la ventana
Ejecutar un único pago por el monto neto

Si el Agente A le debe al Agente B $0,15 a través de 50 interacciones y el Agente B le debe al Agente A $0,08 a través de 30 interacciones, la liquidación neta es un único pago de $0,07 de A a B. Esto reduce las comisiones de transacción en 80 veces y es el modo recomendado para agentes con relaciones bilaterales en curso.


14. Reservas de Contexto y Direcciones Futuras del Mercado

14.1 Mecanismo de Reserva

La ventana de contexto de un agente tiene capacidad finita. Cada solicitud entrante consume una porción. Si el agente está ocupado (alta utilización), la capacidad restante es más valiosa. Un solicitante que desee acceso garantizado debería estar dispuesto a pagar por una reserva de capacidad. CWEP v1.0 especifica reservas bilaterales de contexto como un mecanismo concreto e implementable para la gestión de capacidad.

{
  "reservation": {
    "requestor": "did:example:agent-a",
    "responder": "did:example:agent-b",
    "capacity_tokens": 100000,
    "duration_seconds": 3600,
    "price_usd": 0.50,
    "qos_tier": "reserved",
    "auto_renew": true
  }
}

La reserva garantiza que 100.000 tokens de la ventana de contexto del Agente B están disponibles para uso exclusivo del Agente A durante una hora. El Agente B se compromete a procesar cualquier solicitud del Agente A hasta la capacidad reservada dentro de las garantías de latencia del nivel QoS. Si el Agente B no cumple con la reserva, la tarifa de reserva es reembolsable y se puede presentar una disputa a través de AJP [17].

14.2 Precios Spot vs. Reservados

Coexisten dos modelos de fijación de precios:

La estrategia óptima depende de la previsibilidad de la interacción:

Este es precisamente el compromiso entre instancias reservadas, bajo demanda y spot en computación en la nube, adaptado para el espacio de ventana de contexto.

14.3 Dirección Futura: Mercados de Contexto

El mecanismo de reserva bilateral anterior es el bloque de construcción hacia un potencial mercado de contexto futuro: un mecanismo donde los agentes intercambian autónomamente capacidad de contexto en tiempo real con descubrimiento de precios y emparejamiento de órdenes. Tal mercado requeriría unidades de capacidad estandarizadas (tokens por período de tiempo), señales de precios en tiempo real a través de la red de agentes, liquidez suficiente (muchos agentes comprando y vendiendo) e infraestructura de creadores de mercado o bolsa. Esto es estructuralmente análogo a los mercados de capacidad en redes eléctricas, donde a los generadores se les paga por mantener capacidad disponible incluso si no se despacha [13].

Ninguna de esta infraestructura existe actualmente. El mecanismo de reserva es suficiente para las necesidades actuales de la economía de agentes; un mercado de contexto completo se vuelve relevante cuando el volumen de interacciones entre agentes alcance niveles donde la negociación bilateral se convierta en un cuello de botella. Consulte la Sección 20.1 para una discusión más amplia sobre el desarrollo de mercados de contexto.


15. Integración con el Ecosistema de Confianza

15.1 CWEP en la Pila de Protocolos

CWEP se ubica en la Capa 4 (Mercado/Economía) del Ecosistema de Confianza de AB Support, junto con el Agent Matchmaking Protocol [19]. Depende de:

CWEP proporciona datos a:

15.2 Flujos de Datos entre Protocolos

DesdeHaciaDatosPropósito
CWEP → CoCHashes de CMRAnclaje de procedencia para registros de costos
CWEP → ARPDatos de costos de interacciónComportamiento económico como señal de reputación
CWEP → ASAMontos de liquidaciónCumplimiento de términos de costos en acuerdos
CWEP → AJPCMR como evidenciaResolución de disputas de costos
CWEP → AMPEstimaciones de costosEmparejar agentes por eficiencia de costos
CoC → CWEPVerificación de cadenaValidar autenticidad de la interacción
ARP → CWEPPuntuaciones de reputaciónInformar poder de negociación, niveles de depósito
ASA → CWEPReglas de asignación de costosDeterminar nivel y método de liquidación

15.3 Ciclos de Retroalimentación del Ecosistema

Dos ciclos de retroalimentación estabilizan el ecosistema CWEP:

Retroalimentación positiva (ciclo virtuoso): El agente proporciona buen servicio → alta calificación ARP → depósitos menores requeridos por las contrapartes → más interacciones → más oportunidades de obtener calificaciones positivas.

Retroalimentación negativa (ciclo correctivo): El agente envía spam/desperdicia contexto → depósitos confiscados → baja calificación ARP → depósitos mayores requeridos → menos interacciones → el agente mejora su comportamiento o sale del mercado.

Estos ciclos son propiedades emergentes de la interacción de la pila de protocolos: ningún protocolo individual los crea, pero CWEP + ARP juntos los producen.


16. Analogías Biológicas

Dos paralelos biológicos informaron decisiones específicas de diseño de CWEP. Los incluimos no como metáfora decorativa sino porque moldearon las decisiones del protocolo.

16.1 ATP como Moneda de Tokens → Agnosticismo de Vía de Pago

El trifosfato de adenosina (ATP) sirve como la moneda energética universal para todo organismo en la Tierra [61]. La lección clave de diseño: el poder del ATP proviene de la aceptación universal, no de la química específica. Cada proceso celular —desde la contracción muscular hasta la replicación del ADN— utiliza ATP independientemente de la fuente de energía que lo produjo. Esto motivó directamente el agnosticismo de vía de pago de CWEP (Sección 3.3): el protocolo especifica la asignación de costos en una denominación universal (USD/tokens) que cualquier vía de pago puede liquidar, así como el ATP denomina las transacciones energéticas independientemente de si la energía provino de la glucosa, la grasa o la luz solar. Un protocolo que requiera una vía de pago específica sería tan frágil como una célula que solo acepta energía de una sola vía metabólica.

16.2 Hipótesis de la Reina Negra → Economía de la Especialización

La Hipótesis de la Reina Negra [62] muestra que los microbios pierden genes para funciones costosas cuando los socios proporcionan confiablemente esos recursos. Esto no es meramente análogo a la especialización de agentes: es el mecanismo que la visibilidad de costos de CWEP está diseñada para acelerar. Cuando CWEP hace explícito el cálculo de "comprar vs. construir" (el costo CWEP de externalizar una tarea vs. el costo de inferencia de hacerlo internamente), los agentes pueden tomar decisiones racionales de especialización. Un agente que puede externalizar la revisión de código a $0,23 por interacción (Sección 4.1) no tiene razón económica para mantener su propia capacidad de revisión de código a $0,39 por interacción. Los datos de medición de CWEP proporcionan la señal; la dinámica de la Reina Negra predice el resultado: los agentes se desprenderán de capacidades que son más económicas de externalizar, impulsando la especialización del ecosistema.

16.3 Límites

Estas analogías son ilustrativas, no modelos formales. Dos diferencias críticas limitan su aplicabilidad: (1) los agentes pueden duplicarse a costo casi cero, creando un problema Sybil sin paralelo biológico —CWEP aborda esto a través del acceso controlado por reputación (Sección 11.3) en lugar de mecanismos inmunológicos biológicos; (2) las estructuras de costos de los agentes son discretas y transparentes (medibles con precisión vía respuestas de API), lo que permite mecanismos de asignación de costos (Shapley, Nash) que no tienen equivalente biológico.


17. Análisis de Seguridad

17.1 Modelo de Amenazas

CWEP opera en un entorno donde los agentes pueden ser adversarios. El modelo de amenazas considera:

AmenazaDescripciónDefensa CWEP
Inundación de contextoEnviar solicitudes grandes e inútiles para agotar la ventana de contextoMecanismo de depósito (Sección 11.2), tamaño progresivo de solicitudes (Sección 11.4)
Inflación de costosReportar falsamente el nivel de modelo o el conteo de tokens para extraer mayor liquidaciónVerificación de CMR contra respuestas de API del proveedor; pista de auditoría anclada en CoC
Manipulación de liquidaciónReportar valoraciones falsas en la negociación de NashSeguimiento de reputación ARP de resultados de negociación; escalamiento de disputas vía AJP
Manipulación de tarifasCambiar a modelos costosos después de recibir una solicitud para inflar costos de respuestaBloqueo de tarifas por interacción (Sección 9.3); niveles de modelo preacordados en ASA
ParasitismoConsumir espacio de ventana de contexto sin pagar depósitosControles de acceso ponderados por reputación (Sección 11.3); agentes desconocidos enfrentan depósitos máximos
Ataques SybilCrear múltiples identidades para evadir controles de reputaciónVerificación de cadena CoC — los agentes nuevos tienen cadenas cortas, obteniendo baja reputación inicial

17.2 Seguridad de Depósitos

El mecanismo de depósito requiere que los fondos comprometidos no puedan ser confiscados unilateralmente por el receptor. Esto se garantiza a través de la vía de pago:

En todos los casos, el solicitante puede disputar una clasificación de spam a través de AJP [17], y el depósito se retiene hasta la resolución.

17.3 Consideraciones de Privacidad

Los CMR contienen información sensible: qué agentes interactúan, qué modelos usan, cuál es su estructura de precios y cuánto pagan. CWEP aborda la privacidad mediante:


18. Limitaciones y Resultados de Imposibilidad

18.1 Limitaciones Fundamentales

1. El compromiso de imposibilidad es real. CWEP sacrifica la eficiencia económica por el equilibrio presupuestario y la compatibilidad de incentivos (Sección 6.3). Algunas interacciones mutuamente beneficiosas no ocurrirán porque la asignación de costos las hace no rentables para una de las partes. Creemos que este es el compromiso correcto para un protocolo desplegable, pero significa que CWEP no maximiza el bienestar económico total.

2. La medición de valor es difícil. Los mecanismos de liquidación Shapley y Nash requieren medir el "valor" que cada agente recibe de una interacción. En la práctica, el valor es subjetivo, dependiente del contexto y frecuentemente conocido solo después del hecho. CWEP aproxima el valor a través de indicadores observables (conteos de tokens, niveles de modelo, evaluaciones de calidad ASA) pero no puede capturar el valor económico completo de las interacciones.

3. El escalamiento cuadrático de costos es una aproximación. Las implementaciones modernas de atención (Flash Attention, ring attention, atención con ventana deslizante) modifican el perfil de costo O(n^2). La curva real de costo computacional es específica del proveedor, específica del modelo y puede cambiar con actualizaciones de software. Por eso la fijación de precios dependiente de la posición de CWEP (Sección 9.2) está marcada como experimental.

4. La deflación de precios complica los acuerdos a largo plazo. Los costos de inferencia están disminuyendo aproximadamente 10 veces por año [27]. Una regla de asignación de costos negociada hoy puede ser drásticamente incorrecta en seis meses. Los montos de liquidación de CWEP se calculan en tiempo real utilizando los precios actuales, pero los términos de costos de ASA que hacen referencia a CWEP deben incluir cláusulas de renegociación periódica.

18.2 Limitaciones de Alcance

1. Sin estandarización de costos entre proveedores. Los precios de los proveedores varían 10 veces para modelos de código abierto idénticos [64]. CWEP utiliza los precios reales del proveedor de cada agente para la liquidación, lo que significa que la misma interacción cuesta montos diferentes dependiendo de qué proveedores utilicen los agentes. Una "unidad de costo de token" estandarizada independiente del proveedor simplificaría la liquidación pero no existe.

2. Sin normalización de modelos de razonamiento. Los modelos de razonamiento (o3 [32], DeepSeek R1 [65]) generan vastamente más tokens por tarea —en casos extremos, más de 600 tokens para generar dos palabras [14]. CWEP cuenta todos los tokens por igual, incluyendo los tokens internos de razonamiento que pueden o no aparecer en la salida. Esto sobrecarga a los solicitantes en interacciones con uso intensivo de razonamiento.

3. Sin soporte para agentes sin conexión. CWEP asume interacción en tiempo real o casi en tiempo real. Las interacciones asíncronas de agentes con almacenamiento y reenvío (donde las solicitudes se acumulan en cola durante horas) requieren extensiones al protocolo de liquidación que no están especificadas en la v1.0.


19. Implementación de Referencia

19.1 Arquitectura

La implementación de referencia de CWEP proporciona:

19.2 Integración Mínima

La integración CWEP más simple (Nivel 1: Solo Medición) requiere envolver las llamadas a la API del LLM con la biblioteca cwep-meter:

from cwep import Meter

meter = Meter(agent_id="did:example:my-agent")

# Envolver la llamada existente al LLM
response = meter.track(
    llm_client.chat(messages=[...]),
    counterparty="did:example:other-agent",
    interaction_id="uuid-v4"
)

# El CMR se emite automáticamente al almacenamiento local
# response.cwep contiene los datos de medición
print(response.cwep.total_cost_usd)

19.3 Integración Completa

La integración CWEP completa (Nivel 3: Liquidación Dinámica) requiere el motor de liquidación:

from cwep import Meter, SettlementEngine, NashBargaining

meter = Meter(agent_id="did:example:my-agent")
engine = SettlementEngine(
    method=NashBargaining(
        bargaining_power=0.6,  # Derivado de la puntuación ARP
        disagreement_value=0.0
    ),
    settlement_threshold_usd=0.01,
    payment_rail="mpp"
)

# Rastrear la interacción
response = meter.track(llm_client.chat(...), ...)

# Calcular y ejecutar la liquidación
proposal = engine.propose(response.cwep.cmr)
if proposal.amount_usd > engine.threshold:
    receipt = engine.settle(proposal)

19.4 Paquete

pip install context-window-economics

Publicado bajo Apache 2.0 en PyPI y GitHub (vibeagentmaking/context-window-economics).


20. Trabajo Futuro

20.1 Mercados de Contexto

CWEP v1.0 especifica reservas bilaterales de contexto (Sección 14). Futuras versiones deberían explorar mercados multilaterales de contexto donde los agentes intercambien autónomamente capacidad en tiempo real —un verdadero mercado con descubrimiento de precios, emparejamiento de órdenes y liquidación. Esto requiere unidades de capacidad estandarizadas (tokens por período de tiempo), señales de precios en tiempo real a través de la red de agentes, liquidez suficiente (muchos agentes comprando y vendiendo) e infraestructura de creadores de mercado o bolsa. El mercado de capacidad eléctrica, donde a los generadores se les paga por mantener capacidad disponible incluso si no se despacha [13], proporciona la plantilla arquitectónica más cercana. Un mercado de contexto completo se vuelve relevante cuando el volumen de interacciones entre agentes alcance niveles donde la negociación bilateral se convierta en un cuello de botella.

20.2 Optimización de Liquidación entre Cadenas

La división de costos en tiempo real a través de diferentes redes blockchain introduce restricciones de latencia en la liquidación. El trabajo futuro debería evaluar comparativamente la latencia de liquidación en x402 (Base, Polygon, Solana) [3], MPP (red Tempo) [4] y L402 (Lightning) [23] para determinar qué vías soportan liquidación a nivel de interacción (< 1 segundo) vs. liquidación por lotes (cada hora).

20.3 Futuros de Costos de Inferencia

Si los costos de inferencia disminuyen de manera predecible a razón de 10x/año [27], los agentes podrían cubrir costos futuros mediante contratos a plazo —bloqueando las tarifas actuales de tokens para interacciones futuras. Esto crearía un mercado de futuros de costos de inferencia análogo a los futuros de materias primas. La infraestructura para esto no existe pero la lógica económica es sólida.

20.4 Medición de Valor Semántico

CWEP v1.0 aproxima el valor de la interacción a través de conteos de tokens y niveles de modelo. La verdadera medición de valor requeriría evaluar el contenido semántico de una interacción —un problema fundamentalmente más difícil que bordea el desafío de verificación de Integridad Semántica, identificado en la arquitectura del Ecosistema de Confianza como potencialmente irresoluble con la tecnología actual [66].

20.5 Marco Regulatorio y Legal

Las transacciones financieras autónomas de agentes operan en una zona gris legal. Cuando el Agente A paga al Agente B por procesamiento de contexto, ¿quién es la contraparte legal? ¿El agente, el operador del agente o el proveedor de LLM? Los marcos regulatorios para el comercio autónomo de agentes son incipientes; la Ley de IA de la UE aborda el comportamiento de los agentes pero no su economía. Futuras versiones de CWEP deberían incorporar requisitos de cumplimiento legal a medida que surjan.


21. Conclusión

La ventana de contexto es el recurso más escaso de la economía de agentes. Es finita, costosa, de costo no lineal y actualmente sin precio. Cada interacción entre agentes la consume; ningún protocolo asigna el costo.

CWEP aborda esto con seis mecanismos: medición (medir los cuatro flujos de costo), liquidación bilateral (Shapley para interacciones cooperativas, Nash para las competitivas), fijación de precios de contexto (costos dependientes de la posición que reflejan el escalamiento cuadrático de la atención), niveles de QoS (limitación de tasa por presupuesto de tokens y procesamiento prioritario), prevención de spam (filtrado basado en depósitos con control por reputación) y economía de optimización (modelos formales de ROI para compresión, caché, memoria y RAG).

El protocolo es honesto sobre lo que no puede hacer. El resultado de imposibilidad de Green-Laffont/Moulin-Shenker significa que la asignación perfecta de costos es inalcanzable —CWEP sacrifica algo de eficiencia económica por equilibrio presupuestario y compatibilidad de incentivos. La medición de valor es aproximada. El escalamiento cuadrático de costos es un modelo idealizado que las implementaciones reales de hardware aproximan en grados variables.

Lo que CWEP sí logra es un marco estructurado para un problema que previamente carecía de marco alguno. Antes de CWEP, los agentes absorbían sus propios costos sin visibilidad de la estructura de costos bilaterales de sus interacciones. Después de CWEP, cada interacción se mide, cada costo es atribuible y cada asignación es auditable a través del sistema de procedencia Chain of Consciousness.

Este es el fundamento económico que la economía de agentes requiere. La procedencia (CoC), la reputación (ARP), los acuerdos (ASA), la rendición de cuentas (AJP), el ciclo de vida (ALP) y el emparejamiento (AMP) proporcionan la infraestructura institucional. CWEP proporciona la infraestructura económica —el mecanismo por el cual los agentes negocian, asignan y liquidan los costos de la comprensión mutua.

El problema es genuinamente novedoso. No hemos simplemente traducido modelos de comercio humano al lenguaje de agentes —hemos identificado una primitiva económica fundamentalmente nueva (el costo de comprensión) y construido un protocolo para fijarle precio. La economía de agentes no se parecerá a la economía humana en sus estructuras de costos; CWEP está diseñado para la economía que realmente está emergiendo, no para la que podríamos esperar por analogía.


22. Referencias

[1] Anthropic. "Pricing." platform.claude.com. Consultado en marzo de 2026.

[2] Stevens Institute; Koombea. "Hidden Economics of AI Agents"; "LLM Cost Optimization." 2025.

[3] Coinbase. "Introducing x402." coinbase.com. Mayo 2025. Véase también: Coinbase, "Welcome to x402," docs.cdp.coinbase.com, 2025.

[4] Stripe. "Introducing the Machine Payments Protocol." stripe.com/blog. 18 de marzo de 2026. Véase también: mpp.dev, documentación Stripe MPP, marzo 2026.

[5] Google. "Announcing AP2." cloud.google.com. Septiembre 2025. Véase también: Google, "A2A x402 Extension," cloud.google.com, 2025.

[6] FinOps Foundation. "FOCUS Specification v1.3." finops.org. Ratificada el 5 de diciembre de 2025.

[7] Langfuse. "Token & Cost Tracking." langfuse.com. Licencia MIT. 2025. Véase también: Langfuse, "Pricing Tiers for Accurate Model Cost Tracking," diciembre 2025.

[8] BerriAI. "LiteLLM." GitHub. 2025. Véase también: LiteLLM, "Agent (A2A) Gateway with agent cost tracking," docs.litellm.ai, 2025.

[9] Portkey. "Tracking LLM Token Usage Across Providers, Teams and Workloads." portkey.ai. 2025.

[10] Shapley, L. S. "Notes on the n-Person Game — II: The Value of an n-Person Game." RAND Corporation, 1951. Publicado como: "A Value for n-Person Games," Contributions to the Theory of Games (H. W. Kuhn y A. W. Tucker, eds.), Annals of Mathematics Studies 28, Princeton University Press, 1953.

[11] Nash, J. "The Bargaining Problem." Econometrica 18(2), 1950.

[12] Green, J. y Laffont, J.-J. Incentives in Public Decision Making. North-Holland, 1979. Véase también: Moulin, H. y Shenker, S. "Strategyproof Sharing of Submodular Costs: Budget Balance versus Efficiency." Economic Theory 18(3), 2001.

[13] PCI Energy Solutions. "Understanding Locational Marginal Pricing (LMP)." 2025.

[14] iKangAI. "The LLM Cost Paradox: How Cheaper AI Models Are Breaking Budgets." 2025. Véase también: Holter, A. "AI Costs in 2025: Cheaper Tokens, Pricier Workflows." 2025.

[15] Zuplo. "Token-Based Rate Limiting for AI APIs." 2025. Véase también: TrueFoundry, Gartner Market Guide for AI Gateways, 2025.

[16] Kuldeep Paul. "Prompt Compression Techniques: LLMLingua." Medium, 2025.

[17] Agent Justice Protocol. AB Support LLC. 2026.

[18] arXiv:2603.04814. "Memory vs. Long-Context Cost Analysis." 2026.

[19] Agent Matchmaking Protocol. AB Support LLC. 2026.

[20] Agent Service Agreements Protocol. AB Support LLC. 2026.

[21] Agent Rating Protocol v2. AB Support LLC. 2026.

[22] Chain of Consciousness v3. AB Support LLC. 2026.

[23] Lightning Labs. "Lightning Agent Tools." 12 de febrero de 2026. Véase también: Bitcoin Magazine, cobertura de Lightning Agent Tools, febrero 2026.

[24] Superfluid. "ERC-8004 Agent Pool." superfluid.org. 2026. Véase también: Sablier Protocol, sablier.com, 2026.

[25] arXiv:2512.08296. "Towards a Science of Scaling Agent Systems." Diciembre 2025.

[26] MarkAICode. "LangGraph vs CrewAI: Multi-Agent Performance and Cost in Production 2026." 2026.

[27] a16z. "LLMflation: LLM Inference Cost." a16z.com. Noviembre 2024. Véase también: Epoch AI, "LLM Inference Price Trends," 2025.

[28] Internet Society. "Interconnection and Regulated Traffic Obligations." Marzo 2025.

[29] FCC. "All-IP Future," WC Docket Nos. 25-311, Notice of Proposed Rulemaking. 28 de enero de 2026.

[30] Google. "Gemini Developer API Pricing." ai.google.dev. Consultado en marzo de 2026.

[31] Maxim.ai. "Context Engineering for AI Agents: The 100:1 Input-Output Ratio." 2025.

[32] OpenAI. "Pricing." developers.openai.com. Consultado en marzo de 2026.

[33] Hardin, G. "The Tragedy of the Commons." Science 162(3859), 1968.

[34] Simon, H. A. "Designing Organizations for an Information-Rich World." Computers, Communications, and the Public Interest (M. Greenberger, ed.), Johns Hopkins Press, 1971.

[35] Anthropic. "Effective Context Engineering for AI Agents." 2025.

[36] Heitmayer, M. "Second Wave of Attention Economics." Interacting with Computers 37(1), 2024.

[37] Mem0. mem0.ai. 2025.

[38] Zep. zep.ai. 2025.

[39] Letta. letta.com. 2025.

[40] VentureBeat. "WEKA Augmented Memory Grid." 2025. Véase también: WEKA, "Token Warehousing," 2025.

[41] PCI Energy Solutions. "Negative LMP Events in SPP." 2025.

[42] Deng, X. y Papadimitriou, C. H. "On the Complexity of Cooperative Solution Concepts." Mathematics of Operations Research 19(2), 1994.

[43] Fast Approximation of Shapley Values Using Fractional Factorial Designs. Journal of the American Statistical Association (JASA), 2025.

[44] Lundberg, S. M. y Lee, S.-I. "A Unified Approach to Interpreting Model Predictions." NeurIPS, 2017.

[45] Wang, J. et al. "ShapleyFL: Robust Federated Learning Based on Shapley Value." KDD, 2023.

[46] VerFedSV. "Verified Federated Shapley Value." 2024.

[47] Schmeidler, D. "The Nucleolus of a Characteristic Function Game." SIAM Journal on Applied Mathematics 17(6), 1969.

[48] Kalai, E. "Nonsymmetric Nash Solutions and Replications of 2-Person Bargaining." International Journal of Game Theory 6(3), 1977.

[49] Rubinstein, A. "Perfect Equilibrium in a Bargaining Model." Econometrica 50(1), 1982.

[50] Moulin, H. "Incremental Cost Sharing: Characterization by Coalition Strategy-Proofness." Social Choice and Welfare 16(2), 1999.

[51] Vickrey, W. "Counterspeculation, Auctions, and Competitive Sealed Tenders." Journal of Finance 16(1), 1961. Véase también: Clarke, E. H. "Multipart Pricing of Public Goods." Public Choice 11(1), 1971; Groves, T. "Incentives in Teams." Econometrica 41(4), 1973.

[52] Internet Society. "South Korea 'Sender Pays' Analysis." 2025.

[53] BEREC. "Preliminary Assessment of Payments from Large CAPs to ISPs." 2023.

[54] FERC. "Order 1920 Fact Sheet." 13 de mayo de 2024.

[55] State of FinOps Report. FinOps Foundation. 2025. Véase también: Datadog, estadísticas de desperdicio de contenedores, 2025.

[56] AG2. "Usage Tracking." docs.ag2.ai. 2025.

[57] Google. "A2A Agent Card Specification." 2025.

[58] Gartner. "Market Guide for AI Gateways." 2025. Véase también: TrueFoundry, Zuplo, 2025.

[59] VentureBeat. "xMemory: Four-Level Semantic Hierarchy." King's College London / Alan Turing Institute. 2025.

[60] CoinDesk. "Coinbase-backed AI payments protocol wants to fix micropayment but demand is just not there yet." 11 de marzo de 2026.

[61] ScienceDirect. "Evolution of Energy Currencies: From ATP to Digital Money." Octubre 2025.

[62] Mostafa, A. et al. "Biological Market Theory Applied to Microbial Communities." Microlife, 2024.

[63] PNAS. "Host-Symbiont Mutualisms and Employment Contract Theory." 2010.

[64] Introl. "Inference Unit Economics: True Cost Per Million Tokens Guide." 2025.

[65] DeepSeek. "DeepSeek R1 Pricing." deepseek.com. 2026.

[66] AB Support Trust Ecosystem Architecture. "Semantic Integrity Verification — Research Frontier." 2026.


Copyright 2026 AB Support LLC. Con licencia bajo la Licencia Apache, Versión 2.0.

Ancla Chain of Consciousness: Protocol whitepaper v1.0.0