Agentes de IA persistentes en la práctica: costos, desviación de memoria y el problema del 80%.
¿Qué salió mal después de reemplazar los prompts únicos por agentes siempre activos: facturas excesivas de tokens, solicitudes de integración superficiales, desviaciones en las especificaciones y por qué el trabajo del desarrollador pasó a centrarse en el contexto?
Fuentes: I Replaced My Prompting Habit With Persistent Agents. Here’s What Broke.
Durante aproximadamente dos años, la forma habitual de utilizar un modelo era a través de una conversación. Escribías un mensaje, leías la respuesta y luego la utilizabas o discutías sobre ella. Estabas en un ciclo constante y revisabas cada salida antes de que fuera a parar a cualquier lugar. Luego cambió el enfoque: dejaron de escribir instrucciones y comenzaron a utilizar agentes que trabajaban por sí solos, con memoria, herramientas y permiso para completar tareas sin ser vigilados en cada paso. Prueba esto durante una semana, con agentes que leen código, ejecutan comandos y abren solicitudes de integración, y la idea mantiene su validez en algunos casos. Pero en muchos otros no funciona. Los fallos aparecen en un orden bastante predecible.
Por qué la gente dejó de usar instrucciones
El abandono de los prompts refleja una limitación real. Un prompt consiste en una pregunta y una respuesta, lo cual es adecuado para búsquedas simples. Pero resulta inadecuado en situaciones donde el modelo debe recopilar información de varios lugares, razonar sobre lo que sabe, utilizar una herramienta y revisar sus conclusiones según los resultados obtenidos. Pedir todo eso de una sola vez no corresponde a cómo se lleva a cabo el trabajo real.
Lo que se necesita es un ciclo: pensar, actuar, ver el resultado y pensar de nuevo. Al añadir una memoria que persista entre sesiones se obtiene lo que la gente denomina un agente persistente. Hay una distinción importante que vale la pena aclarar desde el principio: la transcripción de una conversación no es la memoria del agente. La memoria se asemeja más a un archivo al que el agente puede leer y escribir para recordar cosas. Esa diferencia se explicará más adelante.
Por lo tanto, la decisión tiene sentido, y nadie debería fingir lo contrario. Lo importante es lo que sucede una vez que realmente la llevas a cabo, comenzando por el costo y terminando con quién sigue siendo responsable del resultado.
La factura
Lo primero que nadie menciona: cada llamada a la API comienza desde cero. El proveedor no guarda memoria de las llamadas anteriores, por lo que el programa debe reenviar toda la conversación cada vez que solicita algo. El primer paso es económico. Para el paso veinte, con los resultados de las herramientas y detalles adicionales acumulados, cada llamada puede contener miles de palabras, y debes pagar por todas ellas en cada llamada.
La aritmética se vuelve preocupante. Un análisis de treinta equipos de ingeniería reveló que un paso tardío en una tarea costaba alrededor de quince centavos. Eso parece trivial hasta que se multiplica por cincuenta pasos por tarea, docenas de tareas por desarrollador al día y todo un equipo. El resultado asciende a seis cifras mensuales, y los agentes consumen muchos más tokens que una conversación normal para realizar el mismo trabajo.
Otro riesgo es el costo descontrolado. Un bucle que sigue intentando algo que no puede tener éxito sigue generando facturas. Circula una historia sobre una empresa a la que le cobraron medio milardo de dólares precisamente por este patrón. Independientemente de si esa cifra es exacta o no, es totalmente creíble que un solo agente mal configurado gaste todo su presupuesto diario en una tarea manual de diez minutos. Lo inquietante es que todo parece estar bien mientras ocurre: el agente sigue trabajando, pero solo da vueltas en círculos.
La solución que funcionó en la práctica consta de tres partes:
- Un presupuesto diario fijo para cada agente, impuesto desde fuera del propio agente
- Una ventana de contexto dinámica, de modo que los pasos anteriores desaparezcan y no se acumulen
- Enviar el trabajo rutinario a un modelo económico y reservar solo los casos difíciles para uno más potente
Los equipos que implementaron esta instrumentación sencilla indicaron que los costos de los agentes disminuyeron en más del 50% en un mes. Un modelo más inteligente nunca fue la clave; lo que realmente funcionó fue un control estricto, y vale la pena ser directos al respecto, ya que el primer instinto cuando llega la factura es buscar un modelo mejor.
La primera solicitud de integración es una estrategia
La primera solicitud de integración de un agente puede parecer increíble: una función completa aparece en minutos y todas las pruebas pasan, lo que genera alivio. Luego surge la sospecha de que el trabajo real aún no se ha realizado, y generalmente esa sospecha es acertada.
Los equipos siguen reportando el mismo patrón: la primera solicitud de integración impresiona, pero para la quinta ya hay algún problema en producción que ninguna prueba detectó. Falto una repetición del proceso. Un caso de valor nulo no fue manejado. Una verificación de autenticación cubrió tres puntos finales y omitió el cuarto. El código funcionaba, pero no resistía la realidad.
Eso se conoce a menudo como el problema del 80%. El agente cumple con el obvio 80% y falla constantemente en abordar el 20% que incluye requisitos no funcionales, modos de fallo y consistencia arquitectónica, porque ese 20% requiere un contexto del que el agente carece. Escribe código que funciona, no código que perdura.
He aquí una versión en una sola línea de esta trampa: el código se compiló, pasó las pruebas de formato y aun así hizo lo incorrecto, porque la atención hacia él disminuyó. El resultado parece completo, así que se revisa rápidamente, como cuando se echa un vistazo al trabajo terminado de un empleado junior.
Arreglarlo más tarde cuesta más que hacerlo bien desde el principio. Las deficiencias se repiten en toda la base de código, por lo que no existe un único lugar para corregirlas.
La memoria tiene dos formas
El mayor problema fue la memoria, presente en dos formas que al principio no resultaban evidentes.
La primera es el olvido dentro de una tarea. Cuando un trabajo dura mucho tiempo, el agente pierde las decisiones que tomó al principio. La solución habitual en la industria es proporcionarle más contexto, un millón o dos millones de tokens, con la idea de que ver todo lleva a tomar buenas decisiones. Eso no funciona. Un agente frente a una gran cantidad de código complicado se confunde. Puede solucionar un problema y causar uno mayor, ya que ve muchas partes pequeñas pero no comprende el todo.
La segunda forma es más sutil y es la que causa daños reales: la deriva del contexto. El agente sigue los archivos de configuración y especificaciones. La base de código evoluciona mientras esos archivos permanecen inmutables. Pronto, un trabajador siempre activo escribe código confiadamente según un estándar que ya expiró hace meses, y nada parece incorrecto, porque sigue fielmente las instrucciones de una copia obsoleta de la realidad. Si se repite esto con varios agentes y repositorios, la brecha se amplía día tras día sin que nadie se dé cuenta.
Es allí donde la culpa deja de recaer en el modelo. La parte defectuosa no era el modelo, sino la memoria del proyecto, esa parte que permanece en el disco y sobrevive a cualquier sesión, la cual no se había construido adecuadamente.
El trabajo del desarrollador cambió
El desarrollador no disminuyó en número. El trabajo se trasladó, y el resultado es menos dramático que tanto el exceso de entusiasmo como la oposición.
La elaboración de instrucciones deja de ser tan importante una vez que el agente funciona durante mucho tiempo. Lo que realmente cuenta es el contexto: qué puede ver el agente, qué puede recordar, qué se le permite hacer y cómo incluso se puede averiguar lo que ha hecho. Los equipos que obtuvieron resultados no contaban con instrucciones ingeniosas; redactaron especificaciones, las mantuvieron actualizadas, se las proporcionaron al agente como memoria y revisaron ellos mismos la arquitectura.
El trabajo basado en especificaciones hace que el desarrollador sea más importante y cambia hacia dónde se dirige el esfuerzo: definiendo qué debe hacer la herramienta, aprobando hasta dónde puede llegar el agente y revisando la arquitectura que propone. Cuando cambian los requisitos, cambian las especificaciones, no las instrucciones. El agente elabora borradores, los implementa y los prueba según esas especificaciones, sin tener control sobre la dirección general. Esa separación fue el único método que evitó que todo fallara.
Bajo todo esto se esconde un dolor sutil pero constante. Un estudio midió el tiempo que dedicaban los desarrolladores a trabajar en bases de código reales y descubrió que eran aproximadamente un 19% más lentos, aunque sentían que trabajaban un 20% más rápido. La sensación de rapidez y la realidad de ser rápido ya no coincidían. Los agentes persistentes amplían esa brecha cuando se lo permiten, ya que son expertos en generar la ilusión de velocidad. Lo que la reduce es algo sencillo pero necesario: gobernanza, revisiones, especificaciones acordes a la realidad y un límite en los gastos.
Volver al uso exclusivo de instrucciones no es la solución, ya que el ciclo de interacción es más potente. Pero el agente no es un colega; es un contratista rápido y seguro de sí mismo que nunca admite dudas. Se mantiene a un contratista así porque es útil, y se lee todo lo que entrega, cada vez.
Lecturas relacionadas
- Uso de prompts con el modelo Astra de OpenAI: autonomía, habilidades, verificación y reglas de detención — Las antiguas costumbres al crear prompts pueden perjudicar a un modelo más reciente y autónomo. Ajuste la autonomía, la prioridad de las instrucciones, el estilo, las pruebas y las reglas de detención, con prompts listos para copiar y una lista de verificación.
- RAG experto: HyDE, compresión, autocomprobación y flujos de trabajo agente — Cuatro técnicas avanzadas de recuperación de información para RAG en producción en Haystack: HyDE, compresión contextual, autocomprobación y flujos de trabajo agente, con indicaciones sobre cuándo utilizar cada una.