Agent Builder, más allá del chat: presentamos la infraestructura aumentada

Esto no es una especulación. Es un hecho.

Todos somos testigos del auge de los agentes de IA. Son fantásticos para resumir texto, escribir fragmentos de código y responder preguntas basadas en la documentación. Pero para quienes trabajamos en DevOps y en ingeniería de confiabilidad de sitios (SRE), existe una limitación frustrante. La mayoría de los agentes están atrapados en el paradigma del centro de llamadas, lo que significa que pueden leer, pensar y chatear, pero no pueden interactuar con la infraestructura que se supone que deben administrar.

Para nuestro último proyecto de hackathon, decidimos superar esa limitación.

Desarrollamos infraestructura aumentada: un copiloto de infraestructura que no solo te da consejos, sino que también crea, despliega, monitorea y corrige el entorno en vivo.

El problema: copiar, reformatear, pegar

Los agentes estándar operan en el vacío. Si una app se cae y le cuesta a la compañía $5 millones, un agente estándar puede leerte el libro de apuntes sobre cómo arreglarlo. Pero sigue siendo tu responsabilidad hacer el trabajo. Ahora solo tienes que copiar el código, adaptarlo al entorno y pegarlo en tu terminal.

Queríamos crear un agente que entendiera la diferencia entre hablar de Kubernetes y configurar Kubernetes.

El motor: ¿Qué es Elastic Agent Builder?

Para desarrollarlo no empezamos desde cero. Partimos de Elastic Agent Builder. Para quienes no lo conozcan, Elastic Agent Builder es un marco de trabajo diseñado para desarrollar agentes de forma rápida, y actúa como puente entre un gran modelo de lenguaje (LLM) (en nuestra demo usamos Google Gemini) y los datos privados almacenados en Elasticsearch.

Agent Builder se puede usar para la IA conversacional si se lo basa en datos internos, como documentos o registros. Pero su característica más poderosa es la capacidad de asignar herramientas. Estas herramientas permiten al LLM salir de la interfaz de chat para realizar tareas específicas. Nos dimos cuenta de que si llevábamos esta característica al límite, podíamos transformar Agent Builder en una potencia de automatización.

Cómo hacerlo funcionar: desarrollo de la primera versión

Cuando empezamos el proyecto, sabíamos que queríamos que los agentes pudieran cambiar el mundo exterior. Pensamos lo siguiente: ¿y si construimos algún software “runner” (para ejecutar cualquier comando que el agente pueda pensar en el host)? Y luego: ¿qué pasaría si los runners, Elastic Agent Builder y el usuario estuvieran en una llamada los tres?

Empezamos desarrollando un proyecto en Python, Augmented Infrastructure Runners, que era esencialmente un bucle de while(true) que consultaba la API de conversaciones de Elastic Agent Builder cada segundo y verificaba una sintaxis especial que habíamos creado:

Luego actualizamos la indicación para enseñarle sobre nuestra nueva sintaxis de llamada de herramienta. Bill es uno de los mantenedores de FastMCP, el marco de trabajo más popular para crear servidores del Protocolo de Contexto de Modelo (MCP) en Python. Se propuso trabajar usando el cliente FastMCP con este nuevo software runner para montar servidores MCP y poner sus herramientas a disposición del runner. Cuando el agente veía esto, ejecutaba la llamada a la herramienta y POST enviaba los resultados de vuelta a la conversación como si el usuario hubiera enviado los resultados. Esto hizo que el LLM respondiera al resultado, ¡y seguimos adelante!

Fue genial, pero tuvo dos problemas principales:

1. El agente soltaba todo este JSON directamente a la conversación con el usuario.
2. El primer momento en el que los mensajes se podían ver a través de la API de conversaciones era cuando se completaba una ronda de conversación (es decir, cuando el LLM respondía).

Así que nos propusimos descubrir cómo llevarlo a segundo plano.

Luego probamos darle al agente una herramienta llamada call_external_tool con dos argumentos: el argumento de la herramienta tool_name y la herramienta JSON en strings. Esta llamada a la herramienta externa no devolvía nada, pero lo importante es que era visible en la solicitud GET a la API de conversaciones. Luego dimos licencia a los runners para escribir documentos directamente en Elasticsearch, los cuales el agente de Elastic Agent Builder podía recuperar según fuera necesario. El agente siempre está operando en respuesta a un mensaje del usuario, por lo que necesitamos iniciar el agente con un mensaje del usuario para que busque resultados y continúe con el procesamiento. Así que hicimos que los agentes insertaran un pequeño mensaje en el chat para reanudar la conversación:

Así que ya teníamos llamadas a herramientas externas. Sin embargo, debido al segundo problema mencionado anteriormente, tuvimos que deshacernos de esa parte final de arranque. De lo contrario, ¡cada llamada a una herramienta externa requería una ronda completa de conversación para recuperar los resultados!

Llevarlo a otro nivel: introducción a los flujos de trabajo

Además de las llamadas al lenguaje de búsqueda de Elasticsearch (ES|QL) y a las herramientas de búsqueda de índices, los agentes de Agent Builder pueden llamar a herramientas basadas en flujo de trabajo de Elastic. Los flujos de trabajo de Elastic ofrecen una forma flexible y fácil de gestionar para ejecutar una secuencia y una lógica de acciones arbitrarias. Para nuestros objetivos, todo lo que necesitamos que haga el flujo de trabajo es almacenar una solicitud externa de herramienta en Elasticsearch y devolver un ID para consultar los resultados. Esto da lugar a la siguiente definición sencilla de flujo de trabajo:

Con eso, en lugar de depender de que la solicitud de llamada a la herramienta se escriba en la conversación, los runners pueden simplemente consultar el índice de distributed-tool-requests de Elasticsearch para nuevas solicitudes externas de herramienta y hacer el reporte de los resultados en otro índice de Elasticsearch con la execution.id proporcionada.

Esto elimina los dos problemas principales mencionados anteriormente:

1. El historial de conversaciones ya no está lleno de datos de las llamadas a herramientas externas.
2. Como los runners consultan el índice de Elasticsearch en lugar del historial de conversaciones, no están bloqueados por la ronda de conversación que debe completarse para que las solicitudes de herramientas externas se hagan visibles.

El segundo punto tiene la gran ventaja de que el procesamiento de las llamadas a herramientas externas comienza dentro de la fase de pensamiento del agente (y no cuando se ha completado la ronda de conversación). Esto nos permite indicarle al modelo de lenguaje grande (LLM) en la indicación del sistema que consulte los resultados de la herramienta externa hasta que estén disponibles, lo que elimina la necesidad del mensaje de inicio. En general, esto tiene el efecto positivo de que la conversación se siente más natural: el LLM puede procesar varias solicitudes de herramienta externa dentro de una sola ronda de conversación (en vez de requerir una ronda de conversación por cada solicitud de herramienta) y, por tanto, puede realizar solicitudes de usuario más complejas de una sola vez.

Todo integrado

Para cerrar la brecha entre el LLM y el rack de servidores, desarrollamos una arquitectura específica empleando las capacidades de la herramienta de Agent Builder:

1. Runners de infraestructura aumentada: desplegamos runners ligeros dentro de los entornos de destino (servidores, clústeres de Kubernetes, cuentas en la cloud). Estos runners se conectan directamente a Elastic, utilizando endpoints seguros y secretos solo disponibles para cada uno de los runners.
2. ES|QL retrieval: el copiloto utiliza ES|QL de Elastic para realizar búsquedas híbridas. No solo realiza una búsqueda en base de conocimientos sino también de capacidades. Consulta a los runners conectados para ver qué herramientas están disponibles (por ejemplo, list_ec2_instances, install_helm_chart).
3. Ejecución del flujo de trabajo: una vez que el agente decide un curso de acción, crea un flujo de trabajo estructurado.
4. Ciclo de retroalimentación: los runners ejecutan el comando de forma local y envían los resultados de vuelta a Elasticsearch. El copiloto lee el resultado del índice y decide el siguiente paso.

La demo: de interrupción a observabilidad

En el video, mostramos dos casos distintos que demuestran la potencia de esta arquitectura.

Escenario 1: Rescate de DevOps

Empezamos con un usuario que estaba preocupado por una interrupción de 5 millones de dólares causada por un punto ciego en su clúster de Kubernetes.

• La solicitud: "¿Cómo me aseguro de que esto no vuelva a suceder?"
• La acción: el agente no solo proporcionó un tutorial. Identificó el clúster, creó los espacios de nombres necesarios, generó secretos de Kubernetes, instaló el operador OpenTelemetry e instantáneamente proporcionó un enlace a un dashboard APM en vivo.
• El resultado: observabilidad completa de Kubernetes e información de aplicación sin que el usuario escriba ni una sola línea de YAML.

Caso 2: entrega de Security

Una regla fundamental de la seguridad de infraestructuras es que no puedes proteger lo que no puedes ver. Mientras llevamos a cabo nuestra intervención de DevOps, el agente ve una oportunidad para mejorar la seguridad del entorno.

Con una alerta iniciada tras una investigación previa relacionada con Elastic Observability, demostramos cómo un profesional de seguridad puede comunicarse directamente con su infraestructura: primero, para enumerar los activos y recursos en su entorno cloud; y segundo, para desplegar las herramientas necesarias para asegurarse de que el entorno esté protegido.

• Descubrimiento: el copiloto enumeró los recursos de AWS para el profesional de la seguridad e identificó una brecha crítica: una instancia de Amazon Elastic Compute Cloud (EC2) y un clúster de Amazon Elastic Kubernetes Service (EKS) con terminales públicos que no tienen protección para endpoints.
• Remediación: con una simple aprobación, el copiloto desplegó Elastic Security detección y respuesta extendida (XDR) y detección y respuesta en el cloud (CDR) a los activos vulnerables, asegurando el entorno en tiempo real.
• El resultado: protección de los activos y recursos de AWS desplegados con seguridad en tiempo de ejecución completa.

El futuro: todo aumentado

Este proyecto demuestra que Elastic Agent Builder puede ser el cerebro central de las operaciones distribuidas. No nos limitamos solo a infraestructura. Nuestra tecnología runner puede impulsar:

• Synthetics aumentados: diagnosticar errores de TLS en runners globales.
• Desarrollo aumentado: crear pull requests e implementar CAPTCHAs en servicios frontend.
• Operaciones aumentadas: reconfiguración automática de los servidores DNS durante una interrupción.

Pruébalo tú mismo

Creemos que el futuro de la IA no se trata solo de soporte por chat; se trata de infraestructura aumentada. Se trata de tener un socio que pueda desplegar, arreglar, observar y proteger a la par tuya.

¡Descubre el código y pruébalo tú mismo con runners distribuidos (GitHub) más Elastic Agent Builder en Elastic Cloud Serverless hoy mismo!

• Crea un proyecto serverless en Elastic Cloud.
• Despliega el código en un ejecutor.
• Configura el runner.
• Configura tu archivo mcp.json.
• Inicia el runner, el cual creará de forma automática tu agente y sus herramientas.
• ¡Chatea con un agente que puede razonar, planificar y ejecutar acciones en tus runners distribuidos!

El equipo: Alex, Bill, Gil, Graham, & Norrie