Dale la misma tarea a un agente tres veces y tendrás tres implementaciones distintas. Dale una tarea larga a un solo agente y al final está resolviendo un problema ligeramente distinto del que empezaste. Ninguna de las dos cosas es un mal funcionamiento. Es la naturaleza del asunto. Los agentes derivan, como el agua encuentra la pendiente, y cualquier plan para operarlos que dé por hecho que no lo harán es un plan que falla al contacto con un run real.
El error que veo cometer, y cometí yo, es tratar la deriva como algo que eliminar. Escribe un prompt mejor, añade más reglas, sé más preciso, y seguro que esta vez se queda en el carril. No lo hará, no de forma fiable, y el esfuerzo gastado en intentar promptear la deriva hasta que desaparezca es esfuerzo no gastado en lo que de verdad funciona: construir un sistema que espera la divergencia y está diseñado para pillarla.
Qué es de verdad la deriva
La deriva es la brecha que se abre entre lo que pretendías y lo que el agente está haciendo, y se abre por razones estructurales, no arreglables siendo más amable con el modelo.
Un agente trabaja desde su contexto, y su contexto es siempre una imagen parcial y en decadencia de tu intención. Parte de la intención nunca se escribió. Parte se compactó a mitad de sesión, la misma pérdida de contexto que borra decisiones e invariantes. Parte la infirió el agente, y la infirió un poco mal. Así que el agente siempre navega guiándose por una aproximación del objetivo, y los pequeños errores de la aproximación se acumulan a lo largo de un run largo. Arregla lo que tiene delante, lo que desplaza sutilmente qué significa «el problema», y arregla lo siguiente contra el significado desplazado. Paso a paso, cada uno localmente razonable, se aleja de donde lo apuntaste.
Multiplica eso por varios agentes trabajando a la vez y la divergencia no es solo entre agente e intención, es entre los agentes mismos, cada uno derivando en su propia dirección desde un objetivo que ninguno ve del todo. Esa es la forma aguda, la que aparece como agentes contaminándose entre sí en el merge.
Por qué no se quita con un prompt
El instinto de arreglar la deriva con un prompt mejor falla por una razón simple: el prompt es una foto, y la deriva es un proceso. Puedes apuntar el agente con mucha precisión al objetivo en el instante cero. No puedes hacer que esa precisión persista a lo largo de un run largo, porque lo que la erosiona, la compactación, la inferencia, la acumulación de pequeñas decisiones locales, pasa después de entregar el prompt y sigue pasando.
Un prompt perfecto reduce el error inicial. No hace nada contra la acumulación. Es la misma razón por la que un modelo más grande no arregla el trabajo largo: el modelo puede ser más listo y aun así derivar, porque la deriva no es un problema de listura, es un problema de distancia a un objetivo que se difumina. El comportamiento previsto vive en la especificación, y la conexión del agente con esa especificación se degrada a lo largo del run. Por eso la respuesta duradera es reanclar al agente a algo que no se difumina, y lo que no se difumina es una spec que existe antes de escribir una línea y sigue legible todo el camino.
Diseñar para la divergencia
Cuando aceptas la deriva como una constante, el diseño cambia por completo. Dejas de preguntar «cómo hago que el agente no derive» y empiezas a preguntar «cómo pillo la deriva pronto y barato y la traigo de vuelta». Eso es un sistema con tres propiedades.
Reanclaje frecuente. Cuanto más va un agente sin que le recuerden el objetivo, más deriva. Así que no entregas una tarea enorme y compruebas al final. Partes el trabajo en piezas lo bastante pequeñas para que el agente no pueda vagar lejos antes de reanclarse contra el contrato. La memoria duradera y cargable es lo que hace barato el reanclaje: el objetivo está ahí, en el contexto, cada vez, en vez de ser algo que tienes que re-explicar.
Checkpoints que miden distancia a la intención, no solo corrección. Un test normal pregunta «¿esto funciona?». Un checkpoint que pilla deriva también pregunta «¿esto sigue resolviendo el problema con el que empezamos?». Son preguntas distintas. El código puede funcionar perfectamente y ser la respuesta a una pregunta que derivó lejos de la que hiciste. El checkpoint tiene que sostener los criterios originales, no la comprensión actual del agente, porque la comprensión del agente es justo lo que derivó.
Reconciliación como paso de primera clase. Cuando tienes divergencia, sea entre un agente y la intención o entre varios agentes, necesitas un momento deliberado para volver a juntarla, no la esperanza de que integre limpio. La reconciliación es donde detectas que dos cambios derivaron a conflicto y decides cuál es el correcto. En el trabajo multiagente es el merge. En el trabajo largo de un solo agente es el checkpoint donde re-puntúas contra el contrato original. En cualquier caso es un sitio del sistema, no un golpe de suerte.
El coordinador que la espera
Junta eso y tienes un coordinador cuya suposición de diseño entera es que lo que coordina va a divergir. No se fía del informe del agente de que se quedó en el carril, porque un agente que ha derivado cree que está en el carril, desde dentro de su comprensión desplazada. Re-comprueba contra un objetivo que el agente no puede mover. Pilla la divergencia en un checkpoint en vez de al final. Reconcilia a propósito en vez de integrar con esperanza.
Construir ese coordinador a propósito, en vez de improvisarlo cada sesión, es el oficio emergente del harness engineering: la disciplina que nace alrededor de cómo operas los agentes y no de cómo piensan.
Esta es la diferencia entre operar agentes y rezar para que se porten. Rezar no escala, porque cada agente añadido y cada hora añadida es otra oportunidad de derivar, y la tasa de éxito de la esperanza cae según crece la superficie. Un coordinador construido para la divergencia se vuelve más estable según añades agentes, no más tembloroso, porque pillar la deriva es un paso diseñado y no un resultado con suerte.
La razón entera de que este trabajo de coordinación sea caro es que hoy suele correr en una persona, vigilando el momento en que un agente vaga y tirando de él a mano. Esa es la versión más literal de ser el runtime: tú, en persona, como el sistema de detección de deriva. Diseñar para la divergencia es cómo sacas eso de ti, haciendo de «espera la deriva, píllala, reconcíliala» una propiedad del sistema en vez de una cosa que haces por estar vigilante. La deriva no es el enemigo. Fingir que no va a pasar sí.
¿Pillas a tus agentes derivando en un checkpoint, o cuando algo se rompe aguas abajo? Cuéntame en el foro.
Preguntas frecuentes
¿Qué es la deriva de un agente?
La deriva es la brecha que se abre entre lo que pretendías y lo que el agente está haciendo. Un agente navega guiándose por su contexto, que es siempre una imagen parcial y en decadencia de tu intención: parte nunca se escribió, parte se compactó a mitad de sesión, parte la infirió un poco mal. Arregla lo que tiene delante, lo que desplaza qué significa «el problema», y arregla lo siguiente contra el significado desplazado. Paso a paso, cada uno razonable, se aleja de donde lo apuntaste.
¿Se puede evitar la deriva con un prompt mejor?
No de forma fiable. El prompt es una foto; la deriva es un proceso. Puedes apuntar el agente con precisión al objetivo en el instante cero, pero no puedes hacer que esa precisión persista, porque lo que la erosiona —la compactación, la inferencia, la acumulación de pequeñas decisiones locales— pasa después de entregar el prompt y sigue pasando. Un prompt perfecto reduce el error inicial y no hace nada contra la acumulación a lo largo de un run largo.
¿Un modelo más grande reduce la deriva?
No por sí solo. La deriva no es un problema de listura, es un problema de distancia a un objetivo que se difumina. Un modelo más listo puede derivar igual, porque el comportamiento previsto vive en la especificación y la conexión del agente con esa especificación se degrada a lo largo del run. La respuesta duradera es reanclar el agente a algo que no se difumina: una spec que existe antes de escribir una línea y sigue legible todo el camino.
¿Cómo evito que los agentes se salgan del carril?
No previenes la deriva, la pillas pronto y barato. Parte el trabajo en trozos lo bastante pequeños para que el agente no pueda vagar lejos antes de reanclarse al contrato. Usa checkpoints que midan distancia a la intención, no solo si el código funciona. Y trata la reconciliación como un paso de primera clase donde la divergencia se trae de vuelta a propósito. Un coordinador construido así se vuelve más estable según añades agentes, no más tembloroso.