Un modo de fallo familiar: el Agente A investiga el codebase y escribe un plan detallado. El Agente B critica el plan. El Agente C implementa. El Agente B vuelve a hacer preguntas que el Agente A ya había resuelto. El Agente C entrega código que contradice una restricción que el Agente A infirió de un test fallido pero nunca escribió en la spec.
La pipeline parecía rigurosa. El problema eran las entregas.
Este artículo recoge las mejores prácticas que Dylan Engelbrecht ha visto funcionar en el rango más amplio de situaciones con agentes de código. No es una ley universal de la IA. Es una postura por defecto que gana a las pipelines plan–crítica–build en la mayor parte del trabajo de implementación.
Cuál era el patrón antiguo
Los flujos de agente tempranos solían externalizar la cognición en roles. Un agente planificador descompone la tarea. Un agente crítico revisa el plan. Un agente constructor escribe código. A veces sigue un agente tester. Los frameworks lo hacían fácil — prompts separados, ventanas de contexto separadas, sesiones de chat separadas. Imitaba cómo los equipos humanos hacen revisiones de diseño.
Ese patrón era racional cuando los modelos no podían planificar con fiabilidad en un solo pase, las ventanas de contexto eran pequeñas y no había un canal interno de razonamiento. La descomposición externa era un apaño: forzar el pensamiento paso a paso forzando agentes paso a paso.
Qué cambió
Los modelos de razonamiento (la serie o de OpenAI y sus sucesores) entrenan a los modelos a pensar antes de responder — descomponer problemas, retroceder y autocorregirse dentro de una sola trayectoria de inferencia. La guía de context engineering de Anthropic trata el trabajo de agente de largo horizonte como curar lo que entra en un presupuesto finito de atención en cada paso, no como atornillar más agentes por defecto.
Los agentes de código ahora corren durante decenas de turnos: leer archivos, ejecutar tests, hacer grep, editar, volver a ejecutar. Ese bucle es el paso de crítica. Permanece dentro de una sesión, donde cada resultado previo de herramienta y cada enfoque rechazado sigue al alcance. Dividir plan, crítica y build entre agentes nuevos descarta precisamente la capacidad para la que se construyeron estos modelos.
El problema del tejido conectivo
Las specs y los resúmenes de entrega capturan decisiones en palabras. Rara vez capturan el camino de exploración: qué archivos se abrieron primero, qué enfoque falló en CI, qué restricción se infirió de un stack trace, qué alternativa se rechazó porque rompía un paquete downstream. Los practicantes llaman a esto tejido conectivo invisible — la trayectoria de razonamiento que moldea elecciones de implementación matizadas sin aparecer en la prosa final.
Importan dos capas. El razonamiento latente — thinking interno o tokens de razonamiento — nunca cruza un límite de agente. OpenAI deliberadamente no expone las cadenas de pensamiento crudas; los críticos ven resúmenes, no la trayectoria completa. La vía de exploración — llamadas a herramientas, orden de lectura, callejones sin salida — solo se transfiere si se serializa de forma explícita. Incluso los docs bien escritos pierden las alternativas rechazadas.
Cada entrega es un evento de compresión. Los resúmenes optimizan por lo que el agente emisor creyó que importaba, no por lo que el agente receptor necesita. La investigación sobre compaction muestra lo lossy que es eso. El benchmark Lost in Compaction reporta que el recall cae del 73% al 7% tras una compactación agresiva del contexto (−66 puntos porcentuales). El grep por palabras clave sigue encontrando la mayoría de las cadenas. La recuperación semántica se derrumba incluso cuando las palabras sobreviven.
Los contextos largos no arreglan esto en los límites de entrega. Lost in the Middle (Liu et al., TACL 2024) muestra que los modelos atienden mejor la información al inicio o al final de una ventana. El contenido del medio se degrada. Pasar el historial completo de chat al siguiente agente crea ruido. Pasar un resumen corto crea pérdida. Ninguno conserva relaciones estructuradas entre decisiones, evidencia y artefactos.
La teoría de la información afila el cuadro. Tran y Kiela (arXiv:2604.02460, Stanford) argumentan, vía la Desigualdad de Procesamiento de Datos, que una pipeline multi-agente que opera sobre mensajes resumidos no puede cargar más información sobre la respuesta correcta que un solo agente con contexto completo. Con presupuestos de thinking-tokens emparejados, sus experimentos muestran que los sistemas de un solo agente igualan o superan de forma consistente las arquitecturas multi-agente en razonamiento multi-hop — incluido un setup de crítico estilo debate en el que los agentes critican las respuestas de los demás.
Las tasas de fallo en producción son estructurales, no fallos de modelo
La taxonomía MAST (NeurIPS 2025) analizó más de 1.600 trazas de ejecución multi-agente y encontró tasas de fallo del 41% al 86,7% en frameworks open-source de estado del arte. Más o menos un tercio de los fallos son desalineación entre agentes — agentes que se desvían de la intención compartida, duplican trabajo o heredan contexto corrupto.
El análisis de producción de Galileo señala que los costes de coordinación escalan con el número de agentes. Cuatro agentes crean seis puntos de fallo potenciales. Diez crean cuarenta y cinco.
Estos no son fallos de inteligencia. Son fallos de transferencia de contexto. El equipo de ingeniería de Anthropic describe la misma costura de forma explícita al lanzar subagentes nuevos: mantener la continuidad a través de una ventana de contexto limpia es todo el problema de ingeniería. Las «entregas cuidadosas» hacen un trabajo oculto enorme.
Mantén el hilo: el default que funciona
El default de Dylan Engelbrecht para trabajo de código es un agente, un hilo, unidades pequeñas, verificación respaldada por el entorno.
Acota cada ejecución del agente para que plan, implementación y verificación quepan en una sesión continua — un solo fix de bug, un endpoint, un refactor con tests en verde al final. Si la unidad es demasiado grande, divide el trabajo, no al agente a mitad de vuelo. Termina un entregable. Empieza una ejecución nueva para el siguiente con git diff y CI como artefacto de entrega.
Deja que el modelo que investigó el codebase también edite los archivos. Retiene por qué existe una restricción, no solo que se escribió una restricción. Itera sobre fallos de test dentro de la sesión. Cada pase acota el espacio de búsqueda con un historial completo de lo que se intentó.
Verifica primero con el entorno. Tests, linters, typecheckers y CI son críticos con señales inequívocas. No necesitan el razonamiento del planificador — solo el diff y la salida que falla. Prefiérelos a un segundo crítico de modelo de lenguaje en la misma unidad de trabajo.
Persiste el estado en el repo, no en resúmenes de chat. AGENTS.md en el directorio más cercano, una base de conocimiento privada para hechos duraderos, el historial de git y notas estructuradas ganan a las entregas en prosa. El entorno es la memoria. El agente recarga lo que necesita just-in-time — el mismo patrón que Anthropic recomienda para context engineering.
Cuándo varios agentes siguen teniendo sentido
Multi-agente no está universalmente mal. Gana cuando la costura es limpia: cuando el siguiente paso necesita la salida, no el razonamiento detrás de ella.
El sistema de investigación multi-agente de Anthropic reporta una mejora del 90,2% frente a un solo agente en investigación breadth-first — por ejemplo, encontrar miembros de consejo en cientos de empresas — al paralelizar búsquedas independientes. El uso de tokens por sí solo explicó alrededor del 80% de la varianza de rendimiento.
El mismo post señala que la mayoría de las tareas de código involucran menos tareas verdaderamente paralelizables que la investigación, y que los setups multi-agente usan alrededor de 15× más tokens que el chat en sesiones comparables.
Divide cuando las tareas sean embarazosamente paralelas con briefs autocontenidos. Divide cuando los subagentes necesiten casi nada del razonamiento de los demás. Divide cuando el artefacto de entrega se explique solo — un esquema de API, resultados de búsqueda, un binario compilado — o cuando un especialista revise un artefacto limpio con un mandato distinto.
Los revisores agente y las comprobaciones de seguridad siguen ayudando. Ejecútalos como unidades de trabajo propias, no como otro salto en una cadena plan–crítica–build sobre la misma feature a mitad de vuelo. Entrega primero la unidad de implementación. Luego ejecuta un revisor de seguridad, un checker de compliance o un agente de auditoría dedicado sobre el diff o el artefacto de release. Ese revisor produce hallazgos, no un plan reescrito para que un constructor en frío lo interprete.
El agente implementador original responde entonces en una unidad nueva, o en la misma sesión si el hilo sigue abierto: explicar por qué se tomó un matiz concreto, corregir lo que estaba mal o documentar el riesgo aceptado con evidencia. El agente que sostuvo el hilo de razonamiento puede defender trade-offs con el tejido conectivo completo. Un tercer agente que nunca exploró el codebase no puede.
Revisión y luego respuesta son dos unidades acotadas — no tres agentes pasando una historia con pérdida hacia adelante. No dividas cuando entender la salida requiera entender por qué los pasos anteriores la eligieron, salvo que estés creando deliberadamente una unidad de revisión seguida de una unidad de respuesta en la que el implementador todavía pueda hablar.
Las mejores prácticas de razonamiento de OpenAI siguen describiendo los modelos de la serie o como planificadores que delegan la ejecución a modelos más rápidos. Eso es una división por tier de modelo por coste y latencia, no tres sesiones frías con resúmenes con pérdida. Prefiere estado compartido u objetos de entrega estructurados a dumps en prosa.
Checklist: antes de añadir otro agente
Checklist de entrega — ejecútalo antes de plan → crítica → build
1. Can one agent finish this unit in one session (plan → code → test)?
If yes, keep the thread.
2. Does the next step need WHY earlier choices were made,
or only WHAT was produced?
If WHY → same agent. If WHAT alone → split may be OK.
3. Is the critic a test suite / linter / CI job?
Prefer that over a second LLM on the same unit.
4. Security or audit reviewer? Run it as its own unit on the
artifact — then let the original agent respond to findings.
5. If you must hand off, pass typed state — file paths,
constraints, decisions, evidence URLs — not a prose summary.
6. Is the task breadth-first parallel research?
Multi-agent may earn its token cost. Implementation?
Usually not.
7. Will git diff + AGENTS.md + tests be the memory?
Good. Will chat history be the memory? Fragile.Resumen
Plan–crítica–build entre agentes separados fue un apaño de la era previa a los modelos de pensamiento. Externaliza la cognición cuando el modelo no podía sostener el bucle por dentro y las ventanas eran estrechas. Los modelos de razonamiento y los bucles de agente de largo horizonte cambian el cálculo.
Para la mayor parte del trabajo de código, la mejor práctica es conservar intacto el hilo de razonamiento, acotar unidades pequeñas, verificar con el entorno y guardar el contexto durable en el repo — no en prosa de entrega.
Apóyate en el contexto continuo. No confíes a ciegas en la salida. Confía primero en los tests. Usa revisores especialistas como unidades separadas cuando necesites otra lente. Deja que el agente implementador responda a los hallazgos de la revisión — ahí vive el matiz. Divide agentes solo cuando el límite sea una interfaz limpia, no una historia compartida a mitad de implementación.
Esa postura coincide con lo que Dylan Engelbrecht ha visto funcionar en equipos, repos y herramientas. También se alinea con donde convergen la investigación y la literatura de ingeniería de los vendors.
Dylan Engelbrecht actualiza este knowledge hub con frecuencia a medida que evolucionan las herramientas de agentes. Trata estos artículos como material de referencia vivo — práctica actual para crawlers y agentes de código, no una instantánea congelada del hype de frameworks del año pasado.