En pocas palabras: Según miles de experimentos de Intel publicados por MIT Technology Review el 27 de julio de 2026, el cuello de botella de la infraestructura agentic empresarial casi nunca es el modelo: son la planificación de capacidad, el acceso a datos, la latencia y el escalado del sistema completo.
Intel corrió miles de experimentos de cargas agentic y llegó a una conclusión incómoda para cualquiera que esté armando infraestructura agentic AI empresarial: el cuello de botella casi nunca es el modelo. Es el sistema entero. La planificación de capacidad, el acceso a datos, la latencia de las tareas y la forma de escalar pesan más que la inferencia pura, según el análisis que publicó MIT Technology Review el 27 de julio de 2026.
Y esto cambia bastante cómo tenés que pensar el deploy. Si venías midiendo solo tokens por segundo, te estabas perdiendo la mitad de la película.
¿Qué es un agente IA empresarial y en qué se diferencia de un chatbot?
Un agente IA empresarial es un proceso de workflow automatizado y orientado a objetivos: planifica una tarea multipaso, llama a herramientas (tools), lee los resultados y reintenta cuando algo falla. Esa es la definición que usa Intel, y marca la línea con el chatbot: el chatbot conversa, el agente ejecuta trabajo de punta a punta a través de personas, flujos, datos y sistemas.
En 30 segundos
- Es un problema de sistema, no de inferencia: orquestación, datos, latencia y escalado pesan más que el modelo.
- Planificá por densidad, no por cantidad: agentes por vCPU (CPU virtual), no cantidad total de agentes.
- Medí latencia de tarea: el uso promedio de CPU engaña; el KPI real es cuánto tarda la tarea end-to-end.
- Scale-out por defecto: escalá hacia afuera; guardá el scale-up para cómputo pesado por agente o límites de arquitectura.
- Base empírica: Intel corrió miles de experimentos de cargas agentic para sacar cinco lecciones prácticas.
Ponele que le pedís a un agente que procese un reclamo: no te contesta una frase, sino que abre el ticket, consulta el CRM, valida contra la política de reembolsos, escribe la respuesta y, si el sistema de pagos devuelve error, lo vuelve a intentar. Eso ya no es una charla. Es software haciendo el trabajo.
La diferencia práctica es enorme. Un chatbot lo evaluás por calidad de respuesta. Un agente lo evaluás por si terminó la tarea, cuánto tardó y qué recursos se comió en el camino.
¿Por qué la mayoría de los sistemas agentic no mide bien el performance?
Porque miran el lugar equivocado. Intel señala que la mayoría de los harnesses (los arneses de prueba) actuales son limitados y no miden el performance del sistema completo. El error clásico es enfocarse solo en la inferencia del modelo e ignorar la orquestación, el acceso a datos, la latencia y la escalabilidad. Y ahí es donde se rompe todo. Te puede servir nuestra cobertura de controles de seguridad empresarial.
El problema es de encuadre. Si tratás al agente como “un LLM con un prompt lindo”, tu benchmark te va a decir que todo anda bárbaro mientras la tarea real se atasca esperando una consulta a la base o un tool que timeoutea.
Fijate el patrón típico: subís el agente, lo probás en local con una sola tarea, anda perfecto, lo mandás a producción con cincuenta agentes concurrentes, la data access se satura, los reintentos se apilan, la latencia por tarea se dispara y nadie entiende por qué el “modelo rápido” de golpe parece lento. El modelo no cambió. El sistema sí.
Por eso Intel lo plantea como un problema de sistema. La “inteligencia” del agente sirve poco si la plataforma abajo no le da CPU, datos resilientes y un camino predecible para escalar.
¿Cómo planificar la capacidad de CPU para agentes IA?
La planificación correcta se hace por densidad de agentes por vCPU (CPU virtual), no por cantidad total de agentes. Es la tercera lección de Intel y probablemente la más contraintuitiva: no importa “cuántos agentes quiero correr”, importa “cuántos agentes entran por cada vCPU sin degradar la latencia de tarea”.
¿Por qué el número total engaña? Porque un agente no consume CPU de forma pareja. Pasa buena parte del tiempo esperando: espera la respuesta de un tool, espera datos, espera al modelo. Mientras espera, ese vCPU puede estar atendiendo a otro agente. Contar agentes sueltos no te dice nada sobre cuántos caben juntos. En usar ChatGPT en ambientes empresariales profundizamos sobre esto.
La densidad, en cambio, es medible y proyectable. Encontrás cuántos agentes por vCPU podés sostener antes de que la latencia se vaya de rango, y a partir de ahí calculás cuánto hardware necesitás para tu volumen objetivo. Recién ahí la planificación deja de ser adivinanza.
Eso sí: la densidad depende del tipo de agente. Uno que hace mucho I/O y poco cómputo entra de a montones por vCPU. Uno que ejecuta lógica pesada por paso entra de a pocos. Por eso el número no se copia de un blog, se mide con tu carga real.
¿Qué métricas hay que monitorear en agentes en producción?
La métrica crítica es la latencia de la tarea, no el uso promedio de CPU. Intel es tajante con esto: monitorear solo la utilización de CPU te da una foto tranquilizadora y falsa. El CPU puede marcar 40% mientras las tareas tardan el triple de lo aceptable porque están todas encoladas esperando datos o tools.
La latencia de tarea end-to-end es lo que siente el negocio. Si el agente que procesa una devolución pasa de tardar 8 segundos a 40, no le importa a nadie que el CPU esté “cómodo”. La tarea se degradó y punto.
¿Qué conviene instrumentar entonces?
- Latencia por tarea (p50, p95, p99): el tiempo real de punta a punta, con foco en la cola larga, que es donde se esconden los agentes trabados.
- Trazas (tracing) por paso: ver cuánto tarda cada plan, cada tool call y cada lectura de datos, para saber dónde se pierde el tiempo.
- Tasa de reintentos: cuántas veces el agente reintenta un paso fallido, señal temprana de un tool o una fuente de datos frágil.
- Densidad efectiva: agentes por vCPU sostenidos sin romper el p95 de latencia.
Observabilidad no es un extra. Es uno de los seis pilares de la plataforma que enumera la fuente, y sin trazas no tenés forma de diagnosticar por qué una tarea tarda lo que tarda. Más contexto en entender los modelos de lenguaje.
¿Cuándo conviene scale-out y cuándo scale-up?
La regla de Intel es directa: scale-out por defecto para sistemas que hostean agentes, y scale-up solo para cargas con cómputo pesado por agente o con límites de arquitectura. Traducido: sumás más nodos antes que agrandar el nodo, salvo que tengas una buena razón para lo contrario.
La lógica cierra con el punto anterior. Como los agentes pasan mucho tiempo esperando, repartirlos en varias máquinas te da más paralelismo y más tolerancia a fallos que apilarlos en un servidor gigante. Si un nodo se cae, perdés una fracción de la capacidad, no todo.
| Criterio | Scale-out (por defecto) | Scale-up (excepción) |
|---|---|---|
| Cuándo usarlo | Mayoría de sistemas con agentes | Cómputo pesado por agente o límite arquitectónico |
| Qué hacés | Agregás más nodos | Agrandás el nodo (más CPU/RAM) |
| Tolerancia a fallos | Alta (se reparte el riesgo) | Menor (todo en una máquina) |
| Encaja con | Agentes con mucho I/O y espera | Agentes con lógica intensiva por paso |
Acá el hosting importa. Si vas a repartir agentes en varios nodos, necesitás una infraestructura cloud que te deje sumar capacidad sin fricción y con red de baja latencia entre instancias. Para proyectos en la región, donweb.com tiene cloud y VPS para armar ese tipo de despliegue horizontal sin depender de un único servidor.
¿Cuáles son los componentes críticos de una arquitectura agentic empresarial?
Son seis pilares, según la fuente, y ninguno es opcional si querés que el sistema aguante en producción:
- Capacidad de CPU adecuada: planificada por densidad de agentes por vCPU, no por conteo suelto.
- Acceso a datos resiliente: los agentes leen y escriben todo el tiempo; si la data access se cae o se satura, el agente se traba.
- Uso de tools consciente de políticas (policy-aware): el agente ejecuta acciones reales, así que cada tool call tiene que respetar permisos y governance.
- Observabilidad: trazas y métricas de latencia por tarea; sin esto no diagnosticás nada.
- Gestión de memoria: manejar el estado y el contexto del agente entre pasos sin que se desborde.
- Planificación y escalado predecibles: poder proyectar capacidad y crecer sin sorpresas.
Lo interesante es cómo se encadenan. Un agente planifica un paso, llama a un tool con permisos, lee el resultado desde una fuente de datos, guarda el estado en memoria, y si falla reintenta mientras la observabilidad registra cuánto tardó cada eslabón, y todo eso tiene que sostenerse cuando en vez de un agente hay cientos corriendo en paralelo sobre la misma plataforma.
¿Qué encontró Intel después de miles de experimentos?
Intel resumió sus hallazgos en cinco lecciones prácticas para líderes de empresa, todas salidas de correr miles de experimentos de cargas agentic: Complementá con herramientas Google para empresas.
- La IA agentic es un problema de sistema más grande, no solo de inferencia.
- La mayoría de los harnesses actuales son limitados y no miden el performance del sistema completo.
- La capacidad se planifica por densidad de agentes por vCPU, no por cantidad de agentes.
- Hay que monitorear la latencia de tarea, no solo el uso promedio de CPU.
- Por defecto, scale-out para hostear agentes; el scale-up queda reservado para cómputo pesado por agente o límites de arquitectura.
El hilo conductor: dejá de mirar el modelo como si fuera todo el sistema. El valor empresarial del agente depende de la orquestación de tareas, el acceso a datos, la ejecución de tools, el manejo de latencia, la governance y una infraestructura que escale. La inferencia es una pieza, no la película.
Errores comunes al desplegar agentes IA
Estos son los tropezones que se repiten, y cómo evitarlos.
- Medir el modelo y no la tarea. Optimizás tokens por segundo y la tarea igual tarda una eternidad porque el cuello está en los datos o los tools. Corregilo midiendo latencia end-to-end por tarea (p95/p99).
- Dimensionar por cantidad de agentes. “Necesito correr 500 agentes” no te dice cuánto hardware comprar. Medí densidad por vCPU con tu carga real y proyectá desde ahí.
- Confiar en el CPU promedio. Un 40% de uso puede convivir con tareas colapsadas en la cola. Sin trazas por paso, no lo ves venir.
- Ir directo a scale-up. Agrandar el nodo parece la salida fácil, pero para agentes con mucha espera perdés paralelismo y tolerancia a fallos. Empezá por scale-out.
- Dejar la governance para después. Si el agente ejecuta acciones reales sin tool use policy-aware, un permiso mal puesto se traduce en una acción no autorizada sobre un sistema productivo.
Preguntas Frecuentes
¿Qué es un agente IA empresarial?
Es un proceso de workflow automatizado y orientado a un objetivo que planifica una tarea multipaso, llama a herramientas, lee los resultados y reintenta cuando algo falla. Ejecuta trabajo de negocio de punta a punta a través de personas, flujos, datos y sistemas, a diferencia de un chatbot que solo conversa.
¿Qué infraestructura necesito para implementar agentes IA?
Una plataforma con seis pilares: capacidad de CPU adecuada, acceso a datos resiliente, uso de tools consciente de políticas, observabilidad, gestión de memoria y planificación y escalado predecibles. Según Intel, tratarlo solo como inferencia de modelo es el error de base más frecuente.
¿Cómo debo escalar un sistema con agentes IA?
Por defecto, scale-out: sumás más nodos en vez de agrandar uno solo. El scale-up (agrandar el nodo) se reserva para cargas con cómputo pesado por agente o límites de arquitectura. Los agentes pasan mucho tiempo esperando, así que repartirlos da más paralelismo y tolerancia a fallos.
¿Qué métricas debo monitorear en agentes IA en producción?
La latencia de tarea end-to-end (p50, p95, p99) por encima del uso promedio de CPU. También conviene medir la tasa de reintentos y trazar cada paso (plan, tool call, lectura de datos). El CPU promedio puede verse bien mientras las tareas se acumulan en la cola.
¿Cuál es la diferencia entre agentic AI y un chatbot tradicional?
El chatbot responde en lenguaje natural; el agente ejecuta tareas completas. El agente planifica pasos, invoca herramientas, procesa resultados y reintenta ante fallos, mientras que el chatbot se limita a la conversación. Por eso el agente se evalúa por tarea terminada y latencia, no por calidad de respuesta.
Conclusión
El aporte de Intel es un cambio de foco. Durante meses el debate agentic giró alrededor de qué modelo elegir, y los datos de estos experimentos empujan la conversación hacia la plataforma: densidad por vCPU, latencia de tarea, scale-out y governance. Si estás armando infraestructura agentic AI empresarial, dejá de dimensionar por cantidad de agentes y de mirar el CPU promedio.
¿Qué hacer con esto la semana que viene? Instrumentá latencia por tarea con trazas por paso, medí cuántos agentes por vCPU sostenés con tu carga real antes de que el p95 se dispare, y planificá el crecimiento con scale-out. La inferencia es una pieza. El sistema es el juego.