El Foco Es el Nuevo Bottleneck: Por Qué Solo Puedes Correr Tantos AI Agents Como Puedas Controlar

Tuve una llamada interesante el domingo. Una línea se me quedó. El foco es el nuevo bottleneck desde que los LLMs se volvieron buenos. No escribir código. No arreglar bugs. Controlar la orquestación. Pasado cierto número de agents, la calidad del output baja, y el trabajo se traslada de tipear a decidir qué agent corre, con qué contexto, contra qué checks. El nuevo skill set es foco, gestión de contexto y QA. Después de un año corriendo engagements reales de clientes donde la mayor parte del tiempo de teclado ahora es supervisión de agents, estoy de acuerdo.

Este post va sobre por qué existe el techo, cómo se ve en la práctica y cómo mantenemos el número de agents por debajo del techo en builds reales de Wavect.

¿Qué cambió realmente cuando los LLMs se volvieron buenos?

Durante la mayor parte de la historia del software, el bottleneck fue el throughput. Qué tan rápido puede un ingeniero senior convertir una spec en código funcional. Las herramientas se medían por cuánto quitaban de ese loop. Autocomplete, snippets, refactoring del IDE, luego Copilot, luego coding agents completos.

Para 2026, ese loop ya no existe en su mayor parte excepto para el 10% más duro del trabajo. Un operador competente corriendo un coding agent puede producir más código en un día del que un equipo de tres podía hace unos años. El constraint se movió.

El nuevo constraint no es "¿puede el agent escribir el código?". Es "¿tengo suficiente atención restante para verificar lo que produjo el agent, rutear la siguiente tarea al agent correcto y mantener el context window de cada agent lo suficientemente limpio como para que el output se mantenga honesto?". Eso es un problema de foco, no de tipeo.

¿Cómo se ve realmente el techo de orquestación?

Cualquiera que haya corrido más de dos agents en paralelo ha llegado a un momento que se siente así. El Agent A produce código que parece bien. El Agent B produce un refactor que entra en conflicto con el Agent A. El Agent C sugiere un test que no atrapa ninguno de los dos. Pasas más tiempo reconciliándolos del que ahorraste paralelizando. Añades un cuarto agent para triagear los conflictos. Introduce nuevos.

Ese es el techo. No es un número fijo. Se mueve según tres variables.

• Acoplamiento de tareas. Las tareas independientes escalan casi linealmente. Las tareas acopladas donde el output de cada agent depende del output de otro agent colapsan rápido.
• Coste de verificación. Si el output de cada agent tarda 30 segundos en validarse, 10 agents están bien. Si tarda 15 minutos, 3 es tu techo.
• Higiene de contexto. Cuanto más larga la conversación, peor el output. Pasado un umbral, cada agent se degrada silenciosamente. Dejas de notar el drift hasta que una regresión llega a producción.

¿Por qué se degrada la calidad del output pasados N agents?

De los engagements donde hemos corrido más de dos coding agents en paralelo, los modos de fallo se agrupan en siete categorías. Listados en orden de frecuencia.

1. Split de atención. El operador cambia entre agents lo bastante rápido como para que ninguno reciba una lectura completa. Errores sutiles aterrizan en producción. El fix barato es un cap duro en agents concurrentes, normalmente dos para operadores nuevos y tres a cuatro para los experimentados.
2. Bleed de contexto. Un agent que corrió una hora en la Tarea A ahora retoma la Tarea B con asunciones viejas integradas. El output parece confiado y está equivocado. Fix barato: reset duro entre tareas. Trata el context window como una herramienta, no como una memoria.
3. Eval debt. El operador corre más agents de los que la suite de evals puede seguir. La calidad cae sin que nadie lo note. El fix es invertir en TDD y evals continuas antes de escalar el número de agents, no después.
4. Impuesto de reconciliación de conflictos. Dos agents tocan el mismo módulo. Reconciliar sus outputs cuesta más que el trabajo que cualquiera produjo por separado. Fix barato: particionar el codebase por agent, no por tarea.
5. Apilamiento de latencia de tool-use. Cada agent espera por tools. Tres agents esperando por la misma fixture de base de datos serializan en el más lento. Fix barato: fixtures por agent, o menos agents.
6. Coordinación alucinada. Un agent cree que otro agent ya hizo el trabajo, porque puede ver el mensaje en la historia compartida. Nada se hizo. Fix barato: estado explícito de handoff, no coordinación asumida.
7. Fatiga del reviewer. El operador deja de leer cuidadosamente pasados 90 minutos de supervisión de agents. El fix es sesiones más cortas, no más agents.

¿Cuáles son los tres nuevos skills que necesita el orquestador?

Si el loop de tipeo está mayormente automatizado, el bottleneck es la atención del operador. Tres skills deciden si el operador escala o se atasca.

1. Disciplina de foco. Saber cuántos agents puedes supervisar sin caída de calidad. Tratar ese número como un constraint duro, no un objetivo a superar. La mayoría de operadores que hemos contratado llegan a su techo en tres agents concurrentes. Algunos se sienten cómodos en cinco. Ninguno que hayamos visto corre diez sin que caiga la calidad.

2. Gestión de contexto. Saber cuándo resetear un agent, cuándo resumir una conversación larga, cuándo arrancar un contexto fresco para la misma tarea y cuándo mantener historia. Esta es la parte del trabajo que no existía hace tres años. El ecosistema MCP está empezando a lanzar handoffs estructurados de contexto, lo que ayuda, pero el operador todavía tiene que elegir qué mantener.

3. Diseño de quality assurance. Si el operador no puede leer cada output, la suite de evals tiene que hacerlo. QA deja de ser una fase y se vuelve el loop. Tests, snapshot checks, regression suites, behavioral evals, smoke runs después de cada commit del agent. Cuantos más agents corres, más peso lleva tu stack de QA.

"El techo no es un problema de herramientas. Es un problema de atención. Comprar un agent mejor no lo sube. Invertir en evals sí."

¿Cómo racionamos el número de agents en engagements reales?

En cada engagement de IA que corremos en Wavect, la ratio operador-a-agent se establece desde el inicio y se ajusta semanalmente. Las reglas a las que volvemos.

• Dos agents concurrentes por operador, por defecto. Tres si el operador ha lanzado al menos un build AI-heavy antes. Nunca más de cinco sin un co-operador manejando reviews.
• Un agent especialista por rol, no por tarea. Un coding agent, un testing agent, un planning agent. Cada uno mantiene un rol estable en lugar de rotar por cada tipo de tarea.
• Reset duro de contexto entre epics. Cuando el trabajo se mueve a un nuevo feature, los agents empiezan frescos, incluso si su contexto anterior "casi cabe".
• Evals antes de paralelismo. Hasta que la test suite atrape regresiones de forma fiable, corremos secuencialmente. Paralelismo sin evals es un castillo de arena.
• Horas de reviewer con tope. Ningún operador corre supervisión de agents más de 4 horas al día. El tiempo restante va a arquitectura, diseño de evals y review.

Nada de esto es revolucionario. Refleja cómo operan los equipos sin IA. Lo interesante es que ahora aplica a una sola persona corriendo un enjambre de agents.

¿Cómo cambia esto a quién contratamos?

Mueve el listón de contratación. El ingeniero más valioso en 2026 no es el tipista más rápido. Es el que puede mantener cinco agents productivos sin que la calidad de su output derive. Eso es disciplina de foco, disciplina de gestión de contexto y disciplina de QA todo junto. Podemos entrenar cada una de esas. No podemos entrenar del todo la habilidad de notar que un agent ha empezado a mentir sobre lo que hizo. Esa parte viene de la experiencia.

Esto también es por qué el rol de fractional CTO está cambiando. Hace unos años el valor era criterio técnico y velocidad de entrega. Hoy, la mitad del valor es calibrar la capacidad de supervisión de agents de un equipo early y construir el andamiaje de evals que permite que esa capacidad escale de forma segura. Lo vemos en casi cada engagement AI-heavy.

Q&A para founders

¿Significa esto que los equipos pequeños le ganan a los grandes ahora? Los equipos pequeños con andamiaje fuerte de evals le ganan a los equipos grandes con uno débil. El headcount deja de ser el proxy. La capacidad de supervisión sí.

¿Los coding agents harán esto más fácil? Mejores coding agents elevan la calidad individual del output pero no la capacidad de supervisión. El techo se mueve lentamente porque la atención es el constraint vinculante.

¿Y la supervisión agent-sobre-agent? Algunos equipos lanzan "reviewer agents" que chequean coding agents. Ayudan en los márgenes. No resuelven el problema de foco porque alguien todavía tiene que supervisar al reviewer. Las capas no eliminan el presupuesto de atención del operador, lo gastan de forma distinta.

¿Cómo sabes que un agent ha empezado a derivar? Tres señales. El output es más confiado de lo que el contexto justifica. El agent deja de hacer preguntas aclaratorias. Tests que solían fallar ahora pasan sin cambios de código. Cualquiera de esas es la señal para resetear contexto.

¿Esto es solo ingeniería, o aplica también a trabajo no-code? Aplica en todos lados donde los agents tocan. Vemos el mismo patrón en automatización de soporte, en flujos de research y en pipelines RAG que rutean entre agents especialistas. Los números cambian, la forma es la misma.