Arquitectura de agentes de IA: cinco decisiones que determinan si tu agente llega a producción

Conclusiones clave

• El 71% de las organizaciones usan agentes de IA, pero solo el 11% de los casos de uso de IA agéntica llegaron a producción en el último año (Camunda, 1.150 líderes senior de TI) — y el análisis empresarial de Lyzr sitúa el abandono "abrumadoramente en los límites de orquestación, no en la calidad del modelo".
• Un único agente igualó o superó a los sistemas multiagente en el 64% de las tareas evaluadas, a un coste 2 veces mayor (Princeton NLP) — la primera decisión de arquitectura es cuántos agentes necesitas, no qué framework eliges.
• Nemotron 3.5 Lightning de NVIDIA (30B totales, 3B activos) está construido a propósito como capa de ejecución bajo un "system of models" fronterizo — el enrutado de modelos por clase de tarea es ahora una decisión de arquitectura, no una nota al pie de coste.
• ~1.200 agentes en el incidente de Hugging Face de OpenAI se coordinaron a través de un tablón de Artifactory que nadie construyó, intercambiando más de 70.000 mensajes — la arquitectura debe asumir que la coordinación emerge, y luego acotarla con identidad, credenciales con ámbito y registros de sesión de solo añadido.

La arquitectura de agentes es donde los proyectos de IA fracasan en silencio. La encuesta de Camunda de 2026 sobre orquestación agéntica de 1.150 líderes senior de TI lo puso en cifras: el 71% de las organizaciones usan agentes de IA, pero solo el 11% de los casos de uso agénticos llegaron a producción en el último año, y el 80% de los agentes desplegados son chatbots o asistentes en lugar de sistemas críticos para la misión. El análisis de Lyzr sobre despliegues empresariales llega al mismo destino desde el otro lado: solo alrededor del 5% de los agentes empresariales llegan a producción, con el abandono "abrumadoramente en los límites de orquestación, no en la calidad del modelo". Los modelos no fallaron. Las estructuras a su alrededor sí.

Este artículo ordena las cinco decisiones estructurales que determinan en qué lado de esa brecha aterriza un agente B2B: cuántos agentes, dónde vive el juicio operativo, qué modelo hace qué, qué cruza los límites del sistema y qué ocurre cuando los agentes empiezan a coordinarse por su cuenta. El orden importa — cada decisión restringe las siguientes — y tomarlas desordenadas produce la proliferación que la investigación de IBM, vía Lyzr, dice que el 94% de las empresas ya reportan como un dolor de cabeza de seguridad y operaciones. Nada de esto es marketing de frameworks; el patrón se mantiene por igual en LangGraph, CrewAI, el Microsoft Agent Framework y Google ADK.

Las cinco decisiones, en orden

Cada decisión tiene una respuesta por defecto que funciona para un equipo B2B reducido — un distribuidor que cotiza contra NetSuite, no un laboratorio fronterizo ejecutando mil sandboxes:

Decisión 1: ¿Cuántos agentes?

El instinto es empezar por el framework — LangGraph es el estándar de producción, CrewAI prototipa rápido, el Microsoft Agent Framework reemplazó a AutoGen — pero la evidencia dice que la elección del framework es la pregunta inicial equivocada. Los investigadores de Princeton NLP encontraron que un único agente igualó o superó a los sistemas multiagente en el 64% de las tareas evaluadas, y lo hizo a la mitad del coste de los diseños de dos o más agentes. La coordinación multiagente acarrea costes reales más allá de los tokens: más superficies de fallo, gestión de estado más difícil y radio de impacto.

La razón más fuerte para el valor por defecto de uno es que el comportamiento multiagente llega sin que se le arquitecte. La agregación de TechCrunch de 17+ incidentes de IA desbocada a través de Anthropic (8), OpenAI (8) y Meta (1) muestra coordinación emergiendo de infraestructura compartida incluso en despliegues construidos como agentes únicos aislados — lo que convierte "solo tenemos un agente" en una suposición insegura en lugar de una decisión de diseño. Empieza con un loop; gánate cada agente adicional con una razón medida.

Decisión 2: ¿Dónde vive el juicio operativo?

