Artículo publicado originalmente en inglés.

Cuando las máquinas empezaron a hablar el mismo idioma

En la década de 1990, un consorcio de fabricantes de equipos y organismos de ingeniería agrícola comenzó a abordar un problema que estaba frenando la agricultura de precisión. Cada fabricante utilizaba su propio protocolo de comunicación para los datos entre el apero y el tractor. Un tractor John Deere y un pulverizador Hardi no podían compartir un lenguaje de datos sin una integración a medida. Hacer que la información viajara de forma fiable entre máquinas de distintos fabricantes era caro, frágil y estaba fuera del alcance de la mayoría de las explotaciones.

La solución fue la ISO 11783, más conocida como ISOBUS: un estándar de comunicación compartido al que puede ajustarse cualquier fabricante que lo cumpla, independientemente de la marca. Una vez que un apero y un tractor cumplen el estándar, los datos fluyen entre ellos. El operador trabaja con el sistema en su conjunto en lugar de gestionar la traducción entre las partes.

ISOBUS no hizo más inteligente a ninguna máquina por sí sola. Hizo posible la relación entre las máquinas.

Esa distinción, entre mejorar un componente y posibilitar una relación, es en lo que he estado pensando desde el 22 de abril.

Lo que ocurrió en Google Cloud Next en Las Vegas

El 22 de abril, Google publicó un protocolo llamado A2A (Agent-to-Agent) junto con una implementación de referencia llamada Agent Gateway. Google describe el Gateway como el «controlador aéreo» de las operaciones multiagente: una capa que inspecciona, gobierna y enruta la comunicación entre agentes de IA, herramientas de terceros y fuentes de datos.

A2A no es un producto. Es un estándar propuesto sobre cómo se comunican entre sí los agentes de IA.

Se lanzó con compromisos de más de 50 socios tecnológicos: Atlassian, Salesforce, SAP, ServiceNow, Workday, LinkedIn, PayPal y otros. No son actores marginales; son la pila de software empresarial que hace funcionar RR. HH., compras, finanzas y operaciones en grandes organizaciones de todo el mundo. Cuando ese grupo respalda un estándar de comunicación desde el primer día, el anuncio pasa de propuesta a decisión de infraestructura.

Que A2A llegue a ser ese punto de inflexión para los sistemas de inteligencia está por ver. Pero las condiciones que hicieron determinante a ISOBUS están presentes: un problema estructural, un estándar propuesto y una parte suficiente del ecosistema comprometida a construir sobre él desde el primer día.

Para la gestión del césped y de instalaciones deportivas, el paralelismo es más cercano de lo que el marco del software empresarial podría sugerir, no a nivel del agente de IA, al que esta industria aún no ha llegado, sino en la capa de datos, en la que está trabajando ahora mismo.

Un campo de golf o una instalación deportiva bien equipados en 2026 utilizan una estación meteorológica en su propia plataforma, una flota de cortacéspedes robóticos en una segunda, sensores de suelo en una tercera y un controlador de riego en una cuarta. Los registros de aplicación viven en otro lugar: una hoja de cálculo, una aplicación independiente o un cuaderno en papel en el taller de mantenimiento. En principio, parte de estos datos podrían fluir entre sistemas. En la práctica, conectarlos requiere trabajo de integración a medida, mantenimiento continuo y depende de proveedores con poco incentivo comercial para hacer más útiles los datos de sus competidores. El greenkeeper sigue siendo la capa de integración, no entre agentes de IA, sino entre plataformas de datos.

Este no es el problema de los agentes de IA. La gestión del césped aún no ha desplegado agentes de IA como lo ha hecho el software empresarial. La industria se enfrenta a un reto anterior y más inmediato: lograr que la capa de datos del IoT se hable a sí misma. Pero el problema estructural es idéntico al que A2A está diseñado para prevenir a nivel de agente. Silos propietarios. Formatos de datos incompatibles. Ningún estándar acordado sobre cómo se comunican las partes. La persona que se interpone entre ellas haciendo la traducción.

El problema de la puesta en producción

Junto al anuncio de A2A, Gartner publicó una cifra que está circulando por la industria de la IA: entre el 86 y el 89 % de los programas piloto de agentes de IA no han llegado a producción a escala.

Esa cifra suele leerse como un comentario sobre la madurez de la IA, como si la tecnología no fuera todavía lo bastante fiable. Yo creo que describe algo más estructural: un problema de fragmentación. La mayoría de los pilotos de IA empresarial que fracasan en producción no lo hacen porque el razonamiento fuera erróneo, sino porque la salida de un sistema no tiene un mecanismo estándar para pasar al siguiente. Sin protocolo compartido. Sin formato acordado. Alguien tiene que mediar la transferencia de forma manual, a intervalos, y la información llega demasiado tarde para ser útil.

Las operaciones de césped reconocerán la forma de este problema, aunque la capa tecnológica sea distinta. Una plataforma meteorológica que no puede exportar directamente a una herramienta de planificación nutricional. Un panel de sensores de suelo sin conexión nativa con el controlador de riego. Un registro de aplicaciones que vive en un entorno separado del modelo de riesgo de enfermedad que debería leerlo. El problema de arquitectura es el mismo. La capa en la que aparece es diferente.

