import { Steps } from '@astrojs/starlight/components';
import Figure from '@components/Figure.astro';

**Para quién:** equipos que confían en que el agente prepare una acción, pero quieren que una persona la
confirme antes de que se ejecute de verdad — por ejemplo, antes de enviar un mensaje sensible o de tocar un
dato importante.

## Qué ve el cliente final

Depende de la acción concreta que espera aprobación: si el paso envía un mensaje al cliente, este no lo
recibe hasta que alguien de tu equipo lo aprueba — no hay ningún estado intermedio visible para él. Si el
paso es puramente interno (por ejemplo, consultar un dato), el cliente no ve nada en absoluto en ningún
momento.

## Pasos en el producto

<Steps>

1. **En el editor visual de un flujo, añade un paso y márcalo «pide aprobación».** Selecciona la pieza
   **Aprobación → «Pedir aprobación»** de la paleta, o cambia el campo **Aprobación** del paso de «según
   política» a **«pide aprobación»** — este segundo camino sirve para cualquier paso, no solo para uno con
   la pieza de Aprobación. Añádele también la acción real que debe pedir permiso antes de ejecutarse (un
   mensaje al cliente, una fila en una hoja de cálculo, una herramienta de un servidor MCP…). Ver **[Trabajos
   y flujos](/guides/trabajos-flujos/)**, apartado «El editor visual».

2. **El flujo se dispara** — a mano con «Ejecutar ahora», o por su propio disparador — y llega hasta ese
   paso. En vez de ejecutar la acción directamente, la tarea pasa a estado **«Esperando aprobación»** y
   queda visible en **Trabajos**, con los botones **Aprobar** y **Rechazar** ya en la propia fila de la
   cola.

   <Figure
     src="/captures/trabajos-tarea-esperando-aprobacion.png"
     alt="Ficha de la tarea «Revisar antes de enviar» en estado Esperando aprobación, con la sección «Aprobación pendiente» mostrando el texto «Aprobación rápida: el primer operador que responda decide por el equipo» y los botones Aprobar y Rechazar"
     caption="La sección «Aprobación pendiente» explica la regla: el primer operador que responda decide por todo el equipo — no hace falta que varias personas confirmen lo mismo."
   />

3. **Cualquier operador con acceso aprueba o rechaza** — desde la propia fila de la cola, o abriendo la
   ficha de la tarea y pulsando el mismo botón ahí. No hace falta ser quien la creó ni estar asignado a
   ella.

4. **Si se aprueba, la acción se ejecuta de verdad** y la tarea pasa a **«Completada»**. Su historial
   paso a paso queda con todo lo que pasó, en orden: creada, programada, disparada, aprobación solicitada,
   aprobación resuelta (con quién la aprobó), acción ejecutada y completada — nunca tienes que fiarte a
   ciegas de lo que dice haber hecho el agente.

   <Figure
     src="/captures/trabajos-tarea-completada-aprobada.png"
     alt="Ficha de la tarea «Revisar antes de enviar» en estado Completada, con el Historial paso a paso completo: Tarea creada, Programada, Disparada, Aprobación solicitada, Aprobación resuelta («aprobada por el operador»), Acción ejecutada y Completada"
     caption="El historial completo, sin recortar: cada paso lleva su propia fecha y hora exactas."
   />

5. **Si se rechaza**, la acción no se ejecuta y la tarea queda registrada con esa decisión — el mismo
   historial paso a paso deja constancia de quién la rechazó y cuándo.

</Steps>

## Qué configurar

- **Aprobación por paso**: «según política» (usa la regla del tipo de acción — hoy, salientes a cliente
  final piden aprobación por defecto e internas se ejecutan solas) o **«pide aprobación»**, que fuerza la
  pausa en ese paso concreto sin importar la política general.
- **Una acción real detrás del paso**: la aprobación gatea una acción curada (mensaje, fila de hoja de
  cálculo, herramienta de un servidor MCP…) — un paso sin ninguna acción asociada no tiene nada que
  aprobar, así que simplemente queda a la espera de que alguien lo complete a mano.

## Límites y honestidad

- **«Aprobación rápida»** significa que el primer operador que responda decide por todo el equipo — no hay
  (todavía) un modo que exija varias confirmaciones para el mismo paso.
- Un paso sin acción curada asociada nunca llega a «Esperando aprobación»: se queda en **«Activa»**, a la
  espera de que alguien lo complete manualmente con notas de cierre — un mecanismo distinto, cubierto en
  **[Empleado digital: trabajos y flujos](/use-cases/empleado-digital-flujos/)**.
- Rechazar una tarea no la reintenta sola: si hace falta, hay que crear un paso nuevo o relanzar el flujo
  desde su ficha.

## Ver también

- **[Trabajos y flujos](/guides/trabajos-flujos/)** — el caso completo «Recordatorio y seguimiento de una
  visita», paso a paso.
- **[Empleado digital: trabajos y flujos](/use-cases/empleado-digital-flujos/)** — el caso general de
  tareas y flujos, incluida la finalización manual sin aprobación.