Agentes de IA que compran cosas — La pila de protocolos detrás del agentic commerce

TL;DR

En Stripe Sessions 2026 se presentó el concepto de agentic commerce: agentes que descubren, evalúan y compran productos sin intervención humana directa
No existe un único protocolo — hay una pila de capas: MCP (descubrimiento de herramientas), UCP (checkout), ACP (compra conversacional), MPP/x402 (pagos máquina a máquina)
Stripe ya tiene un agent toolkit para Python y TypeScript compatible con OpenAI Agents SDK, LangChain, CrewAI y Vercel AI SDK
PayPal lanzó su propia suite de agentic commerce (Agent Ready, Store Sync) a finales de 2025
La parte que nadie cuenta: la autenticación delegada, el fraude máquina-a-máquina y el cumplimiento son los problemas reales

Contexto

Si ya leíste mi análisis de Stripe AI Agent Commerce y los 288 productos, sabes que Stripe está apostando fuerte por posicionar a los agentes como actores económicos. Este artículo va un nivel más profundo: cómo funciona técnicamente la pila que permite a un agente comprar, quién más está compitiendo en este espacio, y qué problemas reales vas a encontrar si intentas implementarlo.

En Sessions 2026, Patrick Collison lo resumió así: los agentes van a representar la mayoría de transacciones online en un futuro no lejano. Pero para que eso funcione, hacen falta protocolos. No uno. Varios. Y no todos se llevan bien entre sí.

La pila de protocolos del agentic commerce

El agentic commerce no es un API que conectas y ya. Es un stack con capas distintas, cada una resolviendo un problema diferente:

Capa	Protocolo	Creadores	Función	Estado
Descubrimiento	MCP	Anthropic → Linux Foundation	Cómo un agente descubre herramientas y APIs	Live
Checkout/Comercio	UCP	Google + Shopify	Descubrimiento de productos y checkout agentic	Live
Compra conversacional	ACP	Stripe + OpenAI	Checkout dentro de interfaces de chat (ChatGPT)	Live
Pagos M2M (tarjetas)	MPP	Stripe + Tempo	Pagos máquina a máquina vía redes de tarjeta	Pilot
Pagos M2M (stablecoins)	x402	Coinbase + Cloudflare	Pagos HTTP-nativos en stablecoins	Live
Gobernanza	AP2	Google	Estándar de autorización y trazabilidad	Spec
Identidad	TAP	Visa	Identidad criptográfica para agentes compradores	Live

MCP: la capa que ya conoces

El Model Context Protocol (MCP) no es un protocolo de pagos. Define cómo un LLM descubre y llama a herramientas externas. Pero sin MCP, el agente no sabe qué servicios existen. Es la capa 0: si tu agente no puede descubrir que existe una tienda, no puede comprar en ella.

MCP está bajo la Linux Foundation y ya es el estándar de facto para tool calling. Si estás construyendo agentes, ya lo usas.

UCP: el checkout para agentes

El Universal Commerce Protocol (UCP) es un estándar abierto liderado por Google y Shopify que define el flujo completo de compra para agentes:

Checkout: del carrito al pago, con o sin intervención humana
Identity Linking: autorización OAuth 2.0 para que el agente actúe en nombre del usuario
Order Tracking: webhooks para seguimiento de envíos, devoluciones y entregas
Payment Token Exchange: intercambio seguro de tokens de pago entre partes

Stripe es miembro del UCP Tech Council e implementa UCP como payment handler. La especificación está en ucp.dev y el código en GitHub.

El detalle técnico importante: UCP define una máquina de estados para el checkout con estados como incomplete, requires_escalation y ready_for_complete. Esto permite que el flujo se pause cuando hace falta intervención humana — lo cual va a pasar más a menudo de lo que los demos sugieren.

ACP: compra dentro de ChatGPT

El Agentic Commerce Protocol (ACP), creado por Stripe y OpenAI, se centra en un caso específico: la compra conversacional. Ya está live dentro de ChatGPT Instant Checkout.