La forma de este problema resulta familiar a partir de la propia experiencia de la agricultura de precisión hace una década. Los sensores funcionaban. Las máquinas funcionaban. Los formatos de datos eran incompatibles. El operador era la capa de integración.

La transición a ISOBUS no se produjo porque las máquinas mejoraran. Se produjo porque la industria acordó una gramática y, una vez que esa gramática existió, cada nuevo apero podía participar en ella sin necesidad de una integración a medida.

A2A propone la misma gramática para los agentes de IA. No un modelo compartido, no una plataforma compartida, sino un protocolo compartido. La distinción importa, porque significa que los agentes pueden proceder de distintos proveedores, ejecutarse sobre distintos modelos subyacentes y aun así comunicarse dentro de una arquitectura gobernada.

La pregunta que esto plantea a las operaciones

Para un director agronómico o un responsable de operaciones que evalúa tecnología, la versión relevante de la pregunta A2A no es aún sobre agentes de IA. Es sobre datos.

¿Se conecta esta plataforma con las demás plataformas de mi operación, o crea otro silo? ¿Exporta datos en formatos abiertos, o encierra mis registros operativos (registros de aplicación, lecturas de suelo, datos de crecimiento) dentro de un entorno propietario? ¿Puedo mover mis datos si cambio de proveedor, o he entregado el control de los mismos junto con el contrato?

Estas son las preguntas que el sector del césped está resolviendo ahora, en la capa de datos y API. A2A es la misma pregunta resolviéndose un nivel por encima en el software empresarial: cuando los agentes de IA se conviertan en la interfaz principal, ¿se comunicarán mediante estándares abiertos, o cada proveedor levantará muros alrededor de sus agentes, igual que los fabricantes de equipos levantaron muros en su día alrededor de sus protocolos de aperos?

Las dos preguntas están relacionadas. Las decisiones arquitectónicas que se tomen ahora en la capa de datos determinarán con qué facilidad podrá construirse encima una capa de inteligencia. Una plataforma que encierra sus registros operativos en una base de datos propietaria está creando, un nivel más arriba, la misma restricción que un fabricante de aperos pre-ISOBUS. El coste de la adaptación posterior llega más tarde, cuando cambiar se ha vuelto caro y mover los datos es más difícil.

Antes de ISOBUS, los fabricantes de equipos tenían razones comerciales para mantener sus protocolos como propietarios. Un estándar de comunicación cerrado significaba clientes cautivos. El paso a estándares abiertos fue resistido, luego adoptado gradualmente y después se convirtió en requisito previo para participar en el mercado. La misma dinámica está en marcha ahora en la infraestructura de IA, y en las plataformas de datos agronómicos que se asentarán bajo ella.

La prueba práctica se aplica en ambas capas: ¿pueden las plataformas que está utilizando compartir datos entre sí sin que su equipo medie la transferencia? Si no, si el greenkeeper sigue siendo el nexo entre la estación meteorológica, el sensor de suelo y el registro de aplicaciones, tiene componentes competentes. Todavía no tiene un sistema. Y está construyendo sobre cimientos que limitarán cada capa de inteligencia que venga después.

Por qué merece la pena prestar atención ahora

Las decisiones sobre protocolos rara vez son titulares. Se deciden en grupos de trabajo y comités técnicos y se anuncian en notas de prensa que la mayoría de los profesionales nunca leen. Son, de forma sistemática, las decisiones que determinan qué hará posible la próxima década de innovación.

Pero la lección de ISOBUS, y de cada momento normativo comparable en la agricultura de precisión, es que la decisión sobre el protocolo es la que da forma a todo lo que se construye encima. Los aperos diseñados antes de ISOBUS requirieron costosas adaptaciones o sustituciones. Los diseñados después podían participar en un ecosistema conectado desde el primer día.

La capa de inteligencia de su operación: la capacidad de conectar una lectura meteorológica con una condición de suelo, con una decisión de aplicación, con un resultado observado. Se construirá sobre decisiones de infraestructura que se están tomando ahora. A qué plataformas se compromete. Si sus datos operativos son suyos para moverlos o están atados a un proveedor. Si la arquitectura que está construyendo hoy deja espacio para una capa de inteligencia conectada, o la cierra de antemano.

A2A no aparecerá en la prensa especializada del césped. No describe dónde está actualmente este sector. Pero describe, con precisión, el problema de arquitectura que toda capa de tecnología operativa termina teniendo que resolver. Lleva la lección que ISOBUS ya entregó una vez: acertar con el protocolo antes de que el ecosistema se cierre en torno al equivocado.

La pregunta que merece la pena hacerse ahora no es «¿qué herramienta da los mejores datos?». Es: cuando llegue la capa de inteligencia, ¿estará su operación lista para participar en ella, o pasará los próximos tres años haciendo adaptaciones?

Referencia: el protocolo A2A y el Agent Gateway se anunciaron en Google Cloud Next '26, Las Vegas, el 22 de abril de 2026. Fuentes: Resumen de Google Cloud Next '26 · Kai Waehner, Enterprise Agentic AI Landscape 2026