Elastic Agent Builder: agentes de IA nativos en Elastic para Observabilidad, Seguridad y Búsquedas

La mayoría de organizaciones ya tiene el dato en Elastic: logs, métricas, trazas, eventos de seguridad, señales de negocio, alertas y casos. El reto real no es “preguntar en lenguaje natural”, sino convertir preguntas en decisiones repetibles y, cuando aplica, tomar acciones con control.

Ahí es donde encaja Elastic Agent Builder: Flujos de trabajo agentivos con IA, una forma nativa de crear agentes que combinan modelos LLM con el contexto de Elasticsearch y un conjunto de herramientas (tools) para buscar, razonar y operar sobre tus datos. En Elastic 9.3, además, se vuelve especialmente interesante por su integración con Elastic Workflows, que aporta la capa de automatización determinista para ejecutar acciones sin improvisar.

Qué es Elastic Agent Builder (y qué no es)

Elastic Agent Builder es una capacidad de Kibana para construir agentes de IA orientados a datos: agentes que no se limitan a responder, sino que seleccionan herramientas, consultan fuentes reales en Elasticsearch y devuelven conclusiones con evidencia.

Lo importante es diferenciarlo de un “chat genérico”:

• Un chat genérico responde con lo que “sabe” el modelo.
• Un agente en Agent Builder razona con contexto: ejecuta búsquedas, genera consultas, valida hipótesis y vuelve con resultados basados en tus índices.

Elastic lo posiciona como una forma de crear agentes “context-driven” (con contexto real) y ha anunciado su disponibilidad general (GA) en Elastic Cloud Serverless y en el ciclo de Elastic 9.3.

Conceptos clave: Agent Chat, Agents y Tools

En la práctica, Agent Builder se entiende mejor con tres piezas:

1) Agent Chat

La interfaz conversacional donde interactúas con agentes para explorar datos y ejecutar tareas asistidas.

2) Agents

Un agente es una combinación de:

• Instrucciones (cómo debe comportarse),
• Objetivo (qué intenta resolver),
• Conjunto de tools habilitadas (qué puede hacer).

Elastic incluye un agente por defecto, Elastic AI Agent, con acceso a herramientas integradas para empezar rápido.

3) Tools

Las tools son el “puente” entre el modelo y tu plataforma: permiten ejecutar operaciones (principalmente de lectura) sobre Elasticsearch y otros componentes. Agent Builder trae herramientas integradas y, además, permite crear herramientas personalizadas.

Nota práctica: el comportamiento “agentic” (selección y ejecución de tools) consume tokens. Esto no es un detalle menor: influye en coste, latencia y diseño.

Por qué Agent Builder importa ahora en Elastic 9.3

En Elastic 9.3 hay dos movimientos que encajan como un guante:

1. Agentes con contexto y herramientas (Agent Builder)
2. Automatización nativa declarativa (Workflows)

Elastic describe explícitamente que, con 9.3, Agent Builder funciona con Workflows para que los agentes puedan “tomar acciones fiables” (reliable actions), evitando que una acción crítica dependa de una respuesta probabilística.

En mi post sobre Workflows explico justo este patrón: agente para razonar + workflow para ejecutar, especialmente potente en Observability y Security.

Qué puedes construir: posibilidades reales

Observability: del “hay un pico” a “aquí está la evidencia”

Un agente puede:

• Identificar ventanas temporales relevantes.
• Correlacionar logs, métricas y trazas.
• Proponer hipótesis (por ejemplo: cambio reciente, degradación de dependencia, saturación, etc.).
• Devolver consultas reproducibles (ES|QL / búsquedas) y una explicación operativa.

Este enfoque encaja muy bien con agentes especializados por dominio (SRE, APM, plataforma, etc.).

Security (SOC): triage y hunting más rápido, con control

En seguridad, el ROI suele aparecer cuando:

• Priorizas alertas con contexto real.
• Automatizas el enriquecimiento y la investigación inicial.
• Generas un “resumen para caso” con evidencia y siguientes pasos.

Agent Builder incluye agentes integrados (built-in agents) para casos comunes, que puedes clonar y adaptar.

Search & Analytics: acceso a datos para equipos no técnicos

Un agente bien diseñado puede ser la interfaz para:

• Analistas que necesitan preguntas ad-hoc.
• Equipos de negocio que requieren métricas y segmentaciones puntuales.
• Usuarios no expertos que no deberían construir consultas complejas manualmente.

La clave aquí es el diseño de tools: cuanto más determinista sea la recuperación, mejor.

Built-in tools vs herramientas personalizadas: dónde se gana fiabilidad

Elastic distingue claramente entre:

Built-in tools (integradas)

Vienen listas para usar, cubren operaciones “core” sobre datos y son read-only (no se pueden modificar ni borrar).

Esto es ideal para empezar y para agentes generalistas.

Herramientas personalizadas

Cuando un caso de uso se repite (por ejemplo, “RCA de errores 5xx en checkout”), convertirlo en tool reduce:

• consultas inventadas,
• ambigüedad en filtros,
• pasos manuales.

El patrón más sólido suele ser: tools con ES|QL parametrizado para que el modelo rellene parámetros, no “improvise” consultas.

Workflows + Agent Builder: patrón recomendado en producción

Un diseño que funciona especialmente bien:

• El agente investiga y decide (qué mirar, qué hipótesis validar, qué evidencia presentar).
• El workflow ejecuta (abrir caso, notificar, crear ticket, correr runbook, integrar con Slack/Jira/API…).

Elastic posiciona Workflows como automatización integrada y Agent Builder como capa inteligente; juntos permiten separar “razonamiento” de “ejecución fiable”.

Si quieres ver ejemplos y plantillas en español de Workflows (incluyendo integración con agentes), tengo una guía y repositorio actualizada a 9.3.

Exponer agentes y tools fuera de Kibana: MCP y A2A

Cuando quieres que otros sistemas consuman capacidades de Elastic, hay dos piezas relevantes:

MCP server (Model Context Protocol)

Proporciona una interfaz estándar para que clientes externos accedan a tools de Agent Builder (por ejemplo, desde entornos de desarrollo o plataformas de agentes).

A2A server (Agent-to-Agent)

Permite que clientes A2A externos se comuniquen con agentes de Agent Builder (interoperabilidad entre agentes).

Este punto es interesante porque abre arquitecturas donde Elastic actúa como “agente especialista” en recuperación y evidencia, y otros agentes orquestan tareas multi-sistema.

Seguridad y gobernanza: el diseño “mínimo necesario”

En agentes que tocan datos sensibles, lo importante no es solo que “funcione”, sino que:

• no vea lo que no debe,
• no ejecute lo que no debe,
• y sea auditable.

Agent Builder se apoya en permisos y control de acceso del ecosistema Elastic, y el diseño recomendado es:

1. Un agente por dominio (SRE, SOC, negocio…)
2. Tools mínimas para ese dominio
3. Índices mínimos para esas tools

En producción, esto hace más por la calidad que cualquier prompt largo.

Buenas prácticas que suelen marcar la diferencia

• Define el objetivo del agente como si fuese un runbook: claro, operativo y medible.
• Reduce libertad, sube precisión: pocas tools, bien descritas, con parámetros explícitos.
• Estandariza evidencia: el agente debe devolver “qué vi” + “cómo lo busqué” + “qué significa”.
• Separa análisis de acción: decisiones del agente, acciones del workflow.
• Mide coste/latencia: si el agente da demasiadas vueltas, faltan tools o sobran opciones.

Conclusión

Elastic Agent Builder no es “otro chatbot”: es una forma de construir agentes con contexto real, gobernanza y herramientas nativas sobre Elasticsearch. En Elastic 9.3, su valor se multiplica cuando lo combinas con Workflows: el agente hace el trabajo cognitivo (investigar, correlacionar, proponer) y el workflow hace el trabajo repetible (ejecutar, integrar, dejar trazabilidad).

Si tu organización ya vive en Elastic, este enfoque reduce pegamento, acelera triage y permite automatización sin perder control.

Revisa la documentación oficial ➡️ https://www.elastic.co/docs/explore-analyze/ai-features/elastic-agent-builder - Workflows en Elastic ➡️ https://byviz.ai/blog/elastic-workflows-en-9-3-automatizacion-nativa-dentro-de-elastic-stack - Blog detallado ➡️ https://www.elastic.co/search-labs/blog/ai-agentic-workflows-elastic-ai-agent-builder -

FAQ — Elastic Agent Builder

¿Qué es Elastic Agent Builder?

Elastic Agent Builder es una capacidad de Kibana que permite crear agentes de IA dentro del ecosistema Elastic. Estos agentes combinan un modelo LLM con herramientas (tools) para consultar datos reales en Elasticsearch (por ejemplo con ES|QL) y devolver respuestas basadas en evidencia, no solo en texto generado.

¿En qué se diferencia de un “chatbot” tradicional?

Un chatbot suele responder con conocimiento general del modelo. Un agente en Agent Builder puede ejecutar acciones controladas: explorar índices, generar y lanzar consultas, recuperar contexto y construir una respuesta con datos reales. Además, puede apoyarse en Workflows para ejecutar tareas repetibles de forma auditable.

¿Qué son las “tools” en Elastic Agent Builder?

Las tools son capacidades que el agente puede invocar para interactuar con el stack. Pueden ser:

• Built-in tools (integradas y read-only) para operaciones comunes.
• Tools personalizadas (por ejemplo herramientas basadas en ES|QL) para casos de uso concretos y repetibles. La calidad de las tools suele ser el factor que más impacta en precisión y fiabilidad.

¿Puedo crear herramientas personalizadas con ES|QL?

Sí, y es una de las mejores prácticas. Las tools basadas en ES|QL parametrizado ayudan a que el agente no improvise consultas complejas, sino que rellene parámetros válidos y produzca resultados consistentes.

Sobre el autor

Soy Iván Frías Molina, consultor especializado en Elastic Stack y fundador de byviz analytics. En este blog publico guías prácticas y patrones reales (Observability, Security, automatización e IA aplicada) para equipos que operan Elastic en producción.