Iván Fernández García
Solutions Architect & Tech Manager, Galeo Tech
PARA EMPEZAR
Construir un producto con IA en 2026 es cuestión de horas. Habilitar IA dentro de una empresa —con sus sistemas internos, sus permisos, sus integraciones con terceros y su deuda semántica— es otra cosa. Y la diferencia no es «un poco más de ingeniería»: es una capa arquitectónica completa que la mayoría de empresas todavía no tiene. Este post va sobre cómo se ve esa capa cuando se diseña correctamente, qué protocolos están emergiendo para sostenerla —MCP, A2A, AG-UI— y cuándo conviene colocar frameworks de orquestación on-top como LangGraph o similares.
01 · LA ASIMETRÍA
Construir con IA hoy lleva horas. Habilitarla dentro de una empresa, no.
Esa asimetría es el corazón de todo lo que viene a continuación.
Cualquier desarrollador (y sin necesidad de serlo mucho) con una API key levanta un asistente conversacional en una tarde. Lee un PDF, contesta preguntas, llama a una función. Funciona. Es magia barata y termina en LinkedIn como si fuese un avance histórico. Multiplica por n y ya tienes un feed diario de LinkedIn que provoca ese efecto túnel en el que parece que todo el mundo va a la velocidad de la luz menos tú. Tranquilo. No todo es lo que parece.
El problema es que esa demo nunca llega a producción dentro de una empresa. Y cuando lo intenta, choca contra todo lo que hace que una empresa sea una empresa: identidades, scopes, datos repartidos entre veinte sistemas, integraciones con terceros, KPIs definidos de forma distinta en cada departamento, auditoría obligatoria y un comité de seguridad que pregunta —con razón— quién hace qué, con qué permisos, sobre qué dato y con qué trazabilidad.
Lo que separa un escenario del otro no es la cantidad de trabajo: es la ausencia de una capa común. Sin ella, cada caso de uso de IA en la empresa exige su propia integración de identidad, su propio parsing, su propio contrato con cada sistema. El resultado son proyectos a medida, frágiles, difíciles de auditar y que se rompen en cuanto el sistema de origen cambia un campo.
LA TESIS
El cuello de botella de la IA empresarial no son los modelos. Son los contratos entre sistemas y agentes. Hoy ese contrato falta — y la pila de protocolos abiertos que está emergiendo es la primera respuesta seria al problema.
02 · EL PAISAJE ACTUAL
Cada agente, integrando cada cosa a su manera.
Si uno entra hoy en cualquier empresa con varios casos de uso de IA en producción (no creáis que son tantas a diferencia de lo que parece en LinkedIn), lo que se encuentra suele ser parecido: un chatbot interno con su propia integración contra el data warehouse, otro asistente que llama a la API REST de un producto, un copilot operativo conectado a una base vectorial con un SDK específico, un agente que automatiza tickets en un SaaS externo usando el token de una cuenta de servicio. Todo funciona — más o menos — pero nada comparte nada: ni la identidad del usuario, ni la forma de descubrir capacidades, ni el formato de los errores, ni la observabilidad.
Cada nuevo agente que se quiere lanzar es un proyecto desde cero. Cada nuevo sistema que se quiere conectar es otra negociación de credenciales, otra capa de parsing, otro manual interno. La complejidad escala como N × M: tantos agentes por tantos sistemas, tantos puntos donde puede romperse algo.
Fig. 1 — La diferencia no es estética: es estructural. Sin contrato común, cada agente reimplementa identidad, scopes y parsing para cada sistema.
Lo importante no es solo el número de hoy: es lo que pasa cuando llega el sexto sistema o el cuarto agente. En un mundo sin contrato común, cada incorporación multiplica el trabajo. Con una capa común, las nuevas piezas se enchufan al protocolo y heredan la fontanería. Es la misma lógica que llevó hace veinte años a tener buses de mensajería, o a estandarizar las APIs REST: cuando una abstracción es buena, el coste marginal de añadir un nodo más se vuelve casi cero.
Y aquí no hace falta inventar la abstracción. Ya existe.
Esto no es particular de la IA, en el mundo del SW siempre pasa lo mismo. Lo hemos visto con el No-code (La ilusión del Low-Code: Por qué se desvanece rápido) o con las Z en los ERPs.
03 · LA PIEZA QUE YA ESTÁ SOBRE LA MESA
MCP: cómo un sistema se presenta ante un agente.
MCP — Model Context Protocol — es un protocolo abierto que estandariza la forma en que un sistema expone sus capacidades a un agente de IA. No es una API más. Es la fachada agéntica de un sistema: una superficie común desde la que un agente puede descubrir qué tools hay disponibles, qué argumentos esperan, qué efectos producen y cómo se invocan, sin tener que conocer los detalles internos del sistema que las implementa.
La clave conceptual está en el verbo descubrir. Una API REST tradicional asume que el cliente —un desarrollador, una aplicación— ya sabe qué endpoints existen y qué hace cada uno. Un agente de IA no. El agente llega a la conversación, le pregunta al MCP qué puede hacer, lee las descripciones, razona sobre cuál encaja con la pregunta del usuario, compone una llamada, la ejecuta, lee el resultado y decide el siguiente paso. Esa interacción exige metadatos ricos y un canal homogéneo, y eso es exactamente lo que MCP define.
Lo que expone un MCP empresarial bien hecho
Cuando un sistema interno «tiene MCP», lo que tiene es un servidor que actúa como única superficie hacia el mundo de los agentes. Dentro de ese servidor, el equipo decide qué quiere ofrecer y con qué granularidad:
- RAGs sobre documentación, tickets, contratos o histórico operativo.
- Endpoints y queries tipadas, desde lecturas deterministas hasta capacidades analíticas ad-hoc.
- Knowledge bases estructuradas y vector DBs semánticas, expuestas con la granularidad adecuada.
- Acciones —escrituras, comandos, transiciones de estado— con confirmación humana cuando hace falta.
- Integraciones con SaaS externos que ya estaban en la empresa, reexpuestas a través del mismo contrato.
La clave no es la lista. La clave es que el sistema sigue siendo dueño de sus datos y de sus reglas. El MCP es una fachada, no un nuevo silo. Los datos no se duplican, las reglas de negocio no se replican, la identidad y los scopes del usuario que pregunta se propagan hasta donde se ejecuta la acción.
Fig. 2 — Anatomía de una capa MCP empresarial. La superficie de protocolo es la parte visible; los frentes transversales son lo que separa una demo de un sistema en producción.
Las cinco cajas inferiores del diagrama —identidad, capa semántica, trazabilidad, gobernanza y versionado— son las que distinguen un MCP de juguete de un MCP que aguanta producción. No son opcionales, y conviene decirlo porque son el frente más subestimado de toda la conversación. Las trato una a una en el capítulo siguiente.
04 · POR QUÉ LA EMPRESA ES DISTINTA
Los 5 frentes que no aparecen en las demos.
Lo que parece detalle de implementación es, casi siempre, el punto donde el proyecto se cae.
- Diseño de capacidades. ¿Qué tools expone cada MCP? ¿Con qué granularidad? ¿Una sola que devuelve todo, o veinte que devuelven trocitos? ¿Cómo versionas el contrato cuando el modelo subyacente cambia un campo? El diseño de tools se parece más al de una API pública que al de una API interna: una vez expuesta, los agentes empezarán a depender de ella y romperla es caro. Cada nombre, cada parámetro, cada descripción se convierte en deuda viva.
- Capa semántica. Que la palabra «cliente» —o «facturación», o «ticket», o «ingreso recurrente»— signifique lo mismo en todos los MCPs de la empresa. Sin esto, los agentes producen respuestas técnicamente correctas y empresarialmente contradictorias: dos preguntas equivalentes devuelven cifras distintas porque cada sistema define la métrica a su manera. Es el frente más político y el menos técnico de los cinco: requiere un diccionario corporativo de conceptos, owners definidos y un repositorio versionado. No hace falta una herramienta nueva. Hace falta un contrato explícito. Esto no es nuevo, la capa semántica es una disciplina a menudo olvidada en las plataformas de datos corporativas y para las arquitecturas de IA es crítica.
- Gobernanza. Identidad propagada de extremo a extremo: el agente actúa como el usuario, no en su nombre. Scopes diferenciados para lectura y escritura. Confirmación humana obligatoria en acciones críticas. Logs de cada llamada — qué tool, con qué argumentos, qué devolvió, qué hizo el agente con la respuesta. Sin esto no hay auditoría, y sin auditoría no hay producción.
- Veracidad. Tests automáticos sobre métricas canónicas, detección de alucinaciones, citación obligatoria de la fuente en cada cifra. Una respuesta no verificable es peor que ninguna respuesta: erosiona la confianza de toda la plataforma. La regla operativa es simple: si una cifra no puede trazarse hasta la llamada MCP que la generó, no se devuelve.
- Coste y latencia. Caching donde se puede, batching donde tiene sentido, modelos pequeños para tareas de routing y modelos grandes solo cuando aportan. Una buena arquitectura agéntica se nota en la factura tanto como en la experiencia.
LO IMPORTANTE
Estos cinco frentes no se resuelven por sistema, se resuelven por empresa. Quien intente abordarlos sistema a sistema va a multiplicar el coste y a divergir en las decisiones. Quien los aborde a nivel corporativo, una vez, los amortiza en cada MCP que despliegue después.
05 · EL ESTÁNDAR TAMBIÉN LLEGA DE FUERA
Lo que antes era «la API de Salesforce», ahora es «el MCP de Salesforce».
Hay un detalle que cambia bastante el cálculo y que merece capítulo aparte: MCP no es algo que solo se vaya a montar dentro de las empresas. Los grandes proveedores de software empresarial —Salesforce, SAP, Atlassian, GitHub, Notion, Slack, Stripe, HubSpot, Cloudflare, los hyperscalers— están publicando sus propios servidores MCP oficiales como parte del producto. La industria se está moviendo en esa dirección, y rápido.
Esto significa dos cosas. La primera, práctica: cuando una empresa construye su capa MCP, no tiene que construir conectores para los terceros. El MCP del proveedor ya existe; se registra en la capa corporativa y se le pasa la identidad correcta. La segunda, más estratégica: el hueco que durante quince años ocupó la API REST como contrato de integración entre empresas se está rellenando, una capa más arriba, con MCP. Lo que antes era «la API de Salesforce», para los agentes empieza a ser «el MCP de Salesforce».
No es que la API vaya a desaparecer —sigue siendo el contrato natural entre dos máquinas que saben exactamente lo que quieren. Lo que cambia es que aparece una nueva capa de contrato por encima, optimizada para clientes que no saben de antemano qué van a necesitar: agentes que descubren capacidades en tiempo de ejecución, que componen llamadas sobre la marcha, que necesitan metadatos ricos para razonar. Esa capa va a coexistir con las APIs durante mucho tiempo, pero es donde va a vivir cada vez más interacción a partir de ahora. Esto es determinismo vs no determinismo, como un PLC vs un PC.
UNA PREDICCIÓN RAZONABLE
Dentro de dos o tres años, la pregunta que un CIO hará al evaluar software empresarial no será solo «¿qué API tiene este producto?». Será también «¿qué MCP expone y con qué granularidad?». Y el catálogo de respuestas posibles será tan importante para la decisión de compra como lo fue la API en su día.
06 · LOS OTROS DOS PROTOCOLOS
A2A y AG-UI: las conversaciones que MCP no cubre.
MCP es muy bueno respondiendo a una pregunta: ¿cómo accede un agente a las herramientas de un sistema? Pero el stack agéntico de una empresa tiene dos conversaciones más, y cada una está empezando a tener su propio protocolo estandarizado.
Agent-to-Agent (A2A)
La primera conversación es entre agentes. En cuanto pasas de «un chatbot» a «varios agentes con responsabilidades distintas», aparece la necesidad de que se descubran y se deleguen tareas entre sí. Un agente principal —el que habla con el usuario— puede pedirle a un agente especializado en reporting que prepare un informe nocturno, a un agente de compras que ejecute un workflow largo, o a un agente operativo que monitorice una alerta durante toda la jornada.
Esas tareas son, muchas veces, desatendidas: el agente que las recibe trabaja durante minutos u horas sin que haya un humano esperando al otro lado. Necesitan un protocolo que no asuma respuesta inmediata, que permita handoff entre agentes, que dé a cada uno una identidad propia y un descriptor —un «agent card»— donde declare qué sabe hacer.
A2A es, conceptualmente, el equivalente a MCP pero entre pares. Cuando madure, no es difícil imaginar arquitecturas donde un agente principal compone respuestas combinando llamadas MCP propias con delegaciones A2A a agentes especializados —algunos internos, otros expuestos por proveedores externos.
Agent-User Interaction (AG-UI)
La segunda conversación es entre el humano y el agente. Y aquí hay un problema que cada equipo está resolviendo por su cuenta: cómo transmitir, desde el agente hasta la interfaz del usuario, un flujo conversacional rico —texto en streaming, mensajes intermedios, llamadas a tools visibles, formularios que el agente pide rellenar, confirmaciones de acciones— sin reinventar el protocolo en cada producto.
Eso es lo que aborda AG-UI: un protocolo abierto y ligero, basado en eventos tipados, que estandariza el canal entre cualquier agente y cualquier frontend. Su documentación de arquitectura describe un middleware fino —agnóstico de framework, agnóstico de transporte— que define qué eventos viajan entre las dos partes: deltas de texto, mensajes completos, peticiones de tool, resultados, formularios, estados intermedios. Es, en esencia, lo que WebSockets es a las apps en tiempo real, pero pensado específicamente para conversaciones con LLMs.
AG-UI forma parte de una familia de protocolos agénticos —junto a MCP y A2A— donde cada uno tiene un rol claro: MCP conecta agentes con sistemas, A2A conecta agentes con agentes, AG-UI conecta agentes con personas. No son competidores; son piezas de la misma pila, y cada una resuelve una capa distinta.
07 · CUANDO UNA PREGUNTA NO SE RESUELVE CON UNA SOLA TOOL
LangGraph y LangChain: el orquestador encima de los MCPs.
Hay una clase de preguntas que no se resuelve llamando a una sola tool. Por ejemplo: «dame las incidencias críticas del último mes en la región X, cruza con la facturación de los clientes afectados, y si el impacto supera un umbral, abre un ticket con prioridad Alta y manda un email al responsable de cuenta». Esa pregunta encadena cuatro o cinco llamadas a MCPs distintos con condiciones entre ellas. Pedírsela en bruto al LLM y dejar que improvise es lo que más alucinaciones genera, lo que más coste y latencia introduce, y lo que peor se audita.
La solución que está consolidándose en la industria es poner un framework de orquestación entre el agente y los MCPs: típicamente LangGraph —la rama centrada en grafos de LangChain— pero hay alternativas. La idea es separar dos responsabilidades que no conviene mezclar:
- La planificación —qué pasos hay que dar, en qué orden, con qué dependencias— la hace un LLM que genera un plan estructurado (típicamente JSON).
- La ejecución —recorrer el plan, llamar a cada MCP, evaluar condiciones, parar si algo falla, encadenar resultados— la hace código determinista en Python o TypeScript.
Este patrón se conoce como plan-and-execute, y es probablemente la primitiva más útil que ha aportado LangGraph a las arquitecturas agénticas serias. El LLM no decide en cada paso si llamar a una tool — eso es lo que produce comportamientos erráticos. El LLM planifica una vez y luego un grafo de nodos deterministas ejecuta. La lógica de negocio (umbrales, condiciones, validaciones, retries) vive en código auditable, no en el prompt.
Hay otra ventaja menos obvia: este patrón es compatible con ejecuciones largas y desatendidas. Un grafo puede correr durante minutos u horas, persistir su estado entre pasos, recuperarse de fallos parciales y seguir adelante. Eso es muy difícil de conseguir con un agente que decide sobre la marcha en cada turno.
Importante: LangGraph no reemplaza a MCP —vive una capa por encima. Los MCPs siguen siendo el contrato con los sistemas. LangGraph es lo que se encarga de coreografiar varias llamadas a esos MCPs cuando la pregunta lo exige. Para preguntas simples (una tool, una respuesta) sobra; para preguntas con ramificación y condiciones, es lo que evita que la arquitectura se vuelva imposible de razonar.
Fig. 3 — Las tres conversaciones del stack agéntico empresarial y la capa de orquestación encima. Cada protocolo resuelve un problema distinto; juntos definen el modelo de referencia.
La IA es la palanca. La plataforma es lo que queda.
Cuando uno mira hacia atrás los últimos veinte años de arquitectura empresarial, lo que recuerda son las capas que se quedaron: la API REST, el bus de mensajes, el data warehouse, el data lake. Cada una respondía a una pregunta concreta de su época, y cada una sobrevivió a las modas que la rodearon.
MCP, A2A, AG-UI y los frameworks de orquestación tipo LangGraph están en esa misma trayectoria. La pregunta que responden es nueva —¿cómo convivimos con agentes dentro de la empresa?— y la respuesta es lo bastante simple y abierta como para que sea probable que dure. Lo que se construye ahora encima de esas piezas seguirá funcionando dentro de cinco años, aunque los modelos de hoy se hayan jubilado tres veces.
Habilitar IA dentro de una empresa no es montar un chatbot. Es construir la capa que falta entre los sistemas que ya tienes y los agentes que van a llegar. Esa capa es nueva, pero el ejercicio de construirla no lo es: es el mismo que se hizo con las APIs hace quince años. La diferencia, esta vez, es que la ventaja de llegar antes es mayor.
REFERENCIAS
[1] Agentic Protocols — Entendimiento de MCP, A2A y AG-UI (introducción): https://docs.ag-ui.com/agentic-protocols
[2] AG-UI — Documentación de arquitectura: https://docs.ag-ui.com/concepts/architecture
[3] LangGraph — Workflows y Agentes: https://docs.langchain.com/oss/python/langgraph/workflows-agents