Quién hace cada parte
Un agente que hace todo termina haciendo todo peor. Repartir el trabajo entre varios, cada uno con su propio contexto, no es una optimización avanzada: es lo que evita que la tarea larga se degrade a la hora.
El contexto no se comparte por defecto, se comparte por decisión. Y casi todo lo que sale mal en una sesión larga es contexto que se compartió sin que nadie lo decidiera.
Esto no es una séptima disciplina. Las seis son una afirmación, no un contenedor, y agregar una implicaría que hay una preocupación real que ninguna cubre. No es el caso: método ya pregunta “¿en qué orden se hace el trabajo, y quién hace cada parte?”. Esta página es la segunda mitad de esa pregunta.
La diferencia es que método define el procedimiento —las fases, los entregables, el presupuesto— y esto define la topología: dónde corre cada fase y con qué contexto arranca. Un mismo procedimiento repartido de dos maneras distintas da resultados distintos, y por eso la topología merece su propia página en vez de un párrafo.
Si querés el procedimiento antes que el reparto, empezá por método y volvé.
Los roles
No son productos ni configuraciones: son formas de recortar qué contexto recibe cada agente. Lo que define a un rol no es lo que puede hacer, es lo que tiene prohibido — un agente definido solo por sus permisos termina haciendo todo, y ahí volvés a tener uno solo con cinco nombres.
- Qué vive acá
- El hilo principal: el objetivo, en qué punto está la tarea y las decisiones ya tomadas. Muy poco código, y ninguno que no haya necesitado para decidir algo.
- Qué devuelve
- No devuelve, recibe. Es el único que ve la tarea entera, y esa vista completa es exactamente lo que se pierde si se le llena la ventana.
- Lo que nunca hace
- Ponerse a leer el repositorio para entender algo. En el momento en que lo hace deja de ser orquestador y pasa a ser el ejecutor más caro que tenés.
- Qué vive acá
- Una pregunta concreta y acceso al repositorio. Nada del historial de la conversación: si le contás lo que esperás encontrar, lo va a encontrar.
- Qué devuelve
- Tres frases y las coordenadas. Nunca el volcado de lo que leyó — devolver la transcripción anula el motivo por el cual lo mandaste.
- Lo que nunca hace
- Editar. Si lo dejás escribir, va a escribir con lo que entendió en un solo barrido y sin haber visto las consecuencias.
- Qué vive acá
- La especificación, los estándares del repositorio y los archivos que va a tocar. Recibe conclusiones, no transcripciones.
- Qué devuelve
- El cambio, y qué quedó afuera. La segunda parte es la que casi nunca viene y la que siempre hace falta.
- Lo que nunca hace
- Elegir el enfoque. Si llega sin enfoque decidido, lo elige solo, a mitad de camino y sin avisarte.
- Qué vive acá
- El diff y los criterios. Nada de cómo se escribió: quien conoce el argumento juzga el argumento, no lo que quedó escrito.
- Qué devuelve
- Hallazgos con archivo, línea y escenario de falla. Un hallazgo sin escenario es una opinión de estilo.
- Lo que nunca hace
- Arreglar lo que encuentra. El que revisa y arregla termina defendiendo su propio arreglo en la vuelta siguiente.
- Qué vive acá
- El contrato original y el resultado final. No participó de ninguna fase anterior, y esa es toda su utilidad.
- Qué devuelve
- Pasa o no pasa, contra el contrato. No contra lo que parece razonable a esta altura del día.
- Lo que nunca hace
- Negociar el contrato. Si el contrato estaba mal, eso es un hallazgo — no una excusa para aflojarlo y dar por buena la entrega.
Cuándo delegar y cuándo no
Las dos columnas importan. Una lista de qué delegar es un consejo; la lista de qué no delegar es lo que se aprende pagándolo, porque delegar de más falla en silencio: el trabajo igual sale, solo que lo hiciste dos veces.
Delegá
Entender algo exige abrir cuatro archivos o más.
El costo de entender se paga una sola vez, en la ventana del otro, y vuelve convertido en tres frases.
El comando escupe cientos de líneas y te importan tres.
Es la fuga de contexto más común y la menos visible: la salida entra entera aunque solo mires el final.
Hay que revisar o verificar algo que se acaba de escribir.
Acá no es por ruido, es por independencia. El mismo hilo que escribió ya tiene todos los motivos por los que está bien.
La tarea se puede partir en tandas que no se pisan entre sí.
Cada tanda entra cómoda en su propia ventana y se verifica sola. Es la única forma sana de correr algo en paralelo.
Hacelo vos
Ya sabés la respuesta y solo falta escribirla.
Delegar tiene un costo fijo. El que recibe la tarea arranca en frío y vuelve a deducir lo que vos ya tenías resuelto.
El cambio toca dos o más archivos que tienen que quedar coherentes entre sí.
Un solo autor. Dos agentes escribiendo en paralelo producen dos mitades coherentes consigo mismas y con nada más.
Es una consulta de estado: qué rama, qué cambió, qué versión hay instalada.
Delegar una pregunta de un segundo cuesta más que responderla, y además te deja esperando.
La decisión la tiene que firmar alguien.
Podés delegar la investigación de cada alternativa. La elección no, porque el que la delega no la va a poder defender después.
Dónde se van los tokens
Ninguna de estas palancas es un truco de prompt. Cada una es la cara económica de una disciplina que ya está en el sitio, y eso es justamente lo que hay que ver: el costo no es una séptima cosa para ingenierear, es lo que cubrir las seis te devuelve cuando mirás la factura. Con una excepción honesta: control es la única disciplina que también suma gasto. Correr revisores y verificadores cuesta, y ese gasto se justifica en errores que no llegan a producción, no en tokens ahorrados.
El trabajo que produce mucho texto y poca conclusión corre en otra ventana y devuelve solo el resultado.
Qué te ahorra
Proporcional al ruido que evitás — y el ahorro grande no son los archivos, es todo lo que hubieras pensado peor después de tenerlos adentro.
Un índice del código responde “quién llama a esta función” con los fragmentos exactos, sin abrir los archivos enteros.
Qué te ahorra
Diez fragmentos contra treinta archivos completos, y una respuesta en vez de una búsqueda con suerte variable.
Una regla declarada en el repositorio se envía una vez y rige toda la sesión, en vez de repetirse en cada mensaje.
Qué te ahorra
Lo que gastabas repitiéndote. Y de paso deja de depender de que te acuerdes de repetirlo, que es el ahorro que de verdad importa.
Las decisiones vividas quedan guardadas y se recuperan solas al arrancar, en lugar de que las reconstruyas a mano.
Qué te ahorra
El párrafo de contexto que escribís cada mañana — que además escribís peor cada vez, porque te vas olvidando de los detalles.
Cada herramienta conectada ocupa lugar en la ventana antes de que empiece el trabajo, la uses o no.
Qué te ahorra
Un costo fijo por mensaje. Veinte herramientas conectadas por las dudas se pagan en cada pedido, incluido el que solo pedía un typo.
Un tipo estricto o una regla de linter distingue bien de mal ejecutándose, sin consultar a ningún modelo.
Qué te ahorra
Todo lo que la comprobación ya resuelve es superficie que la revisión no tiene que mirar. Es el único ítem de esta lista que además mejora el resultado: lo mecánico no se cansa ni te da la razón.
Cuando la ventana se llena, el sistema resume para seguir. Partir la tarea en fases hace que nunca se llegue a ese punto.
Qué te ahorra
Cortar vos cuesta escribir un entregable. Que corte solo cuesta la parte que no sabés que perdiste, que es la más cara de todas.
Y la palanca más grande no está en la lista, porque no es una técnica: es no hacer el trabajo dos veces. Un agente que reconstruye el contexto que ya tenías, que redescubre una decisión que ya se tomó o que reescribe algo que ya existía te sale mucho más caro que cualquier ventana mal repartida.