El stack agéntico en 2026: un diagrama, cinco capas, y el modelo mental del operador
Pasamos un mes escribiendo una capa a la vez. El lector que estuvo con nosotros durante toda la serie tiene una imagen profunda de cada protocolo, cada patrón, cada disciplina. El lector que aparece hoy y quiere saber cómo se ve el stack agéntico en realidad a mitad de 2026 tiene dieciocho posts por digerir. Este post es la síntesis que les debíamos a ambos. Un diagrama de las cinco capas tal como componen efectivamente en producción, una oración por capa sobre qué pregunta responde, el patrón canónico de composición que atraviesa cada sistema de agentes real, dónde se sientan las preocupaciones transversales de evaluación y seguridad, y el modelo mental del operador para navegar todo.
El diagrama
Las cinco capas, de abajo hacia arriba, como apilan efectivamente en cualquier sistema de agentes en producción al mayo de 2026.
El stack agéntico, mitad 2026:
┌──────────────────────────────────────────────────────────────┐
│ USUARIO / PRINCIPAL / OPERADOR │
│ Meta real, dinero real, consecuencias reales │
└────────────┬─────────────────────────────────────────────────┘
│
┌────────────▼─────────────────────────────────────────────────┐
│ AGENTE (el proceso powered por LLM) │
│ Decide, planifica, despacha, sintetiza │
└────────────┬─────────────────────────────────────────────────┘
│
┌───────┴────────┬───────────────┬──────────────┐
│ │ │ │
┌────▼────┐ ┌────▼────┐ ┌─────▼─────┐ ┌────▼────┐
│ MCP │ │ A2A │ │ AP2 │ │ ERC-8004│
│ tools / │ │ agente↔ │ │ autoriz. │ │identidad│
│ datos │ │ agente │ │ de pago │ │ + rep. │
└────┬────┘ └────┬────┘ └─────┬─────┘ └────┬────┘
│ │ │ │
▼ ▼ ▼ ▼
GitHub, BD, Otros agentes, Rails de Registry
Notion, marketplaces, tarjeta, on-chain
Stripe, flujos x402 / USDC, (Ethereum,
filesystem delegados rails bancarios Base, etc.)
│ ▲
│ │
└──────────────────────────────────────────────┘
(la liquidación del pago autorizado vía AP2 aterriza en
x402 / tarjeta / banco, y el recibo de validación
resultante se postea de vuelta en ERC-8004)
Cinco capas debajo del agente. Cada una responde exactamente una pregunta. Ninguna se superpone; ninguna duplica. El hecho de que puedas meterlas en un único diagrama ASCII es la síntesis en sí — hace dieciocho meses la misma imagen habría requerido una matriz de vendors y un footnote sobre qué adaptador de integración iba dónde.
El resumen de una oración por capa
Memorizar las cinco capas significa memorizar qué pregunta responde cada una. El formato que adoptamos internamente:
MCP — "¿Qué tools tiene acceso el agente?" La capa vertical entre el agente y cualquier capacidad externa — una base de datos, un sistema de archivos, una API, un servicio SaaS. Tools, resources, prompts del lado servidor; sampling, roots, elicitation del lado cliente. Transport stateless en el release 2026-07-28. Cubierto en nuestro deep dive de MCP.
A2A — "¿Con qué otros agentes puede hablar el agente, y cómo?" La capa horizontal entre agentes. Agent Cards en una well-known URL para discovery, once métodos JSON-RPC, lifecycle de tasks de ocho estados, tres mecanismos de update. Cubierto en nuestro walkthrough de A2A.
AP2 — "¿El humano realmente autorizó esta compra?" La capa de autorización. Tres Verifiable Credentials firmadas (Intent, Cart, Payment), cuatro actores (User Agent, Merchant Agent, Credentials Provider, PSP), dos flujos (Human Present y Human Not Present). Cubierto en nuestro post de AP2.
x402 — "¿Cómo se liquida efectivamente el pago si es crypto-nativo?" La capa de liquidación para pagos de stablecoin y on-chain. HTTP 402 revivido, EIP-3009 / Permit2 / Solana SPL, mediado por facilitator. Cubierto en nuestro post de x402.
ERC-8004 — "¿Quién es este agente, y cuál es su historial?" La capa de identidad, reputación y validación. Tres registries on-chain (Identity, Reputation, Validation). El archivo de registro vincula el endpoint A2A del agente, la URL del server MCP, el endpoint x402 y las wallets a una única identidad anclada en la cadena. Cubierto en nuestro post de ERC-8004.
El patrón canónico de composición
La razón por la que el diagrama vale la pena memorizar es que casi cada interacción significativa entre agentes en producción sigue el mismo patrón de composición. El patrón se lee de arriba abajo a través de las capas, y cada protocolo se usa exactamente una vez en su rol.
Patrón de composición, de punta a punta:
1. El Agente A quiere contratar a un agente para hacer la tarea X.
│
2. El Agente A consulta la Identity Registry de ERC-8004 por
candidatos con la skill X y un score mínimo de reputación N.
│
3. Para cada candidato, el Agente A obtiene el
/.well-known/agent-card.json (Agent Card de A2A).
│
4. El Agente A elige un candidato, envía un SendMessage de A2A
al endpoint de tasks del candidato.
│
5. El candidato responde con una Task en estado INPUT_REQUIRED
y un Cart Mandate de AP2 embebido.
│
6. El principal del Agente A (o su Intent Mandate pre-autorizado)
contra-firma el Cart Mandate.
│
7. El Credentials Provider firma el Payment Mandate;
la liquidación va vía x402 en Base / Solana / Polygon
(o vía un rail de tarjeta a través de un PSP).
│
8. El candidato transiciona la Task a WORKING, hace el trabajo,
transiciona a COMPLETED con artifacts adjuntos.
│
9. El Agente A obtiene los artifacts vía A2A, postea un
Validation Receipt de vuelta a ERC-8004 referenciando el
token de identidad del candidato. La reputación se actualiza.
El flujo entero usa cada protocolo exactamente una vez, en el rol para el que cada uno fue diseñado. ERC-8004 para discovery y actualización de reputación. A2A para la conversación a nivel protocolo. AP2 para la cadena de autorización. x402 para liquidación. MCP, a lo largo del proceso, para cualquier tool que el flujo interno del candidato necesite (no mostrado en el flujo porque es interno al proceso del candidato).
Si entiendes este flujo de nueve pasos, entiendes el stack agéntico en 2026. Todo lo demás es o una especialización (qué modelo usa el candidato para qué paso) o una preocupación transversal (eval, observabilidad, seguridad) que envuelve al flujo.
Dónde se sientan la evaluación y la seguridad
Las cinco capas de protocolo manejan la mecánica operacional. Dos preocupaciones transversales envuelven a cada una de ellas.
La evaluación y la observabilidad se sientan transversalmente sobre los cinco protocolos. El trace de una llamada A2A, el costo de una invocación de tool MCP, la latencia de una liquidación x402, la frescura de un mandate AP2, el cambio en un score de reputación ERC-8004 — todos son señales observadas que el dashboard del operador expone. El post que publicamos ayer cubre esto; la versión corta es que cada acción significativa a través de cada capa se loguea con propagación W3C Trace Context, y el dashboard del operador las correlaciona en una vista operacional.
La seguridad y el threat modelling también envuelven cada capa. La prompt injection amenaza el paso de razonamiento del agente sin importar qué protocolo está consumiendo. El tool poisoning amenaza la capa MCP. El replay de mandates amenaza AP2. Los ataques Sybil amenazan el grafo de reputación de ERC-8004. El post de threat-model de hace dos días dispone los ocho ataques vivos y los cuatro emergentes; las defensas aterrizan en distintas capas según la clase de ataque, pero el threat model en sí es una propiedad del stack entero, no de ningún protocolo individual.
Las preocupaciones transversales:
┌─────────────────────────────────────────────────────┐
│ EVALUACIÓN + OBSERVABILIDAD │
│ (traces, costo, latencia, drift en cada capa) │
└─────────────────────────────────────────────────────┘
▲
┌────────┬────────┼────────┬────────┐
│ │ │ │ │
MCP A2A AP2 x402 ERC-8004
│ │ │ │ │
└────────┴────────┼────────┴────────┘
▼
┌─────────────────────────────────────────────────────┐
│ SEGURIDAD + THREAT MODEL │
│ (injection, poisoning, hijack, replay, Sybil) │
└─────────────────────────────────────────────────────┘
El modelo mental del operador
El modelo mental que le permite a un operador navegar el stack sin perderse en los detalles del protocolo es corto:
Cinco capas, un diagrama, un flujo canónico. Cuando algo funciona, sigue el rastro por el diagrama y vas a encontrar la capa que hizo el trabajo. Cuando algo falla, sigue el rastro por el diagrama y vas a encontrar la capa donde vive la falla. Los protocolos están deliberadamente separados para que "qué capa se rompió" sea una pregunta con una respuesta clara.
Cada protocolo es propiedad de una casa neutral. MCP bajo modelcontextprotocol.io con Working Groups de gobernanza. A2A bajo la Linux Foundation. AP2 bajo la FIDO Alliance. x402 bajo la Linux Foundation (desde abril 2026). ERC-8004 bajo la Ethereum Foundation. Ningún vendor único es dueño del stack; la quiebra de ningún vendor lo derriba.
La composición es el valor. Cada protocolo por sí solo es útil pero limitado. El stack es más que la suma de sus partes porque el patrón de composición (el flujo de nueve pasos de arriba) le permite a una contraparte que nunca conoció a tu agente decidir transaccionar con él en una sola vuelta. Esa vuelta es la unidad del comercio de agentes.
La evaluación y la seguridad no son capas; son propiedades del todo. Envuelven al stack. Un operador que las saltea tiene un stack sin sistema nervioso y sin sistema inmunitario.
Agent Builder es el plano de control que opera el stack por ti. No es un sexto protocolo; no es un reemplazo del stack. Es el plano de control que le permite a un operador configurar agentes que hablen los cinco protocolos, observarlos a través de las preocupaciones transversales, y no tener que reinventar cada patrón de composición desde cero.
Qué falta — los gaps a vigilar
El diagrama es honesto sobre lo que 2026 saldó. También es honesto sobre lo que 2026 todavía no saldó. Tres gaps que vale la pena rastrear.
Alineación semántica a través de A2A. Dos agentes pueden completar una conversación A2A perfectamente mientras discrepan sobre qué significa "entregado" o "aprobado". Lo marcamos en el post de A2A; el campo va a necesitar o una capa de ontología compartida o un registry de extensiones semánticas por dominio antes de que el comercio de agentes pueda escalar a través de industrias sin acuerdos bilaterales por par de términos.
Continuidad de memoria a través de sesiones. Un agente que hace un gran trabajo en la sesión N no tiene una forma a nivel protocolo de traer ese aprendizaje a la sesión N+1 con la misma contraparte. Graphiti, Mem0 y stores de memoria externos similares llenan el gap operacionalmente; un estándar a nivel protocolo para memoria de agente portable no aterrizó. El trabajo está pasando en investigación; nada está saliendo en producción todavía.
Portabilidad cross-chain de mandates. Un Cart Mandate AP2 firmado para liquidación en Base no convierte sin fricciones a liquidación en Solana si el rail preferido de la contraparte difiere. El bridging cross-rail en la capa AP2 es una discusión v1.x que todavía no produjo una implementación.
Ninguno de estos gaps está rompiendo el stack hoy. Son las cosas que van a necesitar aterrizar en los próximos doce a dieciocho meses para que el stack soporte las cargas más grandes que los operadores van a demandar a medida que el mercado crezca.
Cómo usar este diagrama
Dos usos prácticos.
Comunicación interna. Cuando un colega o un cliente pregunta "¿cómo se ve el stack agéntico?", muéstrale el diagrama. La conversación que sigue es la correcta — sobre composición, sobre qué capa es dueña de qué, sobre dónde encaja su caso de uso. El diagrama es el artefacto que termina la confusión "¿es MCP un competidor de A2A?" en un minuto.
Revisión de arquitectura. Al diseñar un sistema de agentes nuevo, recorre el flujo canónico contra el caso de uso. Cada paso que el caso de uso saltea es o una reducción deliberada del scope (el agente no necesita ERC-8004 porque todas las contrapartes están dentro de una organización) o una pieza faltante (el agente no tiene forma de aceptar pagos porque AP2 no fue implementado). El diagrama es el checklist.
Cierre
El stack agéntico a mitad de 2026 es la primera versión de la infraestructura de la economía de agentes que es lo suficientemente legible para caber en un diagrama y lo suficientemente estable para construir encima con confianza. Cada capa tiene una casa neutral, una implementación de referencia, un working group, y un roadmap. El patrón de composición está saldado. Las preocupaciones transversales están bien entendidas. El modelo mental del operador es lo suficientemente corto para memorizar.
Hace dieciocho meses, nada de esto era cierto. Dentro de dieciocho meses, los gaps que marcamos probablemente se habrán cerrado y un set nuevo de patrones de orden superior va a ser lo que haya que aprender. Para los próximos dos trimestres, este diagrama es el mapa. Imprímelo, cuélgalo en la pared, refiérete a él cuando diseñes.
El próximo post de esta serie deja la síntesis atrás y vuelve a lo concreto cara al operador: diez nichos donde un operador individual puede lanzar un agente real en una semana, con estimaciones de TAM, requerimientos de datos, y patrones de monetización. La síntesis te dice qué es posible; la lista de nichos te dice qué hacer con eso.