Saltearse al contenido

Skill de Atendium Workflows

La skill Atendium Workflows enseña al asistente a trabajar con el runtime conversacional real de Atendium: nodos, conexiones, ramas, facts, blackboard, pausas entre turnos, integraciones y acciones humanas.

Descargar Atendium Workflows .zip

Cuándo usarla

  • Crear o modificar un workflow de un agente.
  • Clasificar intención desde el primer mensaje.
  • Diferenciar WhatsApp, web u otros canales.
  • Aplicar días y horarios de atención.
  • Capturar datos durante varios turnos.
  • Consultar Nexus, Google Sheets o una API.
  • Pedir aprobación antes de una acción sensible.
  • Transferir una conversación a una persona.
  • Revisar, endurecer, simular o explicar un workflow existente.

Invocación

$atendium-workflows <comando> <objetivo o archivo>

También puede activarse al pedir naturalmente un workflow de Atendium. El comando explícito permite controlar exactamente el tipo de trabajo.

Comandos

ComandoPara qué sirve
shapeIndaga mediante choices y diseña la arquitectura sin generar JSON.
buildGenera el workflow en draft, escenarios mock y reporte validado.
editModifica un workflow preservando lo que queda fuera del pedido.
critiqueRevisa experiencia conversacional, claridad, ruteo y elección de nodos sin editar.
auditBusca errores técnicos, secretos, conexiones, handles, ciclos y ramas faltantes.
simulateRecorre escenarios mock sin credenciales ni efectos reales.
validateValida, corrige y repite hasta aprobar o encontrar un bloqueo concreto.
hardenAgrega fallbacks, expiraciones, idempotencia y participación humana.
optimizeReduce nodos, llamadas LLM y consultas externas innecesarias.
explainDescribe el recorrido turno por turno y rama por rama.

Ejemplos

$atendium-workflows shape atención para ventas, soporte y administración
$atendium-workflows build capturar un prospecto de WhatsApp y crear un deal en Nexus
$atendium-workflows critique workflow.json
$atendium-workflows harden workflow.json
$atendium-workflows simulate workflow.json

Descubrimiento guiado

Cuando faltan decisiones importantes, la skill no obliga al usuario a conocer nodos. Hace de una a tres preguntas por tanda:

¿El tratamiento cambia según el canal?

A. Todos los canales siguen la misma lógica.
B. Cada canal tiene rutas o respuestas diferentes.
C. Sólo WhatsApp tiene tratamiento especial.
D. Otro — describilo con tus palabras.

Se puede responder de manera compacta: 1B, 2A, 3D: fuera de horario sólo tomar datos.

La entrevista puede descubrir decisiones sobre intención, canal, origen proactivo, horarios, identidad, fuente de verdad, captura, riesgo, respuesta y continuidad.

Diseño centrado en conversaciones

La skill trata todo workflow como una conversación multivuelta, no como un flujo lineal. En cualquier punto el usuario puede:

  • responder sólo una parte de lo pedido;
  • corregir un dato anterior;
  • cambiar de tema o interrumpir con una pregunta;
  • pedir volver atrás, cancelar o reiniciar;
  • solicitar una persona.

Por eso cada espera define cómo continuar, qué facts conservar, cuáles invalidar y desde qué nodo reanudar. Un cambio temporal puede responder la nueva consulta y volver al proceso pendiente; un cambio permanente puede abandonar la rama anterior y limpiar únicamente sus datos.

Los retornos no se dibujan como ciclos. El workflow mantiene un DAG válido y vuelve lógicamente mediante estado persistido, nextStartNodeId o ruteo de reentrada. Así puede regresar a una captura anterior sin repetir identidad, saludo ni información todavía válida.

La corrección automática genérica depende del runtime. Actualmente existen retornos especializados para ciertas capturas de fecha y profesional; otros retrocesos deben diseñarse como ramas explícitas o acompañarse de una extensión del runtime.

Criterios de construcción

  • Texto exacto usa mensaje fijo; razonamiento abierto usa agente.
  • Datos tipados y multivuelta usan captura estructurada.
  • Canal, horario, texto e intención utilizan el router específico.
  • Las operaciones de Nexus usan el nodo nativo antes que HTTP manual.
  • Una aprobación puntual y una transferencia humana no son lo mismo.
  • Las credenciales nunca se escriben dentro del workflow.
  • Todas las ramas importantes incluyen fallback, error o salida terminal.

Validación funcional con mocks

La skill incluye un simulador offline. El asistente genera un archivo de escenarios que indica qué salida debe tomar cada nodo y qué camino o efecto se espera.

Ventana de terminal
python3 scripts/validate_and_simulate.py workflow.json \
--scenarios scenarios.json \
--report report.json

La simulación puede comprobar:

  • datos completos e incompletos;
  • éxito y error de Nexus, Sheets o HTTP;
  • aprobación, rechazo y vencimiento;
  • fallback de intención;
  • diferencias por canal y horario;
  • corrección de datos y limpieza de facts dependientes;
  • cambio de intención y retorno al proceso pendiente;
  • preservación de identidad y otros facts transversales entre turnos;
  • nodo terminal o handoff esperado.

Los efectos aparecen como mocked: true: no se envían mensajes ni se modifican sistemas externos.

Resultado de build

Una construcción completa entrega:

  1. Resumen de entrada, rutas, identidad y acciones.
  2. Workflow o plan semántico en draft.
  3. IDs y credenciales pendientes claramente señalados.
  4. Escenarios mock.
  5. Reporte de validación.
  6. Límites de lo que todavía requiere prueba real.

Continuidad comercial opcional

Cuando una rama produce una demo, cotización, lead o deal que necesita seguimiento posterior, la skill puede sugerir Nexus después de entregar el workflow. La recomendación identifica el nodo y la rama determinística de origen, evita duplicar mutaciones ya realizadas y ofrece un prompt listo para $nexus-sales-automations.

La sugerencia es opcional y no bloquea el workflow. La skill no ejecuta Nexus automáticamente y no inventa pipeline, etapa, owner, SLA ni cadencia. Si el caso es sólo informativo o no requiere seguimiento, no muestra la recomendación.

Límites

Los mocks no verifican credenciales, permisos, entrega efectiva de mensajes, existencia de recursos ni respuestas reales de modelos o APIs. Activar o ejecutar efectos reales requiere autorización y una prueba controlada posterior.

Lecturas relacionadas