Funciona así: un usuario le dice a ChatGPT “compra esto”, y el agente inicia un checkout ACP con el merchant. El merchant sigue siendo el merchant of record. El agente nunca vee los datos de pago reales — usa tokens delegados.

ACP es open source (Apache 2.0) y compatible con Stripe como primer payment provider, pero está diseñado para ser agnóstico. Meta también participa como socio.

MPP y x402: los rails de pago máquina a máquina

Aquí es donde se pone interesante. Los agentes necesitan pagar cosas, y hay dos filosofías:

MPP (Machine Payments Protocol), de Stripe + Tempo, usa las redes de tarjeta existentes. Es familiar para merchants, pero depende de la infraestructura financiera tradicional.

x402, de Coinbase + Cloudflare, revive el código HTTP 402 (que existía pero nunca se usó) para pagos nativos en stablecoins (USDC en Base, Polygon, Ethereum). Es HTTP-nativo: cada request puede incluir un pago.

La diferencia práctica:

Aspecto	MPP	x402
Rail	Tarjetas (Visa/Mastercard)	Stablecoins
Settlement	1-2 días laborables	Minutos
Caso de uso	Compras merchants	Micropagos API
Complejidad	Baja para merchants	Alta (wallets, gas)
Madurez	Pilot	Live

La mayoría de agentes en producción probablemente usarán ambos: MPP para compras en merchants, x402 para pagar APIs y servicios entre agentes.

Cómo implementarlo: el Stripe Agent Toolkit

Si quieres que tu agente pueda crear Payment Links, gestionar clientes o consultar datos en Stripe, ya existe un toolkit oficial:

import asyncio
import os
from agents import Agent, Runner
from stripe_agent_toolkit.openai.toolkit import create_stripe_agent_toolkit

async def main():
    # Siempre usar restricted keys (rk_*) con agentes
    toolkit = await create_stripe_agent_toolkit(
        secret_key=os.getenv("STRIPE_SECRET_KEY")
    )

    agent = Agent(
        name="Stripe Agent",
        instructions="Gestiona pagos y clientes de Stripe.",
        tools=toolkit.get_tools()
    )

    result = await Runner.run(
        agent,
        "Crea un payment link para 'Servicio Premium' a $49/mes"
    )
    print(result.final_output)

if __name__ == "__main__":
    asyncio.run(main())

Regla de oro: usa restricted API keys (rk_*) siempre. Un agente con una full secret key es una bomba de relojería. Las restricted keys limitan las herramientas disponibles a los permisos que configures — principle of least privilege aplicado a agentes.

El toolkit soporta Python y TypeScript, y es compatible con OpenAI Agents SDK, Vercel AI SDK, LangChain y CrewAI.

Testing antes de producción

Stripe lo dice claro en su documentación: el comportamiento de los LLM no es determinista. Un agente puede funcionar bien 99 veces y en la 100 intentar crear un charge de $10,000 en lugar de $10.

Usa Stripe Sandboxes y ejecuta evaluaciones rigurosas antes de ir a live mode. No es opcional.

Riesgos y limitaciones (la parte que los demos no muestran)

Seguridad: no es tu usuario quien compra

El modelo de autenticación tradicional (API keys, contraseñas, 2FA) está diseñado para humanos. Los agentes necesitan un modelo diferente: identidad delegada con permisos scoped.

Esto significa:

OAuth 2.0 delegado: el usuario autoriza al agente con permisos específicos (solo puede comprar en esta tienda, máximo $X por transacción)
Tarjetas de un solo uso: Stripe Link genera tarjetas virtuales desechables por tarea
Escalada obligatoria: cuando el checkout entra en requires_escalation, el agente debe parar y pedir intervención humana

El problema: ¿quién define los límites? ¿El developer del agente? ¿El usuario? ¿El merchant? Hoy, cada uno hace lo que quiere.

Fraude máquina a máquina