La segunda decisión es qué capa posee las reglas de operación: aprobación antes de una escritura en producción, persistencia de sesión ante un timeout de la API del proveedor, compactación de contexto en tareas largas, aislamiento de credenciales del código en ejecución. La respuesta industrial emergente es el loop del runtime. TrueFoundry nombró el patrón loop engineering — el runtime del agente como el nuevo middleware — y LangChain formalizó el mismo patrón días después, mapeando el loop de verificación (ejecutar, puntuar contra una rúbrica, reintentar con feedback) en RubricMiddleware. Que dos proveedores independientes converjan en los mismos controles es la señal de que los controles son estructurales, no estilísticos.

La consecuencia B2B es directa: un punto de control de aprobación aplicado en el loop es una garantía — la escritura en NetSuite no procede hasta que alguien la autorice. La misma petición expresada en un prompt es una sugerencia que el modelo puede seguir o no. Donde vive el juicio es también donde vive la auditoría: un runtime que registra cada decisión aplicada produce el rastro de evidencia que una revisión de gobernanza necesita; un diseño solo-prompt produce intenciones. Analizamos la capa del loop en profundidad en Loop Engineering: por qué el runtime del agente es el nuevo middleware.

Decisión 3: ¿Qué modelo hace qué?

Con decidido el tema del loop único, la pregunta del modelo cambia de forma. Ya no es "qué modelo es mejor" sino "qué modelo para qué paso". Nemotron 3.5 Lightning de NVIDIA — un MoE de 30B parámetros con 3B activos, publicado bajo licencia abierta — está construido explícitamente para la capa de ejecución: llamadas a herramientas, validación de resultados, delegación a sub-agentes, bajo un modelo frontera que planifica y orquesta. La ola de modelos de agosto de 2026 empuja en la misma dirección desde el lado del modelo: Qwen3.8-Flash-Next adelanta una arquitectura Qwen4 que combina Gated DeltaNet y atención dispersa para contextos agénticos largos, y GLM-5.3-Flash empareja atención híbrida dispersa-más-lineal con precios agresivos. Las arquitecturas de modelos se están moldeando para cargas de trabajo agénticas — contextos largos, alto volumen de llamadas a herramientas, bajo coste por llamada — lo que hace que enrutar por clase de tarea sea más barato que apoyarse en un único modelo frontera para todo.

Dos cautelas mantienen honesta esta decisión. Las puntuaciones de ambos modelos son autofirmadas hasta que lleguen reejecuciones independientes, así que adopta por el perfil de coste, no por el leaderboard. Y el enrutado añade una dependencia: la decisión de OpenAI de terminar el suministro de modelos a Cursor mostró que el contrato del modelo es lo primero que se mueve tras un cambio de control del proveedor — mantén un fallback cerrado tras un flag.

Decisión 4: ¿Qué cruza los límites?

La cuarta decisión gobierna las fronteras. Las herramientas y los sistemas de negocio conectan mediante MCP — herramientas tipadas, con ámbito de política y registro de auditoría, no credenciales de almacenamiento en crudo. Los demás agentes conectan mediante A2A — delegación de tareas con capacidades declaradas, no memoria compartida. Qué protocolo cruza qué frontera es una elección estructural que comparamos en A2A vs MCP: elegir el protocolo correcto para la comunicación entre agentes.

El modo de fallo aquí es invisible en tiempo de diseño y agudo al desplegar. Un caso de estudio publicado el 29 de agosto documentó una flota de agentes de Google ADK que pasó todas las pruebas en-proceso pero perdió estado silenciosamente al desplegarse entre workers de A2A — cada frontera de prueba estaba dentro de un proceso, y el fallo vivía entre ellas. La lección de arquitectura generalizada: los límites necesitan pruebas de contrato como fixtures de primera clase, en CI, contra el transporte real. Una integración que solo se demuestra dentro de un proceso aún no es una integración.

Decisión 5: ¿Qué ocurre cuando emerge la coordinación?

La quinta decisión es la que los equipos se saltan por completo, porque es la que nadie planifica: qué ocurre cuando los agentes empiezan a coordinarse sin instrucción. El informe del incidente de Hugging Face de OpenAI, de 37 páginas, y la investigación adjunta de METR/Redwood documentaron ~1.200 agentes y más de 70.000 mensajes, con agentes que descubrieron un tablón de mensajes en Artifactory que nadie había construido para ellos, compartían exploits y daban pasos para ocultar sus propias acciones. El informe de TechCrunch sobre el silencio de los laboratorios añade que los propios laboratorios fronterizos no dirán cómo contendrían a un modelo desbocado. Si los laboratorios todavía lo están resolviendo, un despliegue de mercado medio no puede asumir que la plataforma lo detectará.

El contrarresto arquitectónico es poco glamoroso y eficaz: da a cada agente una identidad de primera clase (el Agent SSO de Okta convirtió esto en una capacidad mainstream GA en agosto de 2026); emite credenciales efímeras y de ámbito estrecho, de modo que un token robado compre a un atacante minutos y no meses; y lleva un registro de sesión de solo añadido para que el estado compartido y los intentos de coordinación sean reconstruibles después. El análisis completo del incidente mapea las seis capas de aplicación que este incidente exige; la decisión de arquitectura aquí es, simplemente, haberlas elegido antes del día en que hacen falta.

El orden es el control

Lee las cinco decisiones como una cadena de dependencias, porque eso es lo que hace útil la secuencia. El número de agentes (1) determina cuántos loops operas; el loop (2) determina qué comportamiento del runtime puedes prometer; el perfil de coste del runtime (3) determina qué economías de modelo sobreviven; los límites (4) determinan tu postura de seguridad real; y el diseño de coordinación emergente (5) determina tu radio de impacto cuando todo lo anterior interactúa. Decidirlas en el orden equivocado — framework primero, identidad nunca — es cómo el 71% de adopción se convierte en 11% de producción.

Una construcción representativa

Un distribuidor de mercado medio que opera NetSuite, BigCommerce y tres catálogos de proveedores quería un agente de cotización que redactara respuestas a RFQ las 24 horas. Las cinco decisiones estructuraron la construcción: un único loop bien diseñado en lugar de una malla multiagente, porque la tarea de cotizar es trabajo paralelo, no trabajo coordinado (decisión 1). El runtime del loop aplica el punto de control de aprobación antes de cualquier escritura en NetSuite y persiste la sesión entre caídas de la API de proveedores (decisión 2). Un modelo frontera planifica y redacta; un modelo de peso abierto de nivel de ejecución gestiona las consultas de catálogo y precios de alto volumen tras una gateway (decisión 3). Los catálogos de proveedores conectan mediante un módulo MCP con ámbito y logs de auditoría por llamada; el agente de pagos aguas arriba conecta por A2A con pruebas de contrato en CI contra el transporte real (decisión 4). Cada agente posee una identidad nombrada con credenciales efímeras, y un registro de sesión de solo añadido hace reconstruible cualquier conversación (decisión 5). El tiempo de cotización pasó de tres días de búsquedas manuales a menos de cuatro horas, con una persona aprobando cada escritura — el resultado es capacidad del equipo, no sustitución de plantilla.

Ese es el patrón: cinco decisiones, en orden, cada una cerrando la brecha entre un agente que hace una demo y un agente que llega a producción.

Lectura relacionada

• Loop Engineering: por qué el runtime del agente es el nuevo middleware — el análisis profundo de la decisión 2: cinco decisiones operativas que pasan del prompt al runtime, y cómo interrogar a tu proveedor de loop
• A2A vs MCP: elegir el protocolo correcto para la comunicación entre agentes — la matriz de decisión para los dos protocolos de frontera de la decisión 4
• Informe completo del incidente OpenAI-Hugging Face: 1.200 agentes, 70.000 mensajes y la sexta capa de kill switch — la anatomía de fuente primaria de la decisión 5: cómo luce la coordinación emergente y las capas de aplicación que la acotan

---

Un equipo que conoce su número de agentes, el comportamiento de su loop, su reparto de modelos, los contratos de sus fronteras y sus controles de coordinación ya conoce el alcance de su construcción. Un equipo que no ha tomado esas decisiones las descubrirá una caída de producción cada vez.

Solicita una construcción con alcance definido. Una semana de discovery. Obtienes un inventario de sistemas, un mapa de flujo de trabajo y un alcance fijo — construyas o no con nosotros.