Aprobación humana sin cuello de botella.

En el post sobre las formas en que falla un agente, un ejecutivo de operaciones propuso un caso más: las acciones válidas e irreversibles hacia afuera, como enviar, borrar o publicar. Y preguntó lo que cualquier operación pregunta después: cómo evitar que la aprobación humana se vuelva el cuello de botella. Aquí está la respuesta completa, con el mismo agente de soporte del artículo anterior.

▲¿Cuándo se vuelve cuello de botella la aprobación humana?

Se vuelve cuello de botella cuando se decide a nivel del agente: "este agente necesita aprobación". Entonces una persona revisa cada consulta, cada borrador y cada envío, y el agente avanza al ritmo de su bandeja. La decisión correcta se toma más abajo, en cada acción que el agente puede ejecutar.

▲¿Cómo decido qué acciones necesitan a una persona?

Clasifico cada tool con dos preguntas: qué tan caro es si sale mal (impacto) y si el efecto se queda dentro del sistema o llega a un cliente (alcance). Con esas dos respuestas, cada tool cae en un nivel de autonomía.

La ventana para cancelar resuelve buena parte del caso que planteaba el comentario. Un envío es irreversible en el momento en que sale; programado a unos minutos, se puede detener. Eso lo convierte en una acción reversible durante la ventana sin que nadie tenga que aprobarlo una por una.

▲¿Dónde vive esa clasificación?

Vive en el backend, en una política declarada por tool. El prompt puede pedirle al agente que sea cuidadoso; la política es la que decide qué se ejecuta y qué espera.

// Una entrada por tool. Vive en el backend, fuera del prompt.
export const toolPolicy = {
  getOrder: { level: "auto" },
  draftReply: { level: "auto" },
  notifyCustomer: { level: "cancel_window", delayMinutes: 10 },
  closeTickets: { level: "batch" },
  proposeRefund: {
    level: "approve",
    autoBelowCents: 0, // lo ajusta el dueño del proceso
  },
} satisfies Record<ToolName, ToolPolicy>;

El umbral autoBelowCents empieza en cero: todo reembolso espera. Es la palanca que se mueve después, cuando hay evidencia. El agente no tiene forma de leer ni de cambiar esta política, igual que en el artículo anterior no podía elegir el tenant.

▲¿Cómo espera una aprobación sin detener al agente?

La aprobación es asíncrona: la acción entra a una cola con su contexto y el agente sigue con el resto del trabajo. La persona aprueba cuando le toca, y la ejecución ocurre en ese momento, del lado determinista.

export async function runTool(
  name: ToolName,
  input: unknown,
  ctx: ServerContext,
) {
  const policy = toolPolicy[name];

  if (needsApproval(policy, input)) {
    // El agente no espera: la acción queda en la cola.
    return approvals.enqueue({
      tool: name,
      input,
      tenantId: ctx.tenantId,
      reason: ctx.agentReason, // el porqué, para quien aprueba
      expiresAt: hoursFromNow(24), // si nadie decide, no se ejecuta
    });
  }

  if (policy.level === "cancel_window") {
    // Se ejecuta sola si nadie la cancela antes.
    const at = minutesFromNow(policy.delayMinutes);
    return scheduler.runAt(at, name, input, ctx);
  }

  return tools[name].execute(input, ctx);
}

Dos detalles importan. Cada aprobación llega con lo que la persona necesita para decidir en segundos: qué se va a hacer, para quién, por qué lo propuso el agente y qué cambia. Y una aprobación que vence se descarta: el sistema nunca ejecuta por omisión una acción que estaba esperando a alguien.

▲¿Cómo se gana autonomía con el tiempo?

Se gana con el historial de aprobaciones. Cada decisión queda registrada como aprobada sin cambios, corregida o rechazada, y ese registro por tool es la evidencia de cuánto se puede confiar en ella.

1. 01Empieza en el nivel más estricto que tenga sentido. Una tool nueva de impacto alto y alcance externo arranca en aprobación previa.
2. 02Mira las correcciones, no solo las aprobaciones. Una tool que se aprueba seguido pero con cambios todavía necesita a la persona; la corrección es la señal de que el agente no tiene todo el contexto.
3. 03Mueve una palanca a la vez. Subir el umbral de monto o pasar de aprobación previa a ventana para cancelar, nunca saltar directo a automático.
4. 04La decisión la toma el dueño del proceso. Con el historial a la vista, el mismo que aprobaba decide cuándo deja de hacerlo.
5. 05Bajar de nivel también es un cambio de una línea. Si las correcciones vuelven a aparecer, la tool regresa al nivel anterior sin tocar al agente.

“La autonomía de un agente se gana tool por tool, con evidencia, y se decide fuera del agente.”

▲¿Aplica lo mismo en el desarrollo de software con agentes?

Sí. En el desarrollo con agentes, la revisión humana de un PR es proporcional al riesgo: un cambio de texto en una pantalla no recibe la misma revisión que un cambio en el módulo de pagos. La clasificación por impacto y alcance es la misma, y también lo es la manera de ganar confianza.

Describo esas compuertas en qué es un harness y en el método de PeakSyn.

▲¿Por dónde empezar?

1. 01Lista las tools de tu agente. Todas, incluidas las que solo leen.
2. 02Responde impacto y alcance para cada una. Una línea por tool basta.
3. 03Escribe la política en el backend. Fuera del prompt, versionada como cualquier configuración.
4. 04Arma la cola con contexto y vencimiento. Y asigna cada tipo de aprobación a su dueño de proceso.
5. 05Registra cada decisión. Aprobada, corregida o rechazada: es lo que vas a necesitar para soltar el control.

Si quieres revisar qué acciones de tu agente deberían esperar a una persona, puedes agendar una conversación de 30 minutos.