Sus agentes no romperán primero el stack de IA. Romperán los sistemas construidos para el ritmo humano
El control de código de Anthropic, los backtests de Third Moment y el planificador de Databricks chocan con el mismo límite: sistemas dimensionados para personas.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
La mayoría de las revisiones de riesgos de IA empresarial miran el modelo y el agente: a qué puede acceder, qué podría decir, qué podría hacer. Rara vez miran lo que el agente hará con todo lo demás. Los informes de ingeniería de esta semana sugieren que ahí es donde aparecen realmente los primeros problemas de producción a escala.
Los cambios fusionados de Anthropic crecieron de unos 2,500 a más de 30,000 por día en cuatro meses, y las suposiciones de Git se rompieron antes que su almacenamiento. Los agentes de investigación de Third Moment quemaron sus presupuestos haciendo polling de un backtest de tres horas. Los investigadores de Databricks lanzaron ocho veces más trabajos de entrenamiento una vez que los agentes ejecutaron experimentos, y encontraron que los inicios lentos y los errores confusos se convirtieron en el cuello de botella. Ninguno de estos fue un fallo del modelo. Cada uno fue un sistema diseñado en torno a cómo trabajan las personas, encontrándose con software que funciona de manera diferente.
Nuestra opinión, y es una opinión construida a partir de estas señales más que una ley medida: los primeros sistemas en fallar bajo la adopción de agentes son los dimensionados para el ritmo humano. Las personas actúan unas pocas veces por hora, toleran esperar, leen errores ambiguos con criterio y están limitadas en número. Los agentes actúan continuamente, nunca se cansan de reintentar, leen los errores literalmente y se multiplican a demanda.
Una auditoría de tempo
La respuesta práctica es una auditoría de los sistemas que los agentes tocarán, hecha antes de que llegue el volumen. Para cada uno, anote la suposición que hace sobre sus usuarios, qué se rompe cuando esa suposición falla, y la primera señal que verá.
| Asume | Se rompe al ritmo de los agentes como | Primera señal | |
|---|---|---|---|
| Control de código | Commits ocasionales, copias locales completas | Carga de clonación y fetch, espejos retrasados | Minutos de CI por cambio fusionado en aumento |
| Revisión de código | Una persona lee cada cambio | Una cola que nadie puede vaciar, o aprobaciones a ciegas | Espera media para revisión creciendo más rápido que la producción |
| CI y cola de fusión | Las fusiones llegan una a la vez | Colas serializadas que nunca drenan | Tiempo en cola superando el tiempo de compilación |
| Planificadores de trabajos | Usuarios pacientes que leen los errores | Reintentos, polling y fallos malinterpretados | Tiempo de lanzamiento y tasa de reintentos por trabajo |
| Flujos de aprobación | Unas pocas solicitudes al día por aprobador | Fatiga de aprobación; la aprobación deja de significar revisión | Tiempo de aprobación colapsando a segundos |
| Cuotas y licencias | Límites por persona o asiento | Limitación de velocidad, facturas sorpresa, identidades compartidas | Errores de límite de velocidad y picos de gasto por agente |
Dos filas merecen especial atención, porque fallan silenciosamente. Un sistema de control de código bajo carga se vuelve lento y alguien lo nota. Un proceso de revisión bajo carga sigue funcionando: las aprobaciones aún ocurren, simplemente sin que nadie lea. Una aprobación que toma cuatro segundos es una firma, no una revisión. Ese es el costo que describimos en la verificación como el nuevo cuello de botella, visto desde el lado de la infraestructura.
Tres movimientos de diseño que ayudan en todas partes
Reemplace la espera con señales. El polling es el equivalente del agente a una persona refrescando una página, multiplicado por miles. Las devoluciones de llamada de finalización, las notificaciones de eventos y las esperas duraderas lo eliminan. La solución de Third Moment fue trabajos más rápidos; la solución más general es nunca hacer que un agente pregunte “¿ya está listo?”
Fije lo que los agentes ejecutan. Los agentes activan pipelines con mucha más frecuencia que las personas, por lo que cualquier cosa que pueda cambiar debajo de un pipeline importa más. Los nuevos archivos de bloqueo de flujos de trabajo de GitHub, en preview pública desde el 14 de octubre, fijan Actions y flujos de trabajo reutilizables, incluidas las dependencias transitivas, a commits específicos mientras los archivos de flujo de trabajo mantienen sus referencias existentes, y los administradores pueden exigirlos por política. Un archivo de bloqueo no hace que un commit fijado sea seguro, pero evita que una dependencia cambie después de la revisión sin un cambio en su repositorio.
Dé a los agentes sus propias cuotas e identidades. Las cuentas de servicio compartidas y los límites por asiento ocultan quién consume qué. Las cuotas por agente hacen visible la carga y el límite una decisión, que es el archivo de agente con presupuesto que defendimos antes.
Ejecute la auditoría antes de que el piloto escale
El momento más barato para encontrar un problema de tempo es antes de que un piloto exitoso se copie en toda la empresa. Una regla útil: cuando un equipo propone escalar un agente diez veces, pregunte cuál de los seis sistemas de la tabla cargará, y quién es responsable de cada uno. Si nadie puede responder, el plan de escalado es un plan de modelo, no un plan de producción.
El consejo de Anthropic a otras empresas fue llevar las ideas de Scion a Git en lugar de adoptar Scion. Lo mismo aplica aquí. Nadie necesita reconstruir su infraestructura para agentes en 2026. Todos los que los despliegan necesitan saber en qué suposiciones sobre el ritmo humano confían silenciosamente sus sistemas, y cuáles están a punto de retirar los agentes.