Patrón Self-Critique Agent: borrador → crítica → revisión

Esencia Del Patrón

Self-Critique Agent es un patrón en el que el agente primero escribe un borrador, luego registra riesgos y cambios obligatorios con una plantilla fija, hace una revisión controlada y guarda exactamente qué cambió en el registro.

Cuándo usarlo: cuando necesitas revisión de riesgos estricta y estructurada, con una revisión controlada y trazabilidad de auditoría.

A diferencia de reflection ligero, self-critique suele ser más estricto:

• la crítica tiene formato fijo (por ejemplo, JSON)
• solo se permiten cambios con reglas
• se controla el crecimiento del texto
• el sistema guarda un registro de cambios (antes → después)

Problema

Imagina que un agente prepara una actualización para un cliente sobre un incidente.

Borrador:

"El release está retrasado por una falla en el módulo de pagos."

Luego llega una petición:

"Haz el tono más suave."

Sin un marco de self-critique, el agente suele hacer una "reescritura bonita" que se sale de la tarea:

• agrega suposiciones nuevas
• hace el tono menos específico
• expande el texto fuera del alcance necesario
• oculta el problema en lugar de aclararlo

"Mejorar redacción" no debe convertirse en "cambiar el significado".

Como resultado:

• el sentido cambia sin que se note
• no queda claro qué se corrigió exactamente
• auditoría no puede reconstruir la lógica de cambios
• la respuesta se vuelve menos confiable para decidir

Ese es el problema central: durante la "mejora", el agente puede cambiar el contenido aunque solo debía cambiar la forma.

Solución

Self-Critique introduce una regla: solo se puede editar lo que esté en "required changes".

Analogía: es como edición editorial con una lista de observaciones. Primero fijamos exactamente qué hay que corregir, luego aplicamos una sola revisión controlada. Así la respuesta queda más clara sin cambiar el significado.

Principio clave: primero crítica estructurada, luego una sola revisión controlada con rastro de auditoría.

El agente puede proponer reescrituras, pero el sistema permite solo cambios puntuales que estén explícitamente en "required changes".

Flujo controlado:

1. Borrador: generar la primera versión
2. Crítica: generar un artefacto (risks + required_changes)
3. Decisión: ok/revisar/escalar
4. Revisión: ejecutar una sola revisión acotada
5. Auditoría: registrar diff + metadata

Esto te da:

• mayor claridad sin cambiar hechos
• separación nítida entre "qué está mal" y "qué se corrigió"
• revisiones reproducibles
• control de salidas high-risk antes de publicar

Funciona bien si:

• critique tiene estructura fija (schema-driven)
• revision está limitada a required_changes
• se aplica no_new_facts
• el audit diff es obligatorio

Cómo Funciona

Para que este patrón sea seguro, necesitas límites claros:

• una pasada de crítica
• una pasada de revisión
• no agregar hechos nuevos
• editar solo lo que está en required changes
• no inflar el texto (por ejemplo, +20% máximo)
• con riesgo alto: parar o pedir revisión humana

En Código Se Ve Así

draft = writer.generate(goal, context)

critique = critic.review_once(
    draft=draft,
    schema="risks_required_changes_v1",
)

if critique.high_risk:
    return escalate_to_human(critique.reason)

if critique.ok:
    return draft

revised = writer.revise_once(
    draft=draft,
    required_changes=critique.required_changes,
    rules=[
        "no_new_facts",
        "max_length_increase_pct=20",
        "keep_scope",
    ],
)

approved = supervisor.review_output_patch(
    original=draft,
    revised=revised,
    allowed_changes=critique.required_changes,
)

audit.log_diff(
    before=draft,
    after=approved,
    risks=critique.risks,
)

return approved

Self-Critique no debe ejecutarse "hasta que quede perfecto". Una crítica + una revisión (revise) y validación de que revision no salió de required_changes.

Cómo Se Ve En Ejecución

Goal: proponer un plan de acción seguro durante un incidente de red

Draft:
"El problema fue causado por la red. Debemos reiniciar todo el clúster."

Critique:
- risk: afirmación de causa sin evidencia
- risk: acción con blast radius demasiado amplio (cambios de estado)
- required_change: añadir verificaciones antes del restart

Revision:
"Una causa probable es una falla de red.
Antes de reiniciar el clúster, verificar estado de nodos y latencia.
Si se confirma una caída parcial, reiniciar solo los nodos afectados."

Cuándo Encaja - Y Cuándo No

Encaja

No Encaja

Porque self-critique añade un segundo paso de generación y eleva el costo de ejecución.

Diferencia Frente A Reflection

Reflection se usa más como filtro ligero antes de enviar. Self-Critique es para control más estricto de cambios.

Cuándo Usar Self-Critique (vs Otros Patrones)

Usa Self-Critique cuando necesitas crítica profunda con criterios explícitos y reescritura controlada.

Prueba rápida:

• si necesitas "evaluar por checklist y reescribir respuesta" -> Self-Critique
• si necesitas "solo un chequeo corto antes de enviar" -> Reflection Agent

Cómo Combinarlo Con Otros Patrones

• Self-Critique + RAG: crítica y revisiones permitidas solo dentro de hechos del contexto de retrieval.
• Self-Critique + Supervisor: cambios riesgosos no se aplican automáticamente y se envían a aprobación humana.
• Self-Critique + Reflection: Reflection hace pre-check rápido y Self-Critique se activa para respuestas complejas o discutibles.

Resumen

Ventajas Y Desventajas

FAQ

Q: ¿Se pueden hacer varias pasadas de crítica?
A: Técnicamente sí, pero se convierte rápido en un ciclo caro. Estándar base seguro: 1 + 1.

Q: ¿Por qué es obligatorio registrar cambios?
A: Sin diff es difícil entender qué cambió la calidad de la respuesta y dónde apareció el error.

Q: ¿Hace falta un modelo crítico separado?
A: A veces sí, pero no es obligatorio. Es más importante tener esquema estricto, validación de salida y reglas duras de revisión.

Qué Sigue

Self-Critique mejora la calidad mediante reescritura controlada.

Pero ¿qué hacer cuando la respuesta no solo debe reescribirse, sino validarse por policy antes de una acción riesgosa?