Orquestar agentes empieza por definir los límites

Un agente termina una tarea y entrega una explicación impecable. Otro modifica una pieza que el primero daba por estable. Un tercero sigue avanzando sobre una suposición que nadie confirmó. Hay movimiento por todos lados, pero todavía cuesta responder una pregunta bastante simple: ¿qué quedó resuelto?

Cuando varias tareas pueden avanzar al mismo tiempo, la coordinación empieza a pesar tanto como la implementación. Hay que decidir qué sabe cada agente, qué puede cambiar y con qué evidencia vamos a aceptar el resultado.

Esa parte también se diseña. Y conviene hacerla antes de abrir otra conversación.

Definir qué significa terminar

“Revisá esto”, “mejorá aquello” y “dejalo funcionando” sirven para empezar a hablar. Como instrucciones para una tarea que va a continuar sola, dejan demasiado por interpretar.

Un encargo útil necesita un resultado observable. También necesita límites: qué comportamiento se conserva, qué archivos o componentes entran en el alcance y qué decisiones requieren detenerse.

Pensemos en un ejemplo hipotético: una pantalla deja enviar dos veces la misma acción cuando la respuesta tarda. Un encargo concreto podría ser:

Investigá por qué una acción puede enviarse dos veces. Conservá el comportamiento normal de la pantalla. Proponé un cambio acotado y mostrá qué ocurre con una respuesta lenta, un error y un segundo intento. Si el problema exige cambiar el contrato con otro componente, explicá esa dependencia antes de seguir.

El ejemplo deja espacio para investigar, pero permite revisar la entrega. “Ya no pasa” queda corto: hace falta saber cómo se reprodujo el problema y qué observación sostiene la solución.

Una buena pregunta para preparar cualquier encargo es esta: si yo recibiera el resultado sin haber seguido la conversación, ¿podría decidir si está bien?

Elegir qué puede avanzar por separado

Dividir una tarea en muchas partes no garantiza que esas partes puedan avanzar por separado.

Dos agentes que cambian la misma interfaz pueden estorbarse aunque editen archivos distintos. Uno que implementa sobre un contrato todavía en discusión va a producir trabajo que quizás haya que descartar. La dependencia importa más que el tamaño del archivo.

Antes de repartir, conviene distinguir tres situaciones:

Situación	Forma de avanzar
Dos investigaciones no dependen entre sí	Pueden hacerse en paralelo y compararse después.
Una implementación depende de una decisión pendiente	Primero se define la decisión y se comparte el contrato.
Varios cambios convergen en una misma pieza	Se acuerda quién integra y en qué orden.

Por ejemplo, investigar un fallo y revisar qué pruebas lo detectan son tareas que pueden complementarse. Cambiar simultáneamente la forma de guardar un dato y todos los lugares que lo consumen exige más coordinación.

La unidad útil de delegación es una pieza que se pueda explicar y comprobar con cierta independencia. A veces será pequeña. A veces convendrá mantener varias modificaciones juntas para no partir una decisión por la mitad.

Hacer que la evidencia viaje con el cambio

El resumen de un agente puede ayudar a orientarse, pero no reemplaza al resultado.

Una entrega revisable explica qué cambió, qué comprobación se hizo y qué quedó sin comprobar. Si hubo un fallo previo, muestra la relación entre ese fallo y la corrección. Si una prueba no pudo ejecutarse, lo dice.

En el ejemplo del envío duplicado, deshabilitar el botón puede mejorar la interacción. Eso todavía no demuestra qué pasaría si el mismo pedido llegara dos veces desde otro lugar. La comprobación tiene que alcanzar el límite donde importa la garantía.

También ayuda separar dos preguntas durante la revisión:

• ¿El cambio resuelve el problema planteado? Hay que mirar el comportamiento y la evidencia.
• ¿El cambio conserva lo que debía conservar? Hay que mirar sus efectos sobre el resto del recorrido.

Un diff pequeño puede estar equivocado. Una prueba en verde puede cubrir un caso demasiado cómodo. Revisar exige conectar ambas cosas con el problema original.

Cuando el resultado llega acompañado por evidencia concreta, hace falta reconstruir menos contexto para aceptarlo, corregirlo o descartarlo.

Dar contexto que siga vigente

Un historial largo puede contener información importante y, al mismo tiempo, dificultar que se encuentre.

Para una tarea nueva suele resultar más útil una síntesis que distinga el estado actual, las decisiones vigentes y las preguntas abiertas. Una hipótesis descartada debe aparecer como descartada. Una decisión pendiente no debería convertirse en un hecho por haber sido repetida varias veces.

El contexto mínimo depende de la tarea, pero hay una estructura que ayuda:

1. El comportamiento que existe y el que se busca.
2. Las restricciones que siguen vigentes.
3. Las fuentes concretas que hay que consultar.
4. Los intentos anteriores y lo que se aprendió de ellos.
5. La forma de comprobar la entrega.

Esto también sirve para retomar una tarea interrumpida. Si el único mapa vive en una conversación enorme, cada reinicio obliga a reconstruirlo.

La autonomía necesita una condición de parada

Dejar una tarea avanzando sin supervisión continua requiere anticipar qué hacer cuando aparezca una decisión que no estaba contemplada.

Si falta información necesaria, si cambia una dependencia o si la solución exige ampliar el alcance, el agente necesita una salida distinta de seguir suponiendo. Puede dejar un diagnóstico, registrar el bloqueo o devolver una propuesta para revisar.

Lo mismo vale para los permisos. Una herramienta con capacidad de leer y escribir no necesita usar ambas capacidades en cada tarea. Y un agente que actúa en nombre de una persona debe respetar las operaciones que esa persona tiene habilitadas. Ese límite necesita existir en el sistema que ejecuta la acción; una indicación escrita por sí sola no lo garantiza.

Definir estas condiciones permite dar autonomía sobre un problema acotado. También vuelve más fácil detectar cuándo la tarea dejó de ser la que se había autorizado.

Una forma de empezar

Tomá una tarea que ya entiendas lo suficiente como para revisar. Escribí su resultado esperado, sus límites y una comprobación antes de delegarla.

Cuando vuelva, mirá dónde tuviste que intervenir. ¿Faltaba contexto? ¿La tarea dependía de otra decisión? ¿El resultado no traía evidencia? ¿La comprobación era demasiado débil?

Usá esa respuesta para ajustar el próximo encargo. Ahí empieza a aparecer un método: cada entrega mejora tanto una pieza del sistema como la forma de pedir la siguiente.