Qué ocurre cuando los agentes IA se niegan a trabajar hasta que les pagan

Por Unladen Swallow (blog de Olivier Wulveryck) · 25 de junio de 2026.

**El problema: agentes IA aislados en los portátiles de los desarrolladores**

Olivier Wulveryck abre su artículo con una provocación directa al consenso actual: dar a cada desarrollador un potente agente IA local parece la máxima palanca de productividad, pero para organizaciones que operan a escala es, en realidad, una trampa de gobernanza y costes esperando a dispararse. El autor define con precisión qué significa escalar el SDLC con IA: llevar el desarrollo asistido por inteligencia artificial a N equipos trabajando sobre M productos, donde tanto N como M son superiores a 10. No se trata de la dinámica interna de un único equipo, sino de organizaciones verdaderamente multiproducto.

El modelo actual, según Wulveryck, es el de bucles agénticos monolíticos y aislados. Herramientas como GitHub Copilot o Claude corren en el contexto del desarrollador individual, sin visibilidad centralizada, sin routing inteligente de modelos y sin ningún mecanismo de compensación entre equipos. Eso funciona para un equipo pequeño, pero a escala genera tres problemas estructurales que el autor desarrolla en detalle.

**Problema 1: Deriva arquitectónica garantizada estadísticamente**

El primer problema es de naturaleza matemática. Los LLM son probabilísticos: cualquier directiva de empresa —una decisión de arquitectura, una regla de cumplimiento GDPR, un estándar de seguridad— solo se respeta un porcentaje del tiempo. Si ese porcentaje de fallo es del 10 % y se escala a más de diez equipos ejecutando miles de iteraciones, la organización tiene la certeza estadística de que algún equipo acabará enviando código que incumple las reglas globales. Wulveryck llama a esto 'deriva arquitectónica masiva'.

Se pueden construir guardarraíles deterministas mediante hooks y programas de validación, argumenta el autor, pero si esos mecanismos se ejecutan localmente en los portátiles de los desarrolladores, se pierde la observabilidad centralizada. El CTO o el Principal Engineer es en última instancia responsable del software de la organización; no puede conformarse con 'confiar en el equipo', necesita garantías sistémicas. ¿Cómo puede un CTO certificar con confianza lo que se despliega cuando los mecanismos de aplicación están dispersos e invisibles?

**Problema 2: Escalado lineal de costes sin control**

Cuando los agentes IA operan en local, la organización pierde el control sobre el modelo de ejecución. Los desarrolladores quedan atrapados en un enfoque único: una tarea concreta puede funcionar perfectamente en un LLM de gama media pero fallar en uno de bajo coste, y herramientas como Copilot o Claude no ofrecen ninguna forma sencilla de enrutar dinámicamente las peticiones al modelo más rentable según la complejidad de la tarea. En consecuencia, la organización paga una prima por cada llamada que realizan los agentes locales. Sin cacheo centralizado ni routing inteligente de modelos, ese coste escala linealmente con el número de desarrolladores y de iteraciones, convirtiéndose rápidamente en un gasto desorbitado.

**Problema 3: La economía interna sin respuesta**

El tercer problema es financiero y organizativo. Si un desarrollador construye una habilidad IA altamente efectiva que más tarde adoptan múltiples equipos, ¿quién absorbe los costes de ejecución? El modelo descentralizado no da ninguna respuesta. Se necesita un mecanismo para rastrear el uso con precisión y gestionar cargos cruzados entre equipos ('chargebacks'), compensando así a los equipos que construyen estos activos organizativos compartidos.

**La solución: la plataforma agéntica centralizada**

Para resolver estos tres desafíos, Wulveryck propone pasar de cajas negras locales a servicios centralizados. Una plataforma agéntica real debería gestionar las consultas IA de forma dinámica —optimizando modelos y utilizando caché para controlar los costes a escala—, mantener un libro de contabilidad financiero para los chargebacks entre equipos, y disponer de un registro de auditoría para garantizar el cumplimiento arquitectónico.

