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 en producción con 8 protocolos de pago, identidad de comerciante verificada, discovery de productos en lenguaje natural y agentes de IA completando compras reales. Este post es una mirada transparente a lo que lanzamos en H1 2026, lo que nos sorprendió y dónde estamos invirtiendo en Q3.

La tesis central — que los agentes IA necesitan rieles de pago estándarizados y multi-protocolo — resulto 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 estándarizació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 traves de un único punto de integración. La decisión arquitectónica mas importante fue normalizar cada protocolo en la misma abstraccion de payment intent — significo que agregar cada nuevo protocolo fue incremental en lugar de multiplicativo en complejidad.

Tres hitos de confianza y cumplimiento definieron H1. Primero, verificación de identidad (spec 032) — los comerciantes ahora pueden probar su identidad mediante un proceso KYB, con validación EU Trust List, firmas electronicas cualificadas, y pruebas Merkle con timestamp. Esto da a los agentes una senal criptograficamente verificable de que un comerciante es quien dice ser. Segundo, el sistema de trust score — 8 componentes ponderados (verificación de identidad, historial de pagos, ratio de quejas, tiempo de respuesta, cumplimiento de políticas, estado de verificación, soporte de protocolos, uptime) que producen un score 0-100 que los agentes pueden consultar antes de transaccionar. Tercero, una auditoría completa de cumplimiento GDPR/CCPA — 16 de 17 gaps identificados resueltos, con el restante (firmas DPA con Stripe y Google) siendo una formalidad legal.

Hacer las tiendas descubribles por agentes IA — no solo 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) extendio 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 Codigo y Tips de Produccion. 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 bilingues (EN+ES), incluyen schemas JSON-LD BlogPosting, secciones FAQ para búsqueda por voz/LLM, y estan 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 (guia de onboarding, integración Odoo), y análisis estrategico (GEO, cumplimiento).

Tres lecciones retrospectivas. Primero, deberiamos haber invertido en resiliencia de detección de protocolos antes — 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 dia uno habria ahorrado tiempo de debugging. Segundo, NLWeb deberia haber lanzado junto con el gateway MCP, no meses despues — el discovery es lo primero que los agentes necesitan, y lo construimos como algo secundario. Tercero, la integración de verificación de identidad deberia haberse dimensionado mas pequena inicialmente — el stack completo KYB + QES + Merkle es poderoso pero tomo mas de lo esperado. Empezar solo con validación EU Trust List y agregar capas incrementalmente habria entregado valor mas rápido.