En los artículos anteriores hemos construido progresivamente la idea de qué es un agente de IA y cómo funciona. Ya conocemos sus diferentes niveles de autonomía, las herramientas que puede utilizar, la importancia de la memoria, los frameworks disponibles y la forma de escribir instrucciones más efectivas. También vimos los errores más comunes que pueden aparecer durante su desarrollo.
Ahora podemos dar un paso importante: hacer que nuestro agente se comunique con otros sistemas.
Un modelo de inteligencia artificial, por sí solo, trabaja principalmente con la información que recibe en su contexto. Puede analizar texto, generar respuestas, razonar sobre un problema y tomar decisiones, pero eso no significa que tenga acceso directo a todos los servicios disponibles en internet.
Si queremos que un agente consulte el clima, revise el inventario de una empresa, obtenga información de una base de datos, consulte un servicio de mapas o envíe información a otra aplicación, necesitamos proporcionarle mecanismos para comunicarse con esos sistemas.
Una de las formas más importantes de hacerlo es mediante las APIs, interfaces que permiten que diferentes programas intercambien información.
1. ¿Qué es una API?
API significa Application Programming Interface, o interfaz de programación de aplicaciones.
Aunque el nombre puede parecer complicado, la idea fundamental es bastante sencilla: una API permite que un programa solicite información o ejecute determinadas operaciones en otro sistema siguiendo unas reglas establecidas.
Por ejemplo, imaginemos una aplicación de clima.
Una persona puede abrir una aplicación, seleccionar una ciudad y observar la temperatura. Pero internamente la aplicación necesita obtener esos datos desde algún lugar.
La aplicación puede realizar una solicitud a una API de clima indicando una ubicación. El servidor procesa la solicitud y devuelve información que la aplicación puede utilizar.
El usuario solamente ve el resultado, pero detrás existe una comunicación entre diferentes sistemas.
Un agente de IA puede participar en este proceso.
En lugar de que una persona tenga que introducir manualmente todos los datos en una aplicación, el agente puede interpretar una solicitud y utilizar una API para obtener la información necesaria.
2. ¿Por qué un agente necesita APIs?
Las APIs permiten que un agente deje de trabajar únicamente con información interna y pueda interactuar con servicios externos.
Imaginemos que un usuario pregunta:
"¿Cuál es el precio actual de este producto?"
Si el agente solamente tiene su modelo de lenguaje, probablemente no conoce el precio actual.
Pero podemos darle acceso a una API del sistema de inventario.
El proceso podría ser:
El usuario realiza una pregunta.
El agente interpreta que necesita información actualizada.
El agente identifica la herramienta correspondiente.
La herramienta realiza una solicitud a la API.
La API devuelve los datos.
El agente interpreta la respuesta.
Finalmente, el agente responde al usuario.
De esta manera, el modelo no necesita conocer directamente todos los sistemas externos. Solamente necesita saber cuándo y cómo utilizar las herramientas disponibles.
3. La API como puente entre sistemas
Podemos pensar en una API como un puente.
Por un lado tenemos nuestro agente de IA.
Por el otro tenemos un sistema externo.
Ese sistema podría ser una plataforma de comercio electrónico, una base de datos, un servicio meteorológico, un sistema empresarial o incluso un dispositivo conectado a internet.
La API define cómo se realiza la comunicación.
Esto es importante porque el agente no necesita conocer cómo está construido internamente el sistema externo.
Por ejemplo, nuestro agente podría consultar un sistema de inventario sin saber cómo está programada su base de datos.
Solamente necesita utilizar el endpoint correspondiente y proporcionar los parámetros requeridos.
Esta separación permite construir sistemas mucho más flexibles.
4. ¿Qué es un endpoint?
Cuando trabajamos con APIs aparece frecuentemente el concepto de endpoint.
Un endpoint es una dirección específica que permite acceder a una determinada función o recurso de una API.
Por ejemplo, imaginemos una API de una tienda.
Podría tener un endpoint para consultar productos:
/productos
Otro para consultar un producto específico:
/productos/25
Y otro para registrar una compra:
/compras
Cada endpoint representa una operación o recurso determinado.
El agente no necesita conocer necesariamente todos los endpoints disponibles. Lo ideal es proporcionarle solamente aquellos que realmente necesita.
Esto también ayuda a mantener el sistema más seguro.
5. Métodos HTTP
Las APIs web suelen utilizar HTTP para comunicarse.
Entre los métodos más conocidos encontramos:
GET: solicitar información.
POST: enviar información o crear un recurso.
PUT: actualizar información.
PATCH: modificar parcialmente un recurso.
DELETE: eliminar un recurso.
Por ejemplo, si nuestro agente necesita consultar información sobre un producto, probablemente utilizará una solicitud GET.
Si necesita registrar una nueva operación, podría utilizar POST.
Esta distinción es importante porque no todas las solicitudes tienen el mismo nivel de riesgo.
Consultar información normalmente es menos peligroso que modificarla o eliminarla.
Por esta razón, cuando diseñamos herramientas para agentes autónomos debemos tener especial cuidado con los métodos que permiten modificar información.
6. Las respuestas normalmente utilizan JSON
Una de las formas más utilizadas para intercambiar información mediante APIs es JSON.
JSON permite representar información estructurada de una manera relativamente sencilla.
Una API podría responder algo parecido a:
{
"producto": "Sensor de temperatura",
"precio": 450,
"disponible": true
}El programa puede interpretar esta información y utilizar los diferentes campos.
El agente podría recibir estos datos y convertirlos en una respuesta comprensible para el usuario.
Por ejemplo:
"El sensor de temperatura tiene un precio de 450 pesos y actualmente está disponible."
Aquí podemos observar nuevamente la separación entre sistemas.
La API proporciona información estructurada y el agente utiliza el modelo de IA para convertir esa información en una respuesta natural.
7. Parámetros: decirle a la API qué necesitamos
Muchas APIs necesitan recibir información adicional para saber qué debe buscar o modificar.
Estos datos se conocen como parámetros.
Por ejemplo, una API de clima puede necesitar una ciudad.
Una API de productos puede necesitar un identificador.
Una API de mapas puede necesitar coordenadas.
Un agente puede obtener estos datos a partir de una conversación.
Si un usuario escribe:
"¿Cómo está el clima en Ciudad de México?"
el agente puede identificar que necesita consultar un servicio meteorológico y que el parámetro principal es la ubicación.
Después puede construir la solicitud correspondiente.
Esta capacidad es especialmente interesante porque el usuario no necesita conocer la estructura técnica de la API.
Puede hablar normalmente con el agente mientras este se encarga de convertir la solicitud en parámetros que el sistema externo pueda comprender.
8. Autenticación y claves API
Muchas APIs no permiten que cualquier persona realice solicitudes.
Para controlar el acceso utilizan mecanismos de autenticación.
Uno de los métodos más comunes consiste en utilizar una API key, una clave que identifica y autoriza a una aplicación.
Por ejemplo, un servicio puede exigir que cada solicitud incluya una clave determinada.
Sin embargo, existe un error muy importante que debemos evitar: guardar las claves directamente dentro del código que se publica.
Nunca deberíamos hacer algo como:
API_KEY = "mi-clave-secreta"
en un repositorio público.
Si alguien obtiene esa clave podría utilizar nuestro acceso al servicio.
Una alternativa mucho mejor consiste en utilizar variables de entorno o mecanismos seguros para almacenar credenciales.
Por ejemplo, nuestro programa puede leer la clave desde una variable configurada en el servidor.
De esta manera, el código puede compartirse sin revelar las credenciales.
9. El agente no debería recibir todas las credenciales
Otro principio importante es separar al agente de las credenciales siempre que sea posible.
El modelo de IA no necesita conocer una API key para utilizar una herramienta.
El sistema que ejecuta la herramienta puede encargarse de manejar la autenticación.
El flujo sería:
El agente decide utilizar una herramienta.
La herramienta recibe los parámetros necesarios.
El código añade las credenciales de forma segura.
La solicitud se envía a la API.
La respuesta vuelve al agente.
De esta forma, la información sensible permanece fuera del contexto del modelo.
Esta arquitectura también facilita cambiar una clave sin tener que modificar las instrucciones del agente.
10. Crear una herramienta que consulte una API
Supongamos que tenemos una API que proporciona información sobre productos.
Nuestro agente podría disponer de una herramienta llamada:
buscar_producto
Esta herramienta recibiría un identificador.
Internamente realizaría una solicitud HTTP a la API.
El servidor respondería con JSON.
Finalmente, la herramienta devolvería los datos relevantes al agente.
Desde el punto de vista del modelo, la herramienta podría verse conceptualmente así:
buscar_producto(id_producto)
El modelo no necesita preocuparse por detalles como la URL completa, la clave de autenticación o la estructura interna del servidor.
Esos detalles pertenecen a la implementación de la herramienta.
Esto permite mantener una separación clara entre el razonamiento del agente y la comunicación técnica con los servicios externos.
11. El ciclo completo de un agente utilizando una API
Ahora podemos combinar los conceptos anteriores.
Supongamos que el usuario pregunta:
"¿Cuántas unidades del sensor X tenemos disponibles?"
El agente recibe la pregunta y determina que necesita información externa.
Primero identifica la herramienta que permite consultar inventario.
Después obtiene el identificador del producto.
A continuación utiliza la herramienta.
La herramienta realiza una solicitud GET al endpoint correspondiente.
La API procesa la solicitud.
El servidor devuelve una respuesta JSON.
La herramienta procesa los datos.
El agente recibe el resultado.
Finalmente, el modelo genera una respuesta para el usuario.
Todo esto puede ocurrir en unos cuantos segundos.
Lo importante es entender que el modelo no está consultando directamente la API. El agente utiliza una herramienta que realiza esa comunicación.
12. Manejar errores de las APIs
Las APIs no siempre funcionan correctamente.
Puede ocurrir que el servidor esté temporalmente fuera de servicio, que el usuario no tenga autorización, que los parámetros sean incorrectos o que el recurso solicitado no exista.
Por eso nuestro agente debe estar preparado para estas situaciones.
Por ejemplo, una API puede devolver un código HTTP indicando que el recurso no fue encontrado.
Otro código puede indicar que no existe autorización suficiente.
También puede existir un error interno del servidor.
El agente debería recibir información suficiente para distinguir estas situaciones.
Si el producto no existe, puede informarlo al usuario.
Si el servicio está temporalmente fuera de línea, puede indicar que no pudo obtener la información.
Lo que no debería hacer es inventar una respuesta.
Este punto conecta directamente con el artículo anterior: los errores de las herramientas deben estar contemplados dentro del diseño del agente.
13. APIs de lectura y APIs de acción
No todas las APIs tienen el mismo nivel de riesgo.
Podemos distinguir de manera general entre APIs utilizadas principalmente para consultar información y APIs que permiten realizar acciones.
Por ejemplo, consultar el estado de un sensor es una operación de lectura.
Cambiar remotamente el estado de una válvula es una operación de acción.
Enviar un correo también es una acción.
Realizar una compra es otra acción.
Esta diferencia es especialmente importante cuando diseñamos agentes autónomos.
Podemos permitir que un agente consulte información libremente, mientras que determinadas acciones necesitan confirmación humana.
Por ejemplo:
"El agente puede consultar inventario automáticamente, pero debe pedir autorización antes de realizar una compra."
Este tipo de regla reduce considerablemente el riesgo de acciones inesperadas.
14. APIs y agentes para automatización
Una de las aplicaciones más interesantes de esta tecnología es la automatización.
Supongamos que una empresa recibe solicitudes constantemente.
Una persona podría revisar una solicitud, consultar información en un sistema, comprobar determinados datos y posteriormente actualizar otro sistema.
Un agente puede encargarse de coordinar este proceso.
Podría recibir la solicitud en lenguaje natural, consultar una API, analizar los datos, realizar una segunda consulta y generar un resultado.
Esto permite automatizar procesos que anteriormente requerían múltiples pasos manuales.
Sin embargo, la automatización debe diseñarse cuidadosamente.
El hecho de que una acción pueda automatizarse no significa que deba automatizarse completamente.
Las operaciones importantes pueden requerir validación humana.
15. Un ejemplo con IoT
Los agentes conectados con APIs son especialmente interesantes para proyectos de IoT.
Imaginemos una empresa que tiene varios dispositivos conectados.
Cada dispositivo envía información como temperatura, presión, humedad o estado de conexión a un servidor.
Nuestro agente puede utilizar una API para consultar esos datos.
Un usuario podría preguntar:
"¿Hay algún dispositivo con una temperatura fuera del rango normal?"
El agente puede consultar los sensores, analizar los resultados y detectar anomalías.
Después podría responder:
"El dispositivo 14 presenta una temperatura de 87 °C, superior al límite configurado."
Incluso podríamos darle acceso a otra herramienta que permita generar una alerta.
En este escenario tenemos una combinación muy interesante:
IoT + API + agente de IA + automatización.
El dispositivo genera datos, la API los proporciona, el agente los interpreta y el sistema puede ejecutar una acción.
16. APIs de terceros
No siempre necesitamos desarrollar nuestras propias APIs.
Existen numerosos servicios externos que ofrecen APIs para diferentes funciones.
Podemos encontrar APIs relacionadas con mapas, clima, pagos, comunicación, búsqueda de información, almacenamiento, comercio electrónico, análisis de datos y muchas otras aplicaciones.
Esto permite construir agentes con capacidades bastante avanzadas sin tener que desarrollar cada servicio desde cero.
Por ejemplo, un agente podría utilizar una API de mapas para calcular una ruta y después utilizar otra API para consultar información de un establecimiento.
El agente actúa como una especie de coordinador entre diferentes servicios.
Sin embargo, debemos revisar cuidadosamente las condiciones de uso, límites de solicitudes, costos y requisitos de autenticación de cada servicio.
17. Límites y costos de las APIs
Las APIs pueden tener límites de uso.
Un servicio puede permitir determinada cantidad de solicitudes durante un periodo de tiempo.
Si nuestro agente realiza demasiadas solicitudes, podríamos superar ese límite.
Además, algunas APIs tienen costos asociados.
Esto significa que un agente mal diseñado podría generar gastos inesperados si realiza demasiadas llamadas.
Por esta razón es importante controlar cuántas solicitudes realiza.
También podemos utilizar memoria, almacenamiento temporal o cachés cuando no sea necesario consultar nuevamente la misma información.
Un agente eficiente no solamente debe producir buenos resultados. También debe utilizar los recursos de manera razonable.
18. Evitar que el agente llame una API innecesariamente
Otro problema frecuente consiste en permitir que el agente consulte servicios externos incluso cuando no es necesario.
Supongamos que el usuario pregunta:
"¿Qué es una API?"
No necesitamos consultar una API externa para responder una definición básica.
Pero si pregunta:
"¿Cuál es el precio actual del producto 124?"
entonces sí puede ser necesario realizar una consulta.
Las herramientas deben utilizarse cuando aportan información o capacidades que el modelo no puede obtener por sí mismo.
Esto mejora el rendimiento y reduce costos.
También disminuye la posibilidad de errores provocados por servicios externos.
19. Diseñar herramientas fáciles de entender
Cuando un agente tiene acceso a una API, no es recomendable simplemente entregarle una gran cantidad de endpoints técnicos.
Es mejor crear herramientas con nombres y descripciones claras.
Por ejemplo:
consultar_inventario
puede ser mucho más fácil de interpretar que exponer directamente una dirección técnica complicada.
La descripción también debe explicar cuándo debe utilizarse.
Por ejemplo:
"Consulta la cantidad disponible de un producto. Utiliza esta herramienta cuando el usuario solicite información actualizada sobre existencias."
Una herramienta bien diseñada facilita que el agente tome mejores decisiones.
Esto demuestra nuevamente que la ingeniería de agentes no consiste solamente en elegir un buen modelo. El diseño de las herramientas también es fundamental.
20. Un ejemplo completo de arquitectura
Imaginemos ahora un sistema empresarial.
El usuario conversa con el agente mediante una aplicación web.
El agente recibe una solicitud.
El modelo analiza qué necesita.
Después decide utilizar la herramienta consultar_inventario.
La herramienta recibe el identificador del producto.
El código realiza una solicitud HTTP a la API empresarial.
La API consulta la base de datos.
El servidor devuelve información en formato JSON.
La herramienta procesa la respuesta.
El agente recibe los datos.
Finalmente genera una respuesta para el usuario.
Si el usuario posteriormente solicita realizar una compra, el sistema puede utilizar otra herramienta.
Pero esa segunda herramienta puede requerir confirmación.
De esta manera, el agente puede coordinar diferentes operaciones manteniendo controles de seguridad.
21. APIs, herramientas y agentes: no son lo mismo
Es importante no confundir estos tres conceptos.
Una API es una interfaz que permite comunicarse con un sistema.
Una herramienta es una función que el agente puede utilizar para realizar una operación.
Un agente es el sistema que utiliza el modelo, las instrucciones, las herramientas, la memoria y la lógica de ejecución para resolver una tarea.
Por ejemplo:
La API proporciona acceso al inventario.
La herramienta consultar_inventario utiliza esa API.
El agente decide cuándo necesita utilizar consultar_inventario.
Cada componente tiene una función diferente.
Esta separación facilita el mantenimiento del sistema y permite cambiar una parte sin tener que reconstruir todo.
22. ¿Qué hemos conseguido al conectar una API?
Antes de utilizar herramientas externas, nuestro agente podía analizar información que ya estaba disponible dentro de su contexto.
Después de conectarlo con APIs, puede acceder a información actualizada y comunicarse con sistemas externos.
Esto cambia considerablemente sus posibilidades.
Ahora puede consultar datos reales, verificar información, registrar operaciones, enviar solicitudes y coordinar diferentes servicios.
En otras palabras, el agente comienza a pasar de ser solamente un sistema que genera información a convertirse en un sistema que interactúa con otros sistemas.
Esta es una de las características que hacen que los agentes sean especialmente interesantes para la automatización.
Conclusiones
Las APIs son uno de los componentes fundamentales para conectar agentes de IA con el mundo exterior. Permiten que un agente consulte información actualizada, interactúe con servicios externos y ejecute acciones mediante herramientas diseñadas específicamente para cada operación.
Para construir una integración adecuada debemos comprender conceptos como endpoints, métodos HTTP, parámetros, respuestas JSON y autenticación. También debemos controlar errores, credenciales, límites de uso y permisos.
La combinación entre agentes, herramientas y APIs abre la puerta a aplicaciones mucho más avanzadas. Un agente puede consultar un sistema empresarial, analizar información y coordinar diferentes servicios sin que el usuario tenga que conocer todos los detalles técnicos que existen detrás.
En el artículo 11 iremos un paso más allá: veremos cómo crear agentes con acceso a internet y búsqueda web en tiempo real, permitiendo que puedan encontrar información actualizada cuando sus conocimientos internos no sean suficientes.
Anterior Siguiente