Stripe reporta que 1 de cada 6 intentos de registro en servicios de IA son actores maliciosos. El abuso de trials gratuitos se ha duplicado en 6 meses. Su producto Radar bloqueó 3.3 millones de registros riesgosos en un solo mes para 8 empresas.

Pero esto es fraude “tradicional”. El fraude nuevo es más sutil: agentes que explotan bugs en la lógica de checkout de otros agentes, que manipulan precios aprovechando la latencia entre catálogo y checkout, que realizan arbitraje automático a escala.

La infraestructura de prevención de fraude para agentes está en pañales.

Regulación: ¿quién es responsable?

Si un agente compra algo por error, ¿quién paga? ¿El usuario que le dio permiso? ¿El developer del agente? ¿El merchant que aceptó la compra?

Hoy no hay marco regulatorio claro. La UE está trabajando en directrices, pero hasta que haya jurisprudencia, es un灰色地带. Lo pragmático: define terms of service claros que especifiquen que el usuario es responsable de las acciones de sus agentes. No es ideal, pero es lo que hay.

Competidores: Stripe no está solo

PayPal Agentic Commerce

PayPal lanzó su suite de agentic commerce en octubre de 2025:

Agent Ready: permite a merchants conectar datos de productos, inventario y fulfillment con agentes de IA
Store Sync: sincroniza catálogos con plataformas de descubrimiento de agentes
PYUSD stablecoin: para settlement instantáneo, compitiendo directamente con x402

La ventaja de PayPal: su red de 400M+ usuarios y la integración con Honey (que ya sabe qué compran las personas). La desventaja: la marca Stripe tiene más tracción entre developers.

PayPal ya está integrado con Google para su framework de AI commerce, usando PYUSD para settlements instantáneos dentro de Google Shopping.

Visa TAP (Tokenized Agent Payments)

Visa presentó TAP, un protocolo de identidad criptográfica para agentes compradores. La idea: un agente con TAP puede demostrar criptográficamente quién es y en nombre de quién actúa, sin exponer datos del usuario.

Es complementario a los protocolos de pago: TAP resuelve la identidad, ACP/UCP resuelven el checkout, MPP/x402 resuelven el settlement.

Google AP2

Google lidera el Agent Payments Protocol (AP2), un estándar de gobernanza que define “mandates” — declaraciones firmadas digitalmente que especifican qué puede hacer un agente. Es multi-rail: funciona con tarjetas, pagos en tiempo real y stablecoins.

AP2 tiene 60+ partners iniciales incluyendo Mastercard, Adyen, PayPal y Coinbase. Aún está en fase de spec, pero marca la dirección: la gobernanza va a ser horizontal, no por rail.

Qué haría yo

Si estás construyendo agentes que necesitan comprar cosas:

Empieza por el Stripe Agent Toolkit con restricted keys. Es lo más maduro hoy. No implementes protocolos desde cero.
Define límites de gasto por agente y por tarea. Un agente sin budget cap es un agente que va a causar problemas. Usa tarjetas de un solo uso.
Implementa escalada a humano. Cualquier transacción above un threshold razonable debería pausar y pedir confirmación. Los agents que compran sin supervisión son un riesgo.
Prueba en sandbox, luego en sandbox otra vez. El comportamiento no determinista de los LLM significa que necesitas evaluaciones extensivas.
No te cases con un protocolo. Hoy ACP es lo más práctico, pero la pila va a evolucionar. Escribe tu integración con una capa de abstracción.
El fulfillment sigue siendo tu problema. Ningún protocolo resuelve la logística de entregar lo que el agente compró. Como dije antes, ACP maneja bien el checkout pero el cumplimiento real es donde está la complejidad.

El agentic commerce no es hype — los protocolos son reales, las APIs funcionan, y los primeros agents ya están comprando. Pero la distancia entre la demo y la producción es enorme. Empieza pequeño, con casos de uso acotados, y escala desde ahí.

Fuentes: Stripe Sessions 2026, Stripe Agent Toolkit, UCP Specification, Agentic Payment Protocols Map, PayPal Agentic Commerce, Stripe ACP, x402 Protocol