Agentes de auto-mejora: curación, aprendizaje y cambio controlado
Agentes que se mejoran por sí mismos sin riesgos: recuperación automática durante la ejecución, aprendizaje a lo largo de múltiples ejecuciones, y cambios que se implementan únicamente después de pruebas y canarios, en LangGraph.
Fuentes: Self-improving Agentic AI Applications — Feedback loop integration
Un agente al estilo ReAct planifica bien, utiliza herramientas, obtiene información y completa tareas de múltiples pasos. Los problemas surgen una vez que está en producción y alguien pregunta qué ocurre cuando comete un error. ¿Puede darse cuenta? ¿Puede recuperarse sin reiniciar todo el flujo de trabajo? ¿Puede recordar qué funcionó, aprender de las correcciones de los usuarios y, con el tiempo, mejorar su propio comportamiento?
La gente agrupa esas preguntas bajo el término “bucle de retroalimentación del agente”, pero este término es engañoso. La arquitectura que se muestra a continuación combina LangGraph con MongoDB, Gemini en Vertex AI y Arize Phoenix, y abarca la recuperación en tiempo de ejecución, el aprendizaje a partir de la experiencia, la evaluación continua y la mejora controlada.
Por qué el bucle ingenuo es peligroso
La versión simplista de un bucle de retroalimentación es breve:
Agent produces answer
↓
LLM reflects on answer
↓
Agent learns
Es atractivo porque es simple, pero también es arriesgado. Cuando un LLM evalúa su propio resultado y modifica de inmediato su comportamiento futuro, un error puede convertirse en una lección, esa lección puede convertirse en memoria, y esa memoria puede luego influir en miles de decisiones posteriores.
Un diseño más seguro se basa en un principio diferente: el agente corrige la ejecución actual, la plataforma aprende a partir de múltiples ejecuciones, y una capa de control decide qué se convertirá en el comportamiento de producción.
Un caso concreto: un agente recomienda códigos de ingreso o deducción salarial. En una ejecución elige el código incorrecto porque nunca obtuvo una política salarial específica para ese estado. El proceso de aprendizaje ingenuo sería el siguiente:
Agent made mistake
↓
Agent reflects
↓
"Always retrieve state policy"
↓
Write lesson to memory
↓
Future agents use lesson
Pueden ocurrir varios problemas con eso. El diagnóstico podría ser incorrecto. La regla podría aplicarse solo a un tipo de transacción de nómina. Un cambio posterior en la política podría hacer que la lección quede obsoleta. La entrada maliciosa de un usuario podría influir en el análisis. Además, la lección podría ser útil en algunos casos mientras perjudica a otros.
Por lo tanto, un diseño mejor trata a la lección como una hipótesis y no como una verdad.
Production failure
↓
Capture evidence
↓
Evaluate the run
↓
Identify recurring failure
↓
Generate lesson candidate
↓
Gather supporting and contradicting evidence
↓
Validate
↓
Canary test
↓
Activate
El cambio es sutil. El agente no se reescribe constantemente. La plataforma que lo rodea evalúa y evoluciona constantemente al agente.
Tres planos con diferentes niveles de autoridad
Es útil imaginar tres planos conectados.
+------------------------------------------------+
| RUNTIME PLANE |
| |
| plan -> act -> validate -> repair -> respond |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| LEARNING PLANE |
| |
| evaluate -> diagnose -> cluster -> learn |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| CONTROL PLANE |
| |
| test -> approve -> canary -> rollout -> rollback|
+------------------------------------------------+
Cada plano funciona a su propio ritmo y posee un grado diferente de autoridad. El plano de ejecución opera en milisegundos o segundos, y su única tarea es completar la solicitud actual de manera fiable. El plano de aprendizaje analiza numerosas ejecuciones distribuidas a lo largo de minutos, horas o días, y determina qué indican las pruebas acumuladas. El plano de control decide si una mejora propuesta es lo suficientemente segura como para convertirse en un comportamiento de producción. Pocas decisiones de diseño en una plataforma de agentes adaptativos son tan importantes como mantener separados a estos tres planos.
1. Autoreparación en tiempo de ejecución
Comencemos con el problema inmediato: una llamada a una herramienta falla. Una implementación simplista simplemente vuelve a intentarlo.
Tool failed
↓
Retry
↓
Retry
↓
Retry
No obstante, volver a intentarlo no constituye una solución automática. Para recuperarse es necesario saber qué falló y elegir una estrategia de recuperación adecuada. Un flujo de trabajo de LangGraph más robusto se acerca más a esto:
User Request
|
v
Clarification Gate
|
v
Retrieve Context
|
v
Plan
|
v
Proposed Action
|
v
Action Guard
|
v
Execute Tool
|
v
Sanitize Tool Result
|
v
Validate Tool Result
|
v
Reason
|
v
Validate Answer
|
+------ uncertain ------> Critic
| |
| v
| Policy Router
| / | | \
| PASS REPAIR HUMAN FAIL
| |
+---------------------------+
|
v
Response
Algunas ideas en ese gráfico merecen atención.
Validar antes de actuar
Imagínese un agente que puede realizar acciones con efectos secundarios: actualizar datos de empleados, crear una deducción salarial, enviar una transacción, modificar una cuenta o enviar una notificación. Verificar el resultado después de los hechos es demasiado tarde. La arquitectura necesita un guardián de acciones antes de cualquier cambio con consecuencias. Este guardián evalúa los permisos, las reglas de negocio, las pruebas disponibles, si la acción es reversible, el nivel de riesgo y si es necesario que una persona la apruebe. Solo entonces puede ejecutarse la herramienta.
Eso redefine la validación. La pregunta deja de ser “¿fue correcta la acción?” y se convierte en la mucho más segura “¿tenemos pruebas y autoridad suficientes para permitirlo?”
La salida de la herramienta también es poco fiable
Otro riesgo pasa desapercibido. Los agentes leen contenido de sitios web, documentos, APIs, motores de búsqueda, bases de datos y otros agentes, y ese material llega al contexto del LLM. Por lo tanto, los resultados de las herramientas constituyen otra vía para la inyección de prompts, por lo que se necesita un sanitizador de resultados de herramientas determinista entre la ejecución de la herramienta y el razonamiento.
External Tool
|
v
Tool Result
|
v
Sanitizer
|
v
Validator
|
v
LLM
Las tareas típicas de un sanitizador incluyen hacer cumplir el tipo y la longitud de la salida, rechazar estructuras mal formadas, escapar el texto que parece contener instrucciones y marcar posibles intentos de inyección. Hay una restricción estricta: no se puede utilizar ningún LLM para inspeccionar texto que pueda ser hostil.
Mantener el validador separado del crítico
Un patrón común consiste en preguntarle a un LLM “¿esta respuesta es correcta?” en cada solicitud. Esto aumenta la latencia y el costo, además de otorgarle al modelo demasiada autoridad. La validación determinística debe realizarse primero, por ejemplo:
Schema correct?
Required fields present?
Allowed value?
Business invariant satisfied?
Evidence exists?
Policy satisfied?
Known contradiction detected?
Si el software puede demostrar que una respuesta es incorrecta, no hay razón para solicitarla a otro modelo. Solo la ambigüedad semántica real llega al crítico, y aun así este no dirige el flujo de trabajo. Su función es la diagnosis, de la siguiente manera:
{
"correctness": 0.61,
"groundedness": 0.92,
"uncertainty": 0.73,
"defects": [
"missing_authoritative_evidence"
]
}
Un enrutador de políticas determinista elige entonces entre cuatro resultados:
PASS
REPAIR
HUMAN REVIEW
SAFE FAIL
La división es clara: el LLM proporciona evidencias y juicio, mientras que la política de software ostenta la autoridad.
La reparación debería cambiar la estrategia
Un intento de nuevo solo tiene valor cuando hay algo diferente. Tomemos como ejemplo a un agente que hace esto:
Search policy
↓
Generate recommendation
↓
Fail validation
Si la reparación repite la secuencia anterior con la misma consulta, las mismas pruebas y el mismo enfoque de razonamiento, eso no es recuperación. Es repetición.
Search policy
↓
Generate recommendation
Un agente robusto hace un seguimiento de algunos campos.
failure signature
strategy fingerprint
attempt ID
repair strategy
remaining budget
quality delta
Luego se aplica una regla sencilla.
same failure
+
same strategy
+
same evidence
=
do not retry
Cada vez que el mismo fallo se presenta con la misma estrategia por segunda vez, el agente debe cambiar de estrategia, transferir la tarea a una persona o fallar de manera segura. Un simple retry_count no abarca esto, por lo que la autorreparación en entornos de producción necesita presupuestos de reparación. Estos pueden limitar las llamadas a modelos de lenguaje grande, las llamadas a herramientas, el tiempo transcurrido, los costos y los intentos de reparación semántica. El objetivo no es persistir hasta que algo funcione, sino utilizar una cantidad limitada de recursos en estrategias de recuperación que realmente sean diferentes.
Verificar si la reparación funcionó
Incluso con diferentes intentos, es posible que no se logre avanzar. Supongamos que un evaluador califica el resultado inicial:
quality score = 0.54
Después de la primera reparación:
quality score = 0.55
Después del segundo:
quality score = 0.56
En teoría eso es una mejora, pero en la práctica supone un estancamiento. Una puerta delta de reparación lo evita.
delta = score_after_repair - score_before_repair
Cuando varias reparaciones solo aportan mejoras insignificantes, los recursos dejan de fluir.
small delta
+
small delta
=
human review or safe failure
Eso evita uno de los fallos más comunes en los agentes: el costoso bucle de razonamiento que parece estar activo pero en realidad no logra casi nada.
La revisión humana es una opción de enrutamiento
La revisión humana no debería considerarse un fallo. Para algunas tareas, simplemente representa la decisión final adecuada. Además, “revisión humana” abarca varios resultados diferentes.
Human
|
+-----------+-----------+
| | |
Approve Edit Reject
| | |
Continue Validate Safe Fail
Request Repair
|
v
Repair
Cada resultado continúa de manera diferente, por lo que cada uno debe aparecer explícitamente en el gráfico. El modelo de interrupción y reanudación de LangGraph se adapta bien a esto, ya que el flujo de trabajo puede marcarse como punto de control, suspenderse y luego reanudarse cuando el revisor responde.
2. Aprender de la experiencia a lo largo de las ejecuciones
La recuperación en tiempo de ejecución responde a cómo salvar esta solicitud. El aprendizaje a partir de la experiencia pregunta qué enseña esta solicitud sobre las futuras. Generalmente ocurre en segundo plano. Una vez que el agente ha respondido:
run_completed
|
v
Evaluation worker
|
v
Gather feedback
|
v
Reflection
|
v
Candidate lesson
Nadie tiene que esperar mientras un LLM reflexiona sobre lo que otro LLM podría haber aprendido. La latencia se mantiene baja, y la evaluación fuera de línea puede ser mucho más completa.
Los comentarios no son la verdad
Los indicadores llegan desde muchas direcciones: un usuario marca con pulgar hacia abajo, un experto en el tema corrige una respuesta, una API posterior rechaza una transacción, o una auditoría de cumplimiento detecta un error dos semanas después. Estos no son equivalentes. Considere el primer par de casos en los que falla la equivalencia:
thumbs up != correct
thumbs down != incorrectuser correction != authoritative rule
Por lo tanto, los comentarios deberían conservarse como evidencia en bruto y clasificarse según su fiabilidad, más o menos de la siguiente manera:
Authoritative business outcome
>
Expert human label
>
Deterministic rule
>
Calibrated evaluator
>
User feedback
>
Agent self-confidence
Eso evita que el sentimiento sea confundido con la verdad objetiva.
Algunos de los mejores comentarios llegan tarde
Los agentes suelen iniciar flujos de trabajo cuyo éxito no se puede observar de inmediato.
Agent recommends payroll code
|
v
Payroll system accepts
|
v
Two weeks later
|
v
Audit rejects transaction
La señal útil llega mucho después de que finalice la ejecución de LangGraph, lo que significa que cada decisión importante necesita un linaje causal. Se debe pasar el run_id a los sistemas posteriores para que los resultados posteriores puedan rastrearse hasta la decisión que los originó. De lo contrario, el sistema de aprendizaje sabe que algo falló, pero no puede determinar cuál decisión del agente merece el crédito o la culpa. Este es el clásico problema de asignación de créditos.
La memoria necesita gobernanza
Una vez que los agentes aprenden a lo largo de las ejecuciones, la memoria se vuelve poderosa y peligrosa al mismo tiempo. Vale la pena separar tres categorías.
- La memoria de perfiles almacena las preferencias de un usuario o entidad, como la preferencia por explicaciones concisas.
- La memoria episódica registra algo que ocurrió, por ejemplo, que la ejecución 182 falló porque no se recuperó la política de estado.
- La memoria procedural almacena una estrategia reutilizable, como resolver el estado del trabajo antes de elegir un código en la clasificación de nóminas sensible al estado.
La memoria procedural es la que más cambia de comportamiento, por lo que merece una gobernanza más estricta. Una sola ejecución fallida nunca debe generar una regla procedural de producción. El camino debería verse más o menos así:
Observation
↓
Candidate lesson
↓
Supporting evidence
+
Counterexamples
↓
Validation
↓
Active lesson
Una lección es mejor modelada como hipótesis más evidencia más alcance más confianza más ciclo de vida, y no como texto introducido en memoria vectorial.
La memoria adquirida no puede superar al conocimiento autoritativo
Los agentes recuperan dos tipos de información. El conocimiento autoritativo se refiere a políticas, regulaciones, configuraciones, datos de referencia y reglas comerciales contractuales. El conocimiento adquirido incluye preferencias, experiencias, estrategias anteriores, observaciones y lecciones aprendidas. Deben mantenerse lógicamente separados, con un orden de prioridad razonable:
Authoritative policy
>
Tenant configuration
>
Approved procedural lesson
>
Episodic example
>
User preference
>
Unverified claim
>
LLM reflection
De lo contrario, una lección recordada con confianza puede anular silenciosamente la política actual.
Las lecciones se vuelven obsoletas
Algo útil hace seis meses podría estar equivocado ahora. Las políticas, los productos, las APIs, el comportamiento de los usuarios y los modelos cambian constantemente. Las lecciones en uso requieren gestión a lo largo de su ciclo de vida.
candidate
↓
validated
↓
active
↓
pending revalidation
↓
deprecated
↓
retired
Asigne a cada lección una marca de tiempo de validación y, cuando sea apropiado, una política de vencimiento o de revalidación. Un cambio en la política puede desencadenar una reevaluación de todas las lecciones basadas en ella, de modo que la memoria se convierte en conocimiento regulado y no en un conjunto de representaciones que solo crece.
3. El plano de aprendizaje sin conexión
La capa siguiente agrega evidencias provenientes de numerosas ejecuciones en producción.
Runs
+
User Feedback
+
Human Reviews
+
Downstream Outcomes
+
Evaluation Scores
|
v
Failure Classification
|
v
Failure Clustering
Dice que una semana de carreras revela esta distribución:
missing state policy 178
wrong tool selected 63
bad tool argument 52
unsupported inference 41
output schema failure 11
Ahora la plataforma puede identificar qué problemas son sistémicos. Eso es diferente a pedirle a un agente que ha fallado que reflexione sobre una única ejecución fallida. El sistema de aprendizaje detecta patrones.
No todo fallo se debe a un problema en los prompts
La ingeniería de prompts no siempre es la solución. Si un agente sigue olvidándose de obtener una política autoritativa antes de recomendar algo, añadir una línea al prompt del sistema pidiéndole que la recuerde podría ayudar. Una solución más efectiva podría ser una regla estructural:
Graph rule:
Policy retrieval must occur before this decision.
Otras fallas recurrentes podrían requerir cambios en estas áreas:
retrieval
tool schema
validator rule
routing
memory policy
clarification logic
action guard
model configuration
Un motor de mejoras avanzado propone varios posibles arreglos y no reescribe automáticamente la instrucción.
La evaluación está en el centro
Si un sistema puede generar mejoras pero no puede determinar si son mejores, no existe un ciclo de aprendizaje, solo un ciclo de mutación. La evaluación es el pilar de esta arquitectura.
Correctness
Groundedness
Retrieval relevance
Completeness
Tool selection
Tool arguments
Trajectory efficiency
Repair effectiveness
Safety
Latency
Cost
Business outcome
La evaluación debe abarcar la respuesta final y también el camino seguido para llegar a ella. Dos agentes pueden producir la misma respuesta. El Agente A lo hace de la siguiente manera:
Agent A
search -> answer
Mientras el Agente B hace esto:
Agent B
search
-> wrong tool
-> retry
-> timeout
-> second search
-> repair
-> answer
Si se juzga únicamente por la respuesta final, son equivalentes. Sin embargo, la evaluación de la trayectoria demuestra claramente que no lo son.
Un solo evaluador basado en LLM no es suficiente
Es útil que Gemini escriba una respuesta y otro modelo Gemini la evalúe, pero existe el riesgo de error correlacionado, ya que el evaluador podría compartir los puntos ciegos del generador. Una capa de evaluación más sólida combina varias fuentes.
Deterministic checks
+
Business outcomes
+
Human labels
+
Multiple evaluator rubrics
+
LLM judges
Los evaluadores de LLM también deben compararse periódicamente con ejemplos etiquetados por humanos. Eso permite determinar hasta qué punto se puede confiar en el evaluador antes de que sus puntuaciones influyan en qué lecciones se promocionan.
La observabilidad forma parte del aprendizaje
El monitoreo tradicional se centra en averiguar si el servicio está activo. La observabilidad de los agentes debe preguntarse también por qué tomaron una decisión determinada. Una buena configuración de producción registra un seguimiento completo de toda la ejecución de LangGraph.
Agent Run
|
+-- Retrieve Context
|
+-- Planner
|
+-- Tool Call
|
+-- Tool Result Validator
|
+-- Repair
|
+-- Critic
|
+-- Final Answer
Cada ejecución también debe tener una identidad estable que vincule varios registros.
LangGraph execution
MongoDB events
Vertex AI calls
Evaluation results
Human feedback
Downstream outcomes
Esa correlación es la materia prima del bucle. La observabilidad deja de ser solo una herramienta de depuración y se convierte en parte del sistema de aprendizaje.
Por qué los eventos de solo anexión son útiles
Es tentador cargar toda la trayectoria de ejecución en un único documento de ejecución de MongoDB. Funciona al principio, pero se vuelve problemático a gran escala. Es mejor mantener la ejecución compacta.
run_id
agent
release
outcome
latency
tool count
repair count
cost
Luego, registre la ejecución como eventos de solo anexión.
run.started
retrieval.completed
tool.called
validation.failed
repair.started
human_review.requested
run.completed
Eso mantiene el orden causal, evita que los documentos crezcan excesivamente, simplifica el rastreo distribuido y hace que el análisis de fallos sea más preciso.
La reproducibilidad requiere algo más que una versión de prompt
El comportamiento de un agente depende de más factores que su prompt del sistema.
model
generation settings
graph version
tool definitions
validator rules
critic rubric
retrieval configuration
memory rules
security rules
Cada serie de producción debería, por lo tanto, utilizar una versión del agente inmutable. Conceptualmente:
agent_release_43
|
+-- graph v12
+-- prompt v43
+-- Gemini configuration
+-- tools v17
+-- validator v11
+-- retrieval config v9
+-- memory policy v5
+-- evaluation suite v8
Una ejecución fallida puede reproducirse más tarde. Sin esto, la depuración se reduce a preguntar qué versión generó una respuesta, seguida de silencio.
El plano de control: las mejoras permiten el acceso a producción
Con el tiempo, el sistema de aprendizaje detecta un fallo recurrente y elabora una mejora. La peor respuesta es implementarla de inmediato. En su lugar, pásela por los procesos de verificación:
Candidate Improvement
|
v
Historical Replay
|
v
Regression Evaluation
|
v
Shadow Production
|
v
Canary
|
v
Progressive Rollout
|
v
Production
En cada etapa, compare al candidato con la versión actual. Esto podría mejorar la corrección y perjudicar la latencia, reducir las alucinaciones y aumentar la necesidad de intervención humana, o ayudar en un tipo de tarea mientras perjudica a otro. Por lo tanto, la promoción requiere varias medidas de control.
Las lecciones también necesitan canarios
La memoria a largo plazo tiene una consecuencia interesante. Cuando se activa una nueva lección procedural e se introduce en el contexto de los agentes futuros, su comportamiento cambia; así que introducir una lección equivale en efecto a cambiar un prompt. La activación debe tratarse como un experimento, y no aplicarse de inmediato en todas las ejecuciones que cumplan los requisitos.
Historical replay
↓
5% canary
↓
Measure outcome
↓
25%
↓
Measure
↓
100%
Si la lección empeora el rendimiento, reviértala. La memoria deja de ser un mecanismo adaptativo misterioso y se convierte en una versión del software medible.
La arquitectura final
En conjunto, la plataforma de agentes adaptativos se ve más o menos así:
USER
|
v
+------------------------------------------------------+
| RUNTIME |
| |
| clarify -> retrieve -> plan -> action guard |
| | |
| v |
| tool |
| | |
| sanitize |
| | |
| validate |
| | |
| reason |
| | |
| answer validate |
| | |
| critic if needed |
| | |
| policy router |
| / | \ |
| repair human pass |
+--------------------------+---------------------------+
|
agent events
|
v
+------------------------------------------------------+
| LEARNING |
| |
| traces + feedback + outcomes |
| | |
| v |
| evaluate |
| | |
| classify failures |
| | |
| cluster |
| / \ |
| lessons improvement candidates |
+--------+----------------------+----------------------+
| |
v v
+------------------------------------------------------+
| CONTROL |
| |
| validate -> replay -> shadow -> canary -> rollout |
| | |
| monitor |
| | |
| rollback |
+------------------------------------------------------+
Los límites de responsabilidad están diseñados de forma deliberadamente clara. El agente en tiempo de ejecución corrige el proceso de ejecución. El sistema de aprendizaje genera hipótesis. La capa de control decide qué comportamiento se considerará fiable.
Reconsiderando el concepto de “auto-mejora”
Al escuchar “agente auto-mejorador”, muchas personas imaginan una IA que reescribe su propio prompt de sistema o se actualiza después de cada conversación. Para los sistemas en producción, ese es el modelo mental incorrecto. Uno mejor es un ciclo:
Observe
↓
Measure
↓
Diagnose
↓
Propose
↓
Test
↓
Promote
↓
Monitor
La inteligencia aquí no se limita al LLM. Diferentes partes del sistema la gestionan:
- El grafo de LangGraph determina el orden de ejecución.
- Los validadores de código simple aplican las reglas ya conocidas.
- El LLM se ocupa de lo que sea ambiguo.
- MongoDB almacena el estado y la experiencia acumulada.
- El seguimiento recopila las pruebas.
- Los evaluadores califican la calidad.
- Las personas toman la decisión cuando el riesgo es alto y la respuesta no está clara.
- El plano de control regula cualquier cambio en el comportamiento.
Esa distribución convierte a un agente en un sistema de agentes adaptativos.
Un orden de construcción sensato
Nadie necesita construir todo el ciclo de una sola vez. Una secuencia viable comienza con una ejecución fiable y un registro en cada ejecución. Además, se incluyen mecanismos de control de acciones, validación de resultados y respuestas, reparaciones limitadas y revisión humana. A continuación viene la medición de la calidad: registros, evaluación y clasificación de fallos, y un conjunto de datos de regresión útil. La experiencia adquirida solo entra en juego cuando se puede medir la calidad con confianza, lo que implica la identificación de lecciones aprendidas, gestión de memoria específica, agregación de evidencias, controles de obsolescencia y retroalimentación diferida. La mejora controlada es la etapa final, que incluye el agrupamiento de fallos, generación de candidatos, evaluación por reproducción, tráfico de prueba y despliegue gradual.
El orden es importante:
Reliability
↓
Observability
↓
Evaluation
↓
Learning
↓
Controlled adaptation
Intentar pasar directamente a un sistema de “aprendizaje autónomo” antes de realizar evaluaciones suele dar como resultado un sistema que cambia más rápido de lo que los ingenieros pueden seguirle el ritmo.
El objetivo
Nadie debería buscar un agente que se edite por sí mismo. Un objetivo mejor es contar con una plataforma capaz de demostrar cuándo un agente debe cambiar. Recordar conversaciones anteriores no es suficiente para que un ciclo merezca confianza; se necesita una cadena disciplinada entre estas etapas:
production behavior
↓
evidence
↓
evaluation
↓
learning
↓
experimentation
↓
controlled production change
Esa cadena es la base sobre la que se sustenta un sistema de agentes adaptativos basado en evidencias, y es la arquitectura que necesita la IA agentes para pasar de demostraciones efectistas a software de producción fiable.