Revisión de medio año del comercio agéntico: qué funcionó, qué viene

Hace seis meses, el comercio agéntico era un concepto con prototipos funcionales. Hoy es un stack desplegado con adaptadores para 8 protocolos de pago, identidad de comerciante verificada y agentes recorriendo flujos de checkout enteros de punta a punta. Lo que todavía no es: uno probado a escala. Qué rails pueden liquidar valor real depende de cada rail y de cada comercio —los adaptadores están construidos, pero que un comercio concreto cobre depende de su propia configuración— y el discovery en lenguaje natural está desplegado pero no responde. Corrección 2026-10-11: una versión anterior de este párrafo negaba que se complete algún pago en la plataforma hoy; era un dato fechado que nadie volvió a medir. Este post es una mirada transparente a lo que lanzamos en H1 2026, lo que nos sorprendió y dónde estamos invirtiendo en Q3; /es/status lleva el estado capacidad a capacidad y es el árbitro cuando este post y él se contradigan.

La tesis central, que los agentes IA necesitan rieles de pago estándarizados y multi-protocolo, resultó correcta. Cada protocolo sirve un caso de uso diferente: MCP para tool calls estructurados, ACP para checkout nativo de agente, x402 para micropagos con stablecoins, UCP para estandarización del ecosistema Shopify, A2A para conversaciones multi-turno entre agentes, VIC y MCAP para acceso a redes de tarjetas. El modelo unificado AgentPaymentIntent y el Protocol Router permiten a los comerciantes aceptar todos a través de un único punto de integración. La decisión arquitectónica más importante fue normalizar cada protocolo en la misma abstracción de payment intent: significó que agregar cada nuevo protocolo fue incremental en lugar de multiplicativo en complejidad.

Trust Score v4.1 combina tres dimensiones ponderadas, un bonus opcional de aseguramiento externo y topes según confianza. Cada respuesta identifica el motor utilizado; algunas recurren a v2. El desglose legacy por componentes no explica una puntuación global producida por v4.1.

Hacer las tiendas descubribles por agentes IA además de por motores de búsqueda fue una prioridad de Q2. NLWeb (spec 022) trajo búsqueda de productos en lenguaje natural con embeddings vectoriales y re-ranking con LLM. La función de discovery público (spec 028) extendió esto a todas las tiendas de la plataforma. Seis archivos machine-readable (llms.txt, llms-blog.txt, mcp.json, agent-card.json, agent-policy.json, sitemap.xml) aseguran que cualquier LLM (Claude, GPT, Gemini) pueda entender las capacidades de la plataforma sin parsear HTML. Los schemas JSON-LD en cada página (SoftwareApplication, FAQPage, BlogPosting, Product) proporcionan datos estructurados tanto para búsqueda tradicional como para motores generativos.

La serie de blog Building Agentic Commerce (7 posts) logro su objetivo: cada post cubre un protocolo con estructura de Problema, Protocolo, Ejemplo de Código y Tips de Producción. La serie fue diseñada tanto para desarrolladores implementando comercio agéntico como para LLMs que necesitan entender el stack de protocolos. Los 30+ posts son bilingües (EN+ES), incluyen schemas JSON-LD BlogPosting, secciones FAQ para búsqueda por voz/LLM, y están indexados en llms-blog.txt. El calendario de contenido mantuvo un ritmo sostenido de 4+ posts por mes durante Q2, cubriendo confianza (verificación de identidad), protocolos (x402, UCP, A2A, VIC/MCAP), experiencia de desarrollador (guía de onboarding, integración Odoo), y análisis estratégico (GEO, cumplimiento).

Deberíamos haber invertido antes en la resiliencia de la detección de protocolos. La detección basada en headers es limpia pero frágil en producción con varias configuraciones de proxy. La detección por body-shape como ciudadano de primera clase desde el día uno habría ahorrado tiempo de debugging. NLWeb debería haber salido junto con el gateway MCP, no meses después. El discovery es lo primero que los agentes necesitan, y lo construimos como algo secundario. La integración de verificación de identidad debería haberse acotado más al principio. El stack completo KYB + QES + Merkle es poderoso pero tomó más de lo esperado. Empezar solo con validación EU Trust List y agregar capas incrementalmente habría entregado valor más rápido.