Construí un sistema que descubre, verifica y aplica automáticamente requisitos relevantes de interacciones anteriores sin preguntar al usuario de dónde vinieron.

La lección central: simplemente recuperar el historial pasado no es lo mismo que saber qué sigue siendo realmente preciso. Una configuración de búsqueda básica solo capturó el 57% de los requisitos que necesitaba un agente de programación. Añadir una capa de verificación lo elevó al 100%.

De 8 tareas, la línea base acertó cero, la búsqueda básica acertó 4, y la búsqueda consciente de la intención acertó las 8. Hice todo esto con cero embeddings, cero bases de datos vectoriales y absolutamente ninguna llamada a LLM en el pipeline.

Configuré un flujo de trabajo de agente de programación que funcionó perfectamente al principio. Pero una vez que un proyecto se volvió lo suficientemente largo, empezó a causar problemas. Cuando un proyecto superaba unas pocas docenas de pasos, las reglas centrales comenzaban a desaparecer. Nadie las eliminó. La ventana de contexto no estaba llena. Esas reglas seguían técnicamente en los registros de chat. Simplemente se salieron del radar porque las nuevas solicitudes no activaban al agente para verificar si una decisión anterior seguía siendo importante.

Por ejemplo, podrías decirle al agente el primer día que nunca exponga IDs internos de base de datos en las respuestas de la API. Sesenta mensajes después, le pides que construya un nuevo flujo de autenticación. Esa nueva solicitud no dice nada sobre IDs. Como el agente carece de una razón clara para mirar atrás, omite ese paso y entrega un endpoint que filtra exactamente los datos que intentaste proteger.

Este no es un escenario inventado. Es el caso de prueba real que usé para este artículo. A continuación, te mostraré cómo tres métodos diferentes manejan este problema exacto.