Conseguir que diferentes sistemas de software se comuniquen entre sí es un reto clásico para los desarrolladores. Durante años hemos utilizado API con reglas bien definidas para conseguirlo. Pero ahora, los grandes modelos lingüísticos (LLM) están cambiando las reglas del juego, ofreciendo una nueva forma de que los sistemas interactúen basándose en la comprensión del lenguaje, no sólo en formatos estrictos. Esto abre posibilidades apasionantes, pero también presenta una nueva serie de problemas por resolver, lo que demuestra una vez más que el trabajo de un desarrollador nunca termina del todo.
Veamos qué significa esto para los desarrolladores.
Cómo solíamos conectar los sistemas: API tradicionales
Piensa en cómo solemos conectar los sistemas. Usamos cosas como:
- API REST: A menudo utilizando JSON, tal vez con una especificación OpenAPI (Swagger), las API detallan exactamente qué datos entran y salen de un sistema, incluidos los tipos de datos (como cadenas o números).
- RPC (Remote Procedure Call): Herramientas como gRPC permiten a los sistemas llamar a funciones entre sí a través de elementos como los búferes de protocolo para definir exactamente lo que una función necesita y devuelve.
- SOAP/WSDL: Es un método más antiguo, pero también se basa en una descripción detallada (WSDL) del servicio.
- Colas de mensajes (por ejemplo, Kafka, RabbitMQ): Estos sistemas envían mensajes de un lado a otro, normalmente siguiendo un formato específico acordado.
La clave es que estos métodos se basan en reglas y formatos explícitos. Las máquinas comprueban si los datos coinciden con la estructura predefinida (el esquema o la definición de tipo). Los desarrolladores leen la documentación para entender qué hacen las API y luego escriben el código para llamarlas en el orden que necesitan, procesando los datos que devuelven. Es un baile que los desarrolladores llevan haciendo desde la aparición de la informática.
Paradigmas emergentes: MCP, marcos de agentes y API mejoradas con prompts
El paso de las API tradicionales rígidamente definidas a las interacciones fluidas y basadas en el lenguaje de los LLM no siempre es un salto directo al lenguaje natural puro y sin restricciones para cada componente del sistema. En su lugar, estamos asistiendo al surgimiento de potentes paradigmas y marcos intermedios diseñados para salvar esta distancia, permitiendo que los sistemas existentes y los nuevos servicios sean "consumibles por LLM".
En el corazón de estos enfoques emergentes se encuentra el concepto de APIs aumentadas por prompt. En lugar de exigir a un LLM que intuya la funcionalidad desde cero, o a un desarrollador que escriba un complejo código adaptador, "decoramos" o "envolvemos" nuestras API -ya sean venerables servicios REST o nuevos puntos finales gRPC- con ricas descripciones en lenguaje natural. Estas descripciones actúan como un manual de usuario específico para un LLM, explicando el propósito de la API, cómo llamarla, qué parámetros espera (y en qué formato) y qué devuelve.
El Protocolo de Contexto de Modelo (MCP), por ejemplo, ejemplifica una forma más estructurada de exponer un conjunto diverso de capacidades a un plano de control basado en LLM. Los sistemas pueden declarar sus servicios y las acciones que soportan, junto con metadatos y descripciones en lenguaje natural. A continuación, un LLM puede consultar este "menú" de capacidades declaradas y orquestar llamadas a estos servicios subyacentes en función de las peticiones de los usuarios o de objetivos de nivel superior, comprendiendo lo que hacen y cómo utilizarlos a través de sus interfaces declaradas, similares a las instrucciones.
Esto está estrechamente relacionado con la rápida evolución del mundo de los marcos de agentes. Estos marcos a menudo proporcionan el andamiaje para construir un Agente controlador primario impulsado por LLM. Este agente central actúa como orquestador o "cerebro", capaz de razonar, planificar y delegar tareas. El verdadero poder viene cuando a este Agente controlador se le da acceso a un conjunto de "herramientas" o sub-agentes.
Estos subagentes pueden variar considerablemente:
- Algunos podrían ser otros agentes especializados basados en LLM, diseñados para tareas específicas como el análisis de datos complejos o la generación de contenidos creativos.
- Otros pueden ser módulos de software más sencillos o, sobre todo, envoltorios de API tradicionales ya existentes. En este caso, un desarrollador crea una envoltura ligera alrededor de, por ejemplo, una API interna de gestión de pedidos. Esta envoltura no se limita a exponer los puntos finales técnicos, sino que incluye mensajes cuidadosamente elaborados que describen las funciones de la API en lenguaje natural: "Esta herramienta le permite consultar el estado de un pedido. Requiere un 'order_id' como entrada y devolverá el estado actual, la fecha estimada de entrega y los artículos del pedido".
El hilo conductor de estos paradigmas está claro: la API, ya sea un nuevo microservicio o un sistema heredado expuesto a través de una envoltura, ya no es sólo un contrato técnico. Se complementa con una capa de instrucciones descriptivas. Esto permite a un LLM consumidor (normalmente un agente controlador) descubrir, comprender y utilizar dinámicamente una amplia gama de herramientas y capacidades. El LLM no necesita conocer los intrincados detalles de implementación de cada herramienta; sólo necesita entender la descripción basada en indicaciones de cómo utilizarla. Este cambio modifica radicalmente nuestra forma de pensar sobre la integración de sistemas y pone un énfasis aún mayor en la claridad, precisión y exhaustividad de estas indicaciones descriptivas, que analizaremos más adelante.
El futuro es... diferente
Pasar de unas API estrictas, basadas en formatos, e incluso de estas interfaces emergentes aumentadas por avisos, a unas interacciones verdaderamente generalizadas basadas en el lenguaje con los LLM es un gran cambio. Como desarrollador, me he acostumbrado a tener una definición clara de las posibles entradas, salidas y mensajes de error. Trabajar con LLMs aporta una enorme cantidad de capacidades que nunca habíamos tenido. Pero también está a punto de redefinir la forma de interactuar con otros sistemas. Como desarrolladores, cada vez es más importante comprender cómo elaborar instrucciones precisas y completas para describir las capacidades, especialmente a medida que construimos sistemas en los que varios agentes de IA pueden tener que colaborar.
Comentarios