Post-Actions

Las post-actions son callbacks HTTP reutilizables que se ejecutan automaticamente al completarse una ejecucion de webhook o tarea programada. Permiten notificar a sistemas externos (Slack, PagerDuty, APIs propias) sobre los resultados sin escribir codigo de integracion.

Casos de Uso

Notificaciones a Slack: Enviar un mensaje a un canal cuando una tarea programada termina o falla.
Gestion de incidentes: Crear un incidente en PagerDuty u Opsgenie cuando falla la ejecucion de un agente.
Webhooks a sistemas externos: Reenviar resultados de ejecucion a tu propia API para logging, metricas o procesamiento adicional.
Dashboards de estado: Enviar resultados a una pagina de estado o herramienta de monitoreo.

Como Funcionan

Crear una post-action: Define una plantilla de peticion HTTP reutilizable (metodo, URL, cabeceras, cuerpo, autenticacion).
Vincularla: Conecta la post-action a uno o mas webhooks o tareas programadas mediante bindings. Cada binding especifica cuando dispararse: en exito, fallo, o cualquier resultado.
Ejecucion automatica: Cuando un webhook o tarea programada termina, todos los bindings coincidentes se evaluan y sus post-actions se ejecutan en paralelo.
Fire-and-forget: Las post-actions nunca bloquean al webhook o tarea programada. Se ejecutan de forma asincrona en segundo plano.

Conceptos Clave

Post-Action

Una post-action es una definicion de peticion HTTP reutilizable que incluye:

Metodo: GET, POST, PUT, PATCH o DELETE.
URL: El endpoint a llamar. Soporta variables de plantilla.
Cabeceras: Cabeceras HTTP personalizadas (ej. Content-Type: application/json).
Plantilla de cuerpo: El cuerpo de la peticion con variables que se reemplazan en tiempo de ejecucion.
Autenticacion: Auth opcional (Bearer token, Basic auth o cabecera personalizada).
Timeout: Tiempo maximo por peticion (1-300 segundos, por defecto 30).
Reintentos: Numero de reintentos en caso de fallo (0-5, por defecto 0).

Binding

Un binding conecta una post-action con un webhook o tarea programada especifica. Especifica:

Tipo de trigger: webhook o schedule.
Trigger: Que webhook o tarea programada especifica monitorear.
Disparar cuando: any (siempre), success (solo en exito) o failure (solo en fallo/timeout).
Override de cuerpo: Opcionalmente sobreescribir la plantilla de cuerpo por defecto para este binding especifico.
Habilitado: Activar o desactivar el binding sin eliminarlo.

Una misma post-action puede tener multiples bindings, permitiendo reutilizar la misma plantilla de notificacion en diferentes webhooks y tareas programadas.

Historial de Ejecuciones

Cada ejecucion de post-action queda registrada. Para cada ejecucion puedes ver:

Estado: success o failed.
Codigo HTTP: El codigo de respuesta del servidor destino.
Peticion enviada: El metodo y URL que se llamo.
Cuerpo de respuesta: Los primeros 4KB de la respuesta.
Error: Detalles del error si la peticion fallo.
Duracion: Cuanto tardo la peticion.

Variables de Plantilla

Usa placeholders con doble llave en la URL, plantilla de cuerpo o valores de cabecera. Se reemplazan con valores reales en tiempo de ejecucion:

Variable	Descripcion
`{{status}}`	Resultado: `success` o `failed`
`{{trigger_type}}`	Tipo de origen: `webhook` o `schedule`
`{{trigger_name}}`	Nombre del webhook o tarea programada que genero la ejecucion
`{{team_name}}`	Nombre del equipo de agentes
`{{run_id}}`	Identificador unico de la ejecucion origen
`{{response}}`	Respuesta del agente (escapada en JSON dentro de plantillas JSON)
`{{error}}`	Mensaje de error si la ejecucion fallo (vacio en caso de exito)
`{{prompt}}`	El prompt que se envio al agente
`{{started_at}}`	Timestamp de inicio de la ejecucion
`{{finished_at}}`	Timestamp de fin de la ejecucion

 
Cuando la plantilla parece JSON (comienza con { o [),
      los valores de las variables se escapan automaticamente para evitar payloads rotos.
 Ejemplo: Notificacion a Slack
 
Para enviar un mensaje a Slack cuando una tarea programada completa:
  
Crea una post-action con:
 Metodo: POST
 URL: Tu URL de incoming webhook de Slack
 Cabecera: Content-Type: application/json
  Plantilla de cuerpo: {
  "text": "{{trigger_type}} '{{trigger_name}}' finalizo: {{status}}\nEquipo: {{team_name}}\nRun: {{run_id}}\nError: {{error}}"
}
 
 
 
 Crea un binding a tu tarea programada con Disparar cuando: any.
 La proxima vez que la tarea se ejecute, recibiras un mensaje en Slack con el resultado.
 
 Autenticacion
 
Las post-actions soportan cuatro modos de autenticacion:
    Modo  Descripcion  
 
  Ninguno Sin autenticacion. Adecuado para servicios que usan auth basada en URL (ej. webhooks de Slack).
 Bearer Agrega una cabecera Authorization: Bearer <token>.
 Basic Agrega autenticacion HTTP Basic con usuario y contrasena.
 Cabecera personalizada Agrega una cabecera personalizada con nombre y valor (ej. X-API-Key).
 
 
 
Las credenciales de autenticacion se cifran en reposo usando AES-256-GCM.
 Comportamiento de Reintentos
 
Cuando una post-action falla (error de red o respuesta HTTP 5xx), se reintenta
      con backoff exponencial:
  1er reintento tras 1 segundo
 2do reintento tras 2 segundos
 3er reintento tras 4 segundos
 Hasta un maximo de 5 reintentos, con tope de 30 segundos entre intentos
 
 
Las respuestas HTTP 4xx no se reintentan (indican un error
      del cliente que no se resolvera reintentando).
 Gestion de Post-Actions
 Desde la Pagina de Post-Actions
 
Navega a Post-Actions en la barra lateral para ver todas las
      post-actions definidas. Desde ahi puedes crear, editar, habilitar/deshabilitar
      o eliminar post-actions y ver su historial de ejecuciones.
 Desde las Paginas de Detalle de Webhook/Tarea Programada
 
Cada pagina de detalle de webhook y tarea programada tiene una seccion de
Post-Action Bindings donde puedes agregar, editar o eliminar
      bindings directamente. Esto te permite gestionar que post-actions se disparan
      para un trigger especifico sin salir de la pagina.
 Notas de Arquitectura
  Las post-actions son fire-and-forget: nunca bloquean ni retrasan la respuesta del webhook/tarea programada.
 Multiples bindings para el mismo trigger se ejecutan en paralelo.
 Las post-actions no estan vinculadas a equipos: son una funcionalidad a nivel de plataforma.
 No hay restricciones SSRF: las post-actions pueden alcanzar IPs privadas y servicios internos. Esto es por diseno, ya que AgentCrew se despliega tipicamente detras de una VPN o en una red privada.
 
 Siguientes Pasos
  Webhooks: Aprende sobre los triggers de webhook que pueden disparar post-actions.
 Tareas Programadas: Aprende sobre las tareas programadas que pueden disparar post-actions.
 Configuracion: Revisa todas las variables de entorno.

Modo	Descripcion
Ninguno	Sin autenticacion. Adecuado para servicios que usan auth basada en URL (ej. webhooks de Slack).
Bearer	Agrega una cabecera `Authorization: Bearer <token>`.
Basic	Agrega autenticacion HTTP Basic con usuario y contrasena.
Cabecera personalizada	Agrega una cabecera personalizada con nombre y valor (ej. `X-API-Key`).