El resto del artículo es una demostración paso a paso de cómo podría funcionar esta arquitectura, apoyándose en dos estándares open source: el protocolo Agent-2-Agent (A2A) para orquestación y gobernanza, y el Agent Payment Protocol (AP2) para gestionar la economía interna.

**El escenario: Winston, el arquitecto local**

Para hacer la demostración concreta, Wulveryck plantea un caso de uso: un Product Manager o Tech Lead en un equipo stream-aligned necesita diseñar una nueva funcionalidad. Recurre a su agente IA local, 'Winston' (un personaje que los usuarios del framework BMAD ya conocen), para diseñar la implementación. El prompt de partida es simple: 'Para esta funcionalidad, necesitamos enviar 50.000 emails transaccionales al día'.

Winston corre completamente en local. Es inteligente, conoce los principios generales de arquitectura software y tiene guardarraíles para escalar problemas críticos de cumplimiento como GDPR. Pero opera en un silo: tiene un punto ciego enorme respecto al contexto empresarial y cero conocimiento de los componentes internos ya existentes en la organización.

**La consulta al Enterprise Architecture Service via A2A**

Winston entiende los requisitos técnicos pero está ciego al ecosistema existente. Para salvar esa brecha, debe recurrir a la plataforma centralizada: el Enterprise Architecture Service, que actúa como el cerebro de la organización para estándares, blueprints y bloques reutilizables. Este servicio está completamente automatizado, gestionado por un agente IA centralizado y altamente optimizado.

Los agentes no se comunican con prompts humanos entre sí; lo hacen mediante el protocolo A2A (Agent-to-Agent), una forma estandarizada de consultar tareas e intercambiar estados. Winston envuelve la petición en un mensaje A2A con un campo ceiling_credits de 1.000 créditos y lo envía al Architect Agent.

**El HTTP 402: el agente se niega a trabajar sin pago**

Aquí reside el corazón del artículo y el gancho del titular. La inteligencia centralizada no es gratuita: como cualquier producto interno, requiere recursos para operar. Antes de procesar la solicitud, el Architect Agent evalúa el coste computacional. Al no encontrar ninguna prueba de pago en el mensaje entrante, detiene la solicitud en la pasarela de pago.

El Architect Agent pide a su propio LLM que estime el coste en tokens, genera un payment_ctx_id único y responde con una tarea A2A en estado 'input-required'. Wulveryck lo describe como un '402 Payment Required' agéntico. El payload incluye: ceiling_amount de 800 créditos, price_per_token de 1, task_type 'architecture-consultation', currency 'CREDITS', el payee (la cuenta del arquitecto), la URL del payment agent y el payment_ctx_id.

**Escalado del pago con supervisión humana**

Winston parsea el estado input-required y el bloque de datos de pago. Evalúa isPaymentRequired(task) como verdadero. Pero Winston no está programado para gastar el presupuesto del equipo a ciegas: carece de autonomía para autorizar transacciones financieras por sí solo, por lo que escala la solicitud al humano.

El humano revisa el presupuesto y valida la transacción con un límite estricto: la autorización solo cubre esos créditos para esa tarea específica. Wulveryck apunta que en el futuro se podría implementar un mecanismo de aprendizaje que permita a Winston aprobar automáticamente el gasto para tareas rutinarias o de confianza, sin intervención humana.

**El Agent Payment Protocol (AP2) y los mandatos criptográficos**

Con la aprobación humana asegurada, Winston inicia el protocolo AP2. AP2 es un estándar abierto diseñado para que los agentes IA ejecuten transacciones de forma autónoma y segura. En lugar de depender de que un humano haga clic en un botón de 'pagar', AP2 utiliza Mandates (mandatos) firmados criptográficamente. Cuando un usuario establece un presupuesto o aprueba un presupuesto de coste, genera un mandato que otorga al agente una autoridad verificable y estrictamente acotada para gastar.

El flujo AP2 funciona así:

1. **Checkout mandate**: Winston crea y sella un mandato de checkout. En el comercio electrónico tradicional, este paso bloquea los artículos en el carrito. Aquí no hay 'carrito' real, pero el paso no es trivial: actúa como un acuerdo criptográfico con la cotización del Architect Agent, vinculando de forma irrevocable la tarea específica ('architecture-consultation') al precio acordado (800 créditos).

2. **Payment mandate**: Winston genera un mandato de pago que instruye al ledger de la plataforma para realizar un hold (retención) sobre los créditos necesarios del presupuesto del equipo. En respuesta, el servicio de pago interno emite un token firmado con HMAC. Este token actúa como prueba criptográfica portable del pago, vinculando de forma segura el importe de la transacción, las partes involucradas y el payment_ctx_id único.

3. **Reenvío con prueba**: Winston reenvía la solicitud de arquitectura inicial, esta vez adjuntando los mandate IDs y la prueba criptográfica. Antes de hacer cualquier trabajo computacional, el Architect Agent consulta al broker de pagos para verificar los mandatos. Como los credenciales de pago los genera el comprador (Winston) y no el vendedor, el sistema está criptográficamente protegido contra falsificaciones.

**La conversación multi-turno A2A: clarificación antes de la recomendación**

Con el pago verificado, el arquitecto comienza el trabajo real. No es un simple request/response, sino una conversación multi-turno A2A. El arquitecto hace preguntas de aclaración: '¿Cuál es el volumen diario exacto? ¿Transaccional o marketing? ¿Alguna restricción regulatoria?' Winston responde con el contexto de negocio. El arquitecto itera, refinando su comprensión antes de hacer una recomendación.

El diálogo A2A transcurre mientras existe un estado input_required del 'enterprise architect'. Cuando el arquitecto tiene suficiente información, cambia su estado a 'working' e indica que va a consultar al Domain Agent para verificar la viabilidad.

**La malla agéntica en acción: consulta al dominio**

Este paso, según Wulveryck, es 'la guinda del pastel'. En lugar de confiar solo en sus datos de entrenamiento internos —que podrían estar desactualizados o ser incorrectos respecto al sistema de notificaciones legado—, el Architect Agent central delega dinámicamente la consulta de viabilidad técnica directamente a 'Winston@domain', el agente especializado que gestiona el bounded context de Notificaciones.

El agente experto en el dominio evalúa la solicitud y responde: '50.000 emails/día es viable, pero requiere un aumento de cuota y una validación estricta de plantillas.' Wulveryck encuadra esto como Domain-Driven Design (DDD) aplicado a IA: el propietario del dominio valida la viabilidad local, permitiendo al arquitecto central tomar una decisión segura y sistémica.

**Decisión, artefacto y liquidación financiera**

Con todos los insumos —requisitos, cumplimiento GDPR y evaluación del agente de dominio—, el Architect Agent llama a su LLM una última vez y emite dos eventos consecutivos sobre la misma tarea:

- Un **artefacto** con la decisión estructurada: usar la plataforma interna de notificaciones vía POST /emails en https://api.lambda.internal/notifications/v1, con OAuth2 client_credentials, y con dos prerequisitos (quota_increase_required, template_validation_required).

- Una **liquidación del pago** antes de marcar la tarea como completada. Esta es una llamada HTTP directa al Payment Agent, no un mensaje A2A. El Architect Agent envía el actual_amount consumido: 620 créditos (frente a los 800 estimados inicialmente).

El Payment Agent verifica que el mandato existe y está cerrado, que el actual_amount (620) es menor o igual que el ceiling_amount (800), y que el tipo de tarea coincide. Entonces libera el hold sobre la cuenta de Winston, devuelve la diferencia (800 − 620 = 180 créditos), transfiere 620 créditos a la cuenta del Architect Agent y devuelve un settlement token firmado.

Solo entonces el Architect cierra la tarea A2A y Winston recibe el estado 'completed' con los metadatos de consumo: ap2_actual_amount: 620, ap2_tokens_consumed: 620.

**El cuadro completo: A2A + AP2 + ADRs**

Wulveryck resume las tres capas del sistema:

- **A2A** habilita la delegación verdadera entre agentes, no simples llamadas a herramientas, sino conversaciones autónomas con intención estructurada. - **AP2 + el código 402** aseguran una fijación de precios interna justa: los agentes se niegan a trabajar hasta que les pagan, los mandatos proporcionan prueba criptográfica portable, y un broker interno neutral liquida las cuentas de forma segura. - **ADRs + pruebas criptográficas** hacen que cada decisión arquitectónica sea completamente auditable y verificable de forma determinista, desde la solicitud inicial hasta la liquidación financiera final.

**Valoración crítica y estado del arte**

El propio autor advierte explícitamente que este flujo de trabajo representa 'un futuro cercano posible' más que el estándar actual de la industria. AP2, tal como lo implementa en la prueba de concepto, fue diseñado primariamente para el comercio agéntico global y trae consigo conceptos de e-commerce como la fase de checkout que no son estrictamente necesarios en una plataforma empresarial interna. Wulveryck reconoce haberlo implementado en su totalidad para demostrar cómo sería la autonomía real y segura entre agentes.

Como contexto del sector, el protocolo A2A fue propuesto por Google en 2025 como estándar abierto para la comunicación entre agentes IA, y ha ganado tracción significativa en la comunidad de desarrolladores como alternativa o complemento al MCP (Model Context Protocol) de Anthropic. El Agent Payment Protocol (AP2) es menos conocido y más experimental, orientado precisamente a resolver la economía de los sistemas multi-agente.

**Implicaciones para la IA agéntica empresarial**

El artículo de Wulveryck toca un problema real y creciente que muchas organizaciones están comenzando a experimentar: a medida que la adopción de agentes IA se generaliza dentro de las empresas, los modelos de gobernanza, coste y cumplimiento que funcionan para un equipo pequeño empiezan a romperse. La propuesta de una 'malla agéntica' con economía interna aborda varios vectores de riesgo simultáneamente:

1. **Gobernanza**: centralizando los servicios de arquitectura y cumplimiento, se crea un único punto de control auditable en lugar de N puntos opacos distribuidos en portátiles. 2. **Coste**: el routing inteligente de modelos y el cacheo centralizado permiten optimizar el gasto de LLM a nivel organizativo, en lugar de pagar prima por todo. 3. **Incentivos**: la economía interna de créditos crea incentivos correctos para que los equipos construyan herramientas IA reutilizables, sabiendo que serán compensados cuando otros equipos las adopten. 4. **Trazabilidad**: cada decisión arquitectónica queda vinculada a una transacción criptográficamente verificable, creando un rastro de auditoría completo.

**Riesgos y fricciones de la propuesta**

La propuesta no está exenta de fricciones. Introducir una capa de pagos —incluso con créditos virtuales— en el flujo de trabajo de desarrollo añade latencia y complejidad. El proceso de aprobación humana para cada transacción financiera, aunque lógico desde la perspectiva de gobernanza, podría convertirse en un cuello de botella significativo si no se implementa un sistema de aprobación automática para tareas rutinarias. Wulveryck reconoce esto y apunta al aprendizaje automático de patrones de gasto como solución futura.

Además, la adopción de estándares como A2A y AP2 requiere que múltiples partes de la organización —equipos de plataforma, equipos de producto, finanzas— colaboren en el diseño del sistema económico interno, lo cual es un desafío organizativo tanto como técnico.

**Prospectiva**

El artículo de Wulveryck apunta en una dirección que el sector parece inevitablemente destinado a explorar: los agentes IA no van a operar solo como herramientas de productividad individual, sino como participantes en ecosistemas de servicios con sus propias economías. La pregunta no es si las organizaciones necesitarán estos mecanismos de gobernanza y fijación de precios entre agentes, sino cuándo y con qué estándares.

La combinación de A2A para orquestación semántica y AP2 para liquidación económica ofrece un marco conceptualmente sólido. Si estos estándares ganan adopción industrial —particularmente A2A, que tiene el respaldo de Google— podríamos ver emerger plataformas empresariales que implementen variantes de esta arquitectura en los próximos dos a tres años.