IA agéntica e IA híbrida: cuando la IA deja de ser solo un chat


En posts anteriores hemos visto reglas, ML clásico y modelos generativos que escriben texto o código. El siguiente escalón es la IA agéntica: sistemas donde uno o varios agentes de IA no solo generan respuestas, sino que planifican, llaman a herramientas, orquestan pasos y se integran con tus sistemas.

Aquí ya no hablamos solo de “dame una explicación”, sino de cosas como:

  • Crear un plan de acción para una tarea compleja.

  • Llamar a APIs o scripts reales.

  • Leer el resultado, corregir el rumbo y seguir hasta completar el objetivo.

Es una IA híbrida porque combina:

  • Modelos generativos (razonamiento, lenguaje, código).

  • Herramientas clásicas (scripts, APIs, bases de datos).

  • Reglas, flujos y límites definidos por humanos.


Qué significa “agente” en este contexto

Un agente de IA es, simplificando, un asistente con cuatro capacidades:

  1. Entender un objetivo

    • No solo responde a una pregunta, sino que interpreta qué hay que conseguir: “diagnosticar un incidente”, “analizar este repositorio”, “preparar un informe”.

  2. Dividir en pasos

    • Planifica: “primero miro los logs, luego reviso métricas, después consulto la CMDB, finalmente genero el informe”.

  3. Usar herramientas reales

    • Puede llamar a comandos, APIs, bases de datos, sistemas de ticketing, etc., dentro de los límites que tú definas.

  4. Revisar y ajustar

    • Lee los resultados, los interpreta y decide el siguiente paso, hasta completar o escalar al humano.

Cuando combinas varios agentes especializados que colaboran entre sí, hablamos de sistemas multi‑agente.

Sabes o que é a IA Agêntica?


Ejemplos: Clawdbot, Kimi Swarm, Devin

Más que quedarnos en nombres concretos (que irán cambiando), lo importante es el patrón que representan:

Clawdbot / agentes “pegados a tus datos”

Puedes imaginar un agente centrado en tu stack de datos y observabilidad:

  • Tiene acceso controlado a dashboards, logs, métricas y documentación.

  • Puede ejecutar consultas predefinidas (SQL, KQL, PromQL…) y scripts de diagnóstico.

  • Habla tu idioma técnico (nombres de servicios, entornos, SLAs).

Su rol:

  • Contestar preguntas tipo “qué ha pasado”, “desde cuándo”, “a quién afecta” usando datos reales.

  • Preparar resúmenes y primeros análisis de incidentes.

  • Proponer acciones en base a runbooks existentes.

Es como un SRE junior hiper‑rápido, que nunca se cansa de leer logs, pero siempre bajo tus reglas.

Kimi Swarm / sistemas multi‑agente

Un swarm es un conjunto de agentes que se reparten el trabajo:

  • Un agente entiende la petición global (“auditar esta arquitectura”).

  • Otros se especializan: uno lee documentación, otro analiza código, otro revisa políticas, otro prepara el informe.

  • Se pasan contexto entre ellos hasta entregar un resultado coherente.

Ventajas:

  • Puedes escalar en complejidad de tareas sin tener un solo agente “monolítico”.

  • Cada agente puede tener permisos limitados y responsabilidades claras.

  • Es más fácil de mantener y ampliar: añades un agente para un nuevo tipo de tarea sin rehacerlo todo.

Devin / el “futuro combinado”

Devin se ha presentado como un “ingeniero de software autónomo”: recibe un ticket y, en teoría, puede:

  • Entender el requerimiento.

  • Leer un repositorio entero.

  • Planificar cambios.

  • Editar código, lanzar tests y abrir pull requests.

  • Explicar lo que ha hecho.

Más allá del hype, lo relevante es la dirección:

  • Agentes que no solo sugieren código, sino que interactúan con repos, CI/CD, issues.

  • Integración profunda con herramientas de desarrollo: Git, issue trackers, pipelines.

  • Un modelo híbrido donde la IA hace el trabajo mecánico y el humano supervisa, prioriza y decide.


Orquestación e integración: el “cerebro” alrededor de los modelos

La IA agéntica necesita una buena capa de orquestación:

  • Definir qué herramientas puede usar cada agente (APIs, scripts, queries).

  • Marcar límites de seguridad: qué entornos puede tocar, qué solo puede leer, qué siempre requiere confirmación humana.

  • Establecer flujos: qué pasa si una llamada falla, cuándo se reintenta, cuándo se escala a una persona.

Esta orquestación convierte un LLM potente en algo utilizable de verdad en empresa:

  • No quieres un modelo con acceso sin control a producción.

  • Sí quieres agentes que ejecuten tareas rutinarias en entornos controlados, con logs y auditoría.

Aquí entra la IA híbrida: una mezcla de:

  • LLMs para entender, planificar y generar.

  • Reglas y workflows para garantizar comportamiento predecible.

  • Sistemas clásicos (ITSM, CMDB, monitores, CI/CD) como “extensiones” del agente.


Casos de uso en cloud e infraestructura

Para tu mundo, esto es especialmente interesante. Algunos ejemplos:

  • Diagnóstico asistido de incidentes

    • Agente que, ante una alerta crítica, recopila logs, revisa cambios recientes, consulta dashboards, resume hipótesis y prepara un primer informe para el on‑call.

  • Gestión de cambios repetitivos

    • Agentes que implementan cambios estándar (por ejemplo, ajustes de configuración, despliegues de pequeños componentes) siguiendo plantillas y pidiendo aprobación humana cuando toca.

  • Auditoría continua

    • Agente que recorre configuraciones (Terraform, Azure, Kubernetes), compara contra buenas prácticas y abre tickets con findings bien documentados.

  • Documentación viva

    • Agente que genera y actualiza documentación técnica a partir de código, infra como código y decisiones registradas en tickets.

En todos los casos, la clave es la misma: la IA no va sola, se apoya en tus sistemas y en tus reglas.


Qué cambiará y qué no

Lo que probablemente veremos en los próximos años:

  • Menos “abrir el chat” y más agentes embebidos en herramientas que ya usamos (portales internos, paneles de observabilidad, IDEs, ITSM).

  • Menos prompts sueltos y más tareas definidas (“investiga esto”, “genera este informe semanal”, “aplica este cambio estándar”).

  • Más foco en seguridad, permisos, auditoría y trazabilidad de lo que hace cada agente.

Lo que no cambiará:

  • La necesidad de criterio humano para definir qué es un buen resultado.

  • La responsabilidad final sobre cambios en producción, decisiones de diseño y gestión de riesgos.

  • La importancia de entender mínimamente cómo funcionan estos sistemas para no tratarlos como cajas mágicas.