Hoy escribir software es más rápido, más accesible y más barato. Pero esa facilidad ha generado una confusión importante: que sea más fácil escribir código no significa que sea más fácil construir software. Y mucho menos software agéntico. 

Hablamos de construir sistemas capaces de operar en entornos reales, con información imperfecta, usuarios impredecibles, dependencias externas y reglas cambiantes. Los agentes han reducido drásticamente el coste de producción, pero no han reducido la complejidad estructural de lo que se construye. De hecho, en muchos casos la han aumentado, porque ahora no solo hablamos de software que ejecuta instrucciones, sino de software que interpreta, decide, actúa y se coordina. Muchos sufren el espejismo al abordar sus proyectos debido a la facilidad para generar código.

Aquí está el error de muchas empresas cuando empiezan a trabajar con inteligencia artificial. Creen que construir un sistema agéntico consiste en conectar un modelo, escribir unas instrucciones y añadir algunas herramientas. Pero eso no es un sistema. Un sistema agéntico real es una arquitectura operativa completa donde la inteligencia no solo responde, sino que opera sobre sistemas vivos, interactúa con datos reales, yoma decisiones, ejecuta acciones y mantiene continuidad en el tiempo.

Y cuando eso ocurre, el problema deja de ser de prompting para convertirse en un problema clásico de sistemas. Construir software agéntico exige, al menos, resolver cinco capas de ingeniería que deben funcionar juntas.

Diseñar comportamiento operativo

La primera capa es la más visible y, probablemente, la que concentra más atención: el propio agente. Aquí es donde se define qué hace, cómo razona, qué herramientas utiliza, qué información necesita y cómo reacciona ante distintas situaciones. Pero diseñar agentes no consiste en escribir un prompt más largo o más sofisticado. Consiste en diseñar comportamiento operativo.

Eso implica establecer instrucciones robustas, definir herramientas con contratos claros, controlar qué contexto entra y sale del sistema, gestionar memoria y construir flujos de ejecución consistentes. En arquitecturas multiagente, además, aparece una dificultad adicional: la coordinación entre agentes. Quién decide, quién ejecuta, quién valida y cómo se transfiere el trabajo de unos a otros.

La diferencia entre un agente útil y uno impredecible no está tanto en la calidad del modelo como en la calidad de la ingeniería que define su comportamiento. El modelo aporta capacidad, pero la arquitectura aporta control. Y cuando no hay determinismo suficiente, la observabilidad se convierte en un requisito básico para entender qué está ocurriendo dentro del sistema.

El contexto es la verdadera inteligencia

Llevamos tiempo insistiendo en una idea que cada vez resulta más evidente: la inteligencia artificial vale menos por lo que sabe y más por el contexto que es capaz de utilizar. Un agente sin contexto es solo una capacidad de lenguaje. Puede parecer inteligente, pero opera con una comprensión limitada de la realidad concreta sobre la que debe actuar.

Todo lo que solemos llamar memoria, conocimiento o inteligencia persistente es, en realidad, un problema de datos. Cómo se almacenan, cómo se estructuran, cómo se recuperan y cómo se actualizan. La mayoría de las empresas tienen su conocimiento crítico fragmentado entre correos, documentos, CRMs, ERPs, conversaciones y bases de datos. El reto no es acceder a esos sistemas. El reto es convertir esa dispersión en contexto operativo útil.

Eso exige aplicar principios clásicos de ingeniería de datos: buenos esquemas, estructuras consistentes, sistemas de recuperación eficientes y mecanismos de actualización continua. Porque el contexto no puede ser estático. La realidad empresarial cambia constantemente y un agente solo puede ser útil si trabaja con una representación actualizada de esa realidad.

La autonomía necesita directrices y límites

Uno de los errores más habituales en sistemas agénticos es confundir instrucciones con seguridad. Decirle a un agente “no modifiques datos” o “no borres información” no es una política de seguridad. Es simplemente una expectativa. Y las expectativas no sustituyen a la arquitectura.

La seguridad real se construye en la capa de herramientas y acceso. Si un agente puede operar sobre un sistema, debe hacerlo dentro de permisos concretos, con autenticación sólida, roles definidos y trazabilidad completa. Leer no es escribir, escribir no es aprobar y aprobar no es ejecutar operaciones sensibles. Cada nivel de acción debe tener su propia política.

Eso implica sistemas de autorización escalonados, auditoría de acciones y aislamiento estricto de datos entre usuarios. Porque cuando un agente trabaja con información sensible, una fuga de contexto entre usuarios no es un fallo menor. Es una brecha de datos con consecuencias legales y operativas. La autonomía sin límites no es eficiencia. Es riesgo.

Los agentes y sus interfaces

Durante décadas, el software tenía una interfaz principal. Una aplicación, una web o una API. En el mundo agéntico eso ha cambiado. Hoy un agente puede existir simultáneamente en múltiples superficies: una interfaz web, un chat, un terminal, un sistema de mensajería o un servidor basado en MCP. Cada una de esas superficies introduce su propia lógica de identidad, autenticación y permisos.

Un usuario dentro de Slack no es necesariamente el mismo usuario dentro del producto. Y un agente llamando a otro agente tampoco puede tratarse como un usuario humano. Eso obliga a repensar completamente la lógica de acceso y la coherencia de políticas.

La ingeniería de interfaces consiste precisamente en garantizar que las reglas operativas y de seguridad se mantengan consistentes independientemente de dónde esté actuando el agente. Porque en la era agéntica la interfaz ya no es solo un canal de acceso. Es parte de la arquitectura.

La inteligencia necesita sostenerse

La última capa es la menos visible, pero muchas veces la más crítica. Toda inteligencia operativa necesita una infraestructura que la sostenga. Dónde corre el sistema, cómo escala, cómo se monitoriza, cómo se recupera ante errores y cómo mantiene continuidad cuando las operaciones son largas o complejas.

Los agentes no son ligeros. Trabajan con contexto, herramientas, procesos encadenados y, en muchos casos, múltiples llamadas a sistemas externos. Eso exige infraestructuras capaces de escalar horizontalmente, gestionar colas de trabajo, aislar procesos y mantener observabilidad completa.

Herramientas como Docker o Kubernetes forman parte natural de este escenario, no por moda, sino porque permiten gestionar esa complejidad de forma operativa. Porque cuando un agente falla a mitad de una operación, lo importante no es solo que falle menos. Es saber por qué falló, dónde falló y cómo reanudar lo que estaba haciendo.

El futuro de la IA no depende de mejores modelos, sino de mejores sistemas

El gran error que estamos viendo es pensar que construir agentes es simplemente integrar inteligencia artificial. Como los modelos son cada vez más capaces, se ha instalado la sensación de que todo se ha simplificado. Pero solo se ha simplificado una parte: la generación. El resto sigue siendo tan complejo como siempre, o incluso más.

Y cuanto más autonomía damos a los agentes, más importante se vuelven las capas que los rodean. Los datos que alimentan su contexto, la seguridad que limita sus acciones, las interfaces que conectan con usuarios y sistemas y la infraestructura que sostiene toda la operación.

El futuro del software no será software con IA añadida. Será software construido alrededor de inteligencias operativas. Y eso no es un problema de modelos. Es, como siempre ha sido en ingeniería, un problema de sistemas. La diferencia es que ahora esos sistemas ya no solo ejecutan lógica. También toman decisiones.