> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2026/w33-five-steps-toward-the-future-work-paradigm-seen-through-agent-teams.md). # W33-Cinco escalones hacia la forma de trabajar del futuro, vistos desde los equipos de agentes Hace poco, Boris Cherny, responsable de Claude Code, publicó una tabla titulada [Etapas de adopción de la IA](https://docs.google.com/document/d/1R91ayvj7uvlxgNi--__2-Bf3w8x5r1nF-xIBN7ds8Ns/edit). En su [publicación original](https://x.com/bcherny/status/2077929379661844559) señaló un fenómeno recurrente. Una persona del equipo aumenta su producción en un orden de magnitud con ayuda de Claude, pero el resto de la organización no la sigue. La observación se parece mucho a lo que he vivido últimamente. La distancia que crea la IA ya no se limita a la habilidad para usar herramientas. Distintas personas están trabajando bajo paradigmas completamente distintos. Boris divide la adopción de IA en cinco niveles, de L0 a L4. Más exactamente, son cinco estados y cuatro transiciones. Prefiero entenderlos como cinco escalones hacia la forma de trabajar del futuro. ## Los cinco escalones | Nivel | Papel de la persona | Forma de trabajar | Principal cuello de botella | | ------------------------ | ------------------------ | --------------------------------------------------------------------------------------------- | ----------------------------------------- | | L0 Restringido | Observador | Quiere usar IA, pero los modelos realmente capaces no tienen acceso al trabajo | Permisos de acceso | | L1 Asistido | Compañero de trabajo | Colabora con un agente: este ejecuta y la persona revisa paso a paso | Atención humana | | L2 Paralelo | Orquestador | Organiza varios agentes a la vez; ejecutan y se verifican, y la persona acepta los resultados | Capacidad de revisión | | L3 Autonomía supervisada | Gestor de gestores | Las tareas programadas o los eventos inician el trabajo; la persona aprueba las excepciones | Confianza y capacidad de tomar decisiones | | L4 Nativo de IA | Definidor de intenciones | Cientos o miles de agentes trabajan según objetivos; la persona gestiona por excepciones | Juicio de valor y gobernanza | El número de agentes en la tabla de Boris va de 0 a 1, 10, 100 y más de 1000. Son órdenes de magnitud, no requisitos para subir de nivel. El cambio importante está en el papel de la persona. En L1, la persona sigue al volante de cada tarea. El agente se parece a un asistente muy rápido. En L2, la persona empieza a diseñar el reparto del trabajo, controlar el contexto y fijar criterios de aceptación. Varios agentes avanzan en paralelo, mientras la atención humana se concentra en los resultados y las excepciones. L3 da otro paso. Ya no es la persona quien inicia cada tarea. El sistema empieza a escuchar eventos, ejecutar planes, detectar problemas y crear trabajo por iniciativa propia. La persona deja de gestionar cada agente y pasa a gestionar el sistema de trabajo que forman. ## Varios agentes no forman necesariamente un equipo Hasta ahora nos hemos centrado en hacer más capaz a cada agente y en que complete tareas más largas y complejas. Pero la capacidad de un agente tiene límites, así que cada vez más personas utilizan varios a la vez. Con más agentes aparecen nuevos problemas. La capacidad individual deja de ser el único cuello de botella. La forma de organizarlos empieza a determinar el límite del conjunto. Si cada trabajo sigue exigiendo que una persona elija el punto de entrada, prepare los antecedentes, traslade el contexto y pase el resultado de un agente a otro, esos agentes siguen siendo, en esencia, herramientas independientes. La persona continúa siendo el único enrutador del sistema y su cuello de botella de hecho. Un equipo de agentes, tal como yo lo entiendo, tiene tres características. Primero, cada agente se ocupa de su dominio de forma continuada. Sabe qué debe tratar, dónde están sus límites y qué problemas no le corresponden. Segundo, parte de la responsabilidad de colaborar pasa de la persona a los agentes. Estos enrutan, transfieren el trabajo y devuelven resultados dentro de relaciones de responsabilidad explícitas, sin exigir que la persona conecte cada paso. Tercero, la persona sigue dentro del equipo, pero cambia de posición. Vuelve cuando hacen falta dirección, hechos, decisiones, revisión o autorización, y deja de vigilar todo el proceso de ejecución. Pero en cuanto deja de participar en cada paso surge otro problema: ¿cómo saber qué tal está funcionando el equipo? Por eso, un equipo de agentes también debe poder observarse, comprenderse y ajustarse de forma continua. De lo contrario, solo habré pasado de coordinar personalmente cada agente a no poder ver qué están haciendo. ## La primera vez que sentí que tenía un equipo de agentes Mi experiencia más intensa de L2 vino de Multica. Al principio creé un Engineering Squad en Multica para construir un MCP conectado con la plataforma de alojamiento de código de la intranet de la empresa. En las primeras versiones, Claude se ocupaba de la estrategia, la descomposición y el enrutamiento; Codex, de la implementación; y Gemini, de la exploración y la validación independiente. Yo conservaba la intención de producto, las prioridades, las decisiones de compromiso y la aprobación final. Por primera vez, esta combinación me dio una fuerte sensación de equipo. Una vez aclarados el objetivo y los límites, el líder seguía dividiendo las tareas y elegía al agente adecuado para explorar, implementar y validar. Solo recibía una notificación cuando había algo que requería mi criterio; entonces volvía a la tarea para decidir. Al comienzo de una tarea, dos documentos se contradecían sobre el estilo de la interfaz y la autenticación. El líder no puso a Codex a programar de inmediato. Primero encargó una exploración acotada, un spike. La tarea debía responder solo a unas preguntas de hecho, aportar solicitudes reales como evidencia y, de forma explícita, no implementar el MCP. Unos minutos de exploración evitaron una implementación completa equivocada. La validación posterior también mostró el verdadero valor del equipo. Un informe utilizaba una respuesta 401 obtenida con un token inválido para demostrar que cierto mecanismo de autenticación no existía. La conclusión era correcta por casualidad, pero el razonamiento no era válido. En otra ronda pasaron todas las pruebas, pero el único fixture real era un arreglo vacío. No se había comprobado en absoluto la estructura de campos con datos no vacíos. Los informes no eran falsos. Eran correctos, pero incompletos. El líder tenía que volver a examinar la evidencia con otra función objetivo, y quien implementaba y quien validaba no podían compartir la misma lógica de autoconfirmación. La tarea terminó por establecer varias reglas estables. La exploración acotada precede a la implementación. El autor no puede ser el único revisor de un cambio de alto riesgo. La evidencia debe decir tanto qué demuestra como qué no demuestra. Las acciones visibles externamente, irreversibles o que impliquen actuar con el respaldo de una identidad se detienen y pasan a una persona. Esa es mi experiencia directa de L2. Una persona empieza a disponer de un equipo de entrega con un costo de coordinación muy bajo. ## De una configuración puntual a un modelo operativo Después empecé a convertir mi uso de Multica en un modelo operativo mantenible, en lugar de una configuración temporal, y lo organicé en un repositorio de Git. Lo más importante fue separar cuatro objetos. | Objeto | De qué se ocupa | Ritmo de cambio | | ------------------ | ------------------------------------------------------------------------------------ | ----------------------------------------- | | Profession Profile | Responsabilidades del rol, límites de decisión, herramientas y contrato de evidencia | Estable y versionable | | Agent Instance | Entorno de ejecución concreto, modelo, permisos y concurrencia | Reemplazable | | Squad | Misión persistente, reglas de enrutamiento y relaciones entre miembros | Se ajusta a las colas de trabajo estables | | Issue Run | Objetivo, contexto, evidencia y riesgo residual de una tarea | Distinto en cada tarea | Su valor central consiste en separar los contratos estables del despliegue variable. Las responsabilidades de los roles deben ser estables. Delivery Lead se ocupa de forma continuada de descomponer, enrutar, resolver conflictos y consolidar la evidencia. Implementation Engineer implementa y prueba. Challenger busca contraejemplos y hace revisiones de solo lectura. Explorer-Validator se encarga de explorar contextos grandes, analizar el alcance de los efectos y validar de forma independiente. El entorno de ejecución y el modelo concretos pueden cambiar. Hoy, Delivery Lead puede ejecutarse sobre Claude; Implementation Engineer, sobre Codex; Challenger puede usar Grok; y Explorer-Validator, Gemini a través de Antigravity. Cuando cambien los modelos, podremos sustituir las instancias sin tener que reescribir al mismo tiempo las relaciones de responsabilidad del equipo. Eso no significa que intercambiar modelos carezca de costo. Hay que volver a verificar los permisos, las herramientas, las sesiones y los modos de fallo de cada entorno. Ser reemplazable significa que el contrato organizativo no depende de una marca de modelo, no que se pueda omitir la validación del despliegue. ## La configuración actual de Multica Mientras escribo este artículo, gestiono ocho Agent Instance y cuatro Squad persistentes en Multica. Los cuatro roles principales que trabajan entre squads son Delivery Lead, Implementation Engineer, Challenger y Explorer-Validator. También hay Product Architect, Market Researcher, Ops Engineer y Data Analyst para las tareas de investigación, arquitectura y fiabilidad. Los cuatro squads se organizan según colas de trabajo estables. | Squad | Condiciones de entrada | Recorrido por defecto | | ----------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Engineering | Funciones habituales, refactorizaciones, bugs corrientes y entrega de ingeniería | Claude enruta, Codex es el único que escribe, Gemini valida y Grok cuestiona cuando hace falta | | Reliability & Incident | Problemas de fiabilidad en producción, de causa desconocida, entre módulos o difíciles de reproducir | Recopilación de evidencia por varias vías de solo lectura; Claude acota hipótesis, Codex es el único que escribe la corrección y alguien distinto del autor verifica las regresiones | | Research & Architecture | Elección tecnológica, decisiones de producto, migraciones o spikes acotados | Gemini reúne evidencia, Grok ataca las hipótesis y Codex solo realiza experimentos delimitados | | Frontend Experience | Flujos de usuario, diseño visual, adaptación a pantallas, accesibilidad y validación en navegador | Gemini establece la referencia, Codex implementa y Gemini valida en la página real | Los squads no se dividen por repositorio ni se crea uno nuevo porque aparezca otro modelo. Un repositorio nuevo es solo un recurso Project nuevo. Las tareas cuyo responsable ya está claro se asignan directamente al agente correspondiente. Solo entran en un squad cuando requieren varias capacidades y no se puede determinar un responsable concreto al crear el issue. La configuración también tiene límites estrictos. Cada tarea tiene un solo responsable actual. Cada worktree tiene una sola persona o agente que escribe. La concurrencia de los agentes con escritura es 1; la de los roles sin escritura puede ser 2. El daemon local tiene un límite total de concurrencia de 3. Las acciones de producción, credenciales, publicación, envío externo e irreversibles siempre requieren mi aprobación. ## Activar solo los roles mínimos necesarios Es fácil entender erróneamente un equipo de agentes como poner a trabajar juntos a todos los modelos en cada tarea. Por lo general, eso solo aumenta el contexto, los tokens y los costos de coordinación. Un squad de Multica es, por sí mismo, un objeto de enrutamiento. Cuando se le asigna un issue, el sistema despierta primero al líder. Este lee el contexto y decide a quién encargar el siguiente paso. El squad no ejecuta automáticamente a todos sus miembros ni aumenta la concurrencia. Por eso, mi regla por defecto es activar solo el conjunto mínimo de roles suficiente para completar la tarea. Una corrección pequeña y bien delimitada puede ir directamente a Codex, sin activar un squad. En un repositorio grande desconocido o una tarea de interfaz, Gemini define primero el alcance y la referencia de validación, y después pasa el trabajo a Codex. Solo añado una revisión adversarial de Grok ante fallos difíciles de reproducir o diffs de alto riesgo. Por defecto, activo como máximo dos miembros ejecutores a la vez. El paralelismo se limita a investigaciones independientes, revisiones independientes sobre el mismo commit estable o worktrees cuyos archivos no se solapan en absoluto. Cuando varios agentes modifican el mismo estado al mismo tiempo, parece que aumenta la velocidad, pero suele acabar en conflictos y retrabajo. El número de agentes no mide la madurez de un equipo. La capacidad de orquestación consiste en activar el rol correcto en el momento correcto. ## La DoD es la interfaz entre agentes Que los agentes puedan colaborar directamente no significa que baste con decir «sigue tú». Exijo que cada delegación explicite cuatro cosas. ``` outcome: 最终可观察结果 evidence: 证明结果的测试、命令、截图、数据或链接 verification: 由谁、用什么方式验收 max_rounds: 最多返工轮数，默认 2 ``` Esta es la Definition of Done, o definición de terminado. Establece el contrato de evidencia que debe cumplirse antes de aceptar el resultado. Implementation Engineer no entrega solo código: devuelve también el alcance del cambio, el commit, los comandos de prueba y los resultados originales. El revisor independiente lee el objetivo, el diff y las pruebas; no acepta como evidencia la afirmación del autor de que ha terminado. Al cerrar el trabajo, el líder enumera los resultados reales, lo no verificado, los riesgos restantes y las cuestiones que debe decidir una persona. `max_rounds` es igual de importante. Los agentes pueden mencionarse entre sí, pero el sistema no puede decidir por mí cuándo debe terminar la colaboración. Si después de dos rondas de retrabajo la evidencia sigue en conflicto, el equipo debe detener el ciclo y trasladar la discrepancia a una persona. En Multica, que una tarea aparezca como `completed` solo indica que esa ejecución del agente terminó con normalidad. No significa que se haya cumplido el objetivo del issue. Lo que determina si la tarea puede pasar a revisión es la DoD y la evidencia. Esta distinción separa el estado de ejecución del agente del estado de finalización del trabajo. ## Un equipo de agentes también necesita ingeniería de configuración Por bien redactado que esté el prompt de un rol, no demuestra que el equipo pueda funcionar en un entorno real. Establecí el repositorio de Git como fuente de verdad de la configuración. `config/agents/` guarda los contratos de los roles; `config/squad-*.md`, las reglas de enrutamiento; y `config/topology.json`, los agentes, entornos de ejecución, permisos, concurrencia y topología de los squads. Los objetos activos de Multica son solo copias en ejecución de estas declaraciones. Por defecto, el sincronizador solo produce un plan de cambios. Se aplica después de una revisión humana y se ejecuta de nuevo: el resultado debe ser `No changes.`. Los objetos ajenos a la gestión se reportan, pero no se eliminan automáticamente. Los Workspace ID, Agent ID, tokens, webhooks y rutas locales quedan fuera del repositorio. Este mecanismo resuelve la deriva de configuración. Cuando cambian los roles o el enrutamiento, puedo ver el diff, revisarlo y volver a contrastar el estado activo con el esperado. La integración real también me mostró que un equipo de agentes es mucho más que unos cuantos prompts. El líder debe operar el plano de control de Multica sin poder escribir archivos del proyecto. Grok necesita revisar en modo de solo lectura sin heredar permisos de red y escritura demasiado amplios. Los entornos de escritorio también se ven afectados por proxies, sandboxes, argumentos de comandos y el entorno local. A medida que aparecían estos problemas, corregí la conexión directa con el plano de control, los límites del sandbox y la coincidencia de subcomandos de la CLI. Que una configuración declare algo permitido no significa que el entorno funcione bien. Cada rol crítico necesita pruebas de humo reales, tanto positivas como negativas. ## Volver a mirar los cinco escalones desde el equipo de agentes Desde esta perspectiva, los cinco escalones de la forma de trabajar del futuro consisten, en esencia, en transferir gradualmente de la persona al sistema la responsabilidad de enrutar, colaborar y validar. | Nivel | Organización de los agentes | Trabajo principal de la persona | | ----- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | L0 | Los agentes no pueden entrar en el trabajo real | Seguir usando los procesos existentes | | L1 | Varias herramientas independientes; la persona es el único enrutador | Proporcionar contexto cada vez y revisar cada resultado | | L2 | Roles y squads persistentes; el líder elige el equipo mínimo | Definir objetivos y DoD, validar evidencia y resolver decisiones clave | | L3 | La programación o los eventos activan el equipo | Gestionar excepciones, permisos, presupuestos y condiciones de parada | | L4 | Varios equipos operan según una intención y la organización puede ajustarse dinámicamente | Decidir la dirección, los valores y los límites que no se pueden delegar | Actualmente estoy entre L2 y L3. Esta configuración de Multica resuelve los roles, el enrutamiento, la evidencia y la observabilidad, pero la mayoría de las tareas todavía las creo yo. El cambio clave de L3 está en quién puede iniciar el trabajo. [Autopilot](https://multica.ai/docs/autopilots), de Multica, permite que tareas periódicas o eventos de webhook creen automáticamente issues y los asignen a un agente o squad. En [El Mac de un builder también necesita un Sweeper](https://weekly-essay.mikey.wang/es/2026/w32-a-builders-mac-also-needs-a-sweeper) escribí sobre rutinas diarias de mantenimiento de skills y revisiones semanales del entorno del Mac. Ese tipo de trabajo se acerca más a L3. Pero la capacidad de iniciar trabajo no debe adelantarse a la capacidad de verificarlo. Sin DoD, evidencia, permisos, condiciones de parada y registros observables, despertar automáticamente a más agentes solo hará que los errores ocurran antes y sean más difíciles de detectar. El equipo en conjunto sigue principalmente en L1, con la mayoría de las personas en transición hacia L2. Ya sabemos usar agentes. El siguiente paso es convertir los roles, el enrutamiento, la validación y los permisos en un sistema de trabajo compartido.