Platform

Flows

Un flujo es un grafo de uno o mas nodos conectados. Cada nodo ejecuta una tarea y pasa el resultado al siguiente. Define qué pasa cuando un usuario escribe un mensaje, cuando llega un webhook o cuando se cumple un horario.

• Grafo dirigido: Los nodos se conectan con flechas que indican el orden de ejecucion.
• Nodos: Cada nodo es un paso del proceso (un LLM, una consulta a una API o una decision).
• Conexiones: Las conexiones entre nodos definen como fluye la informacion.
• Trigger: El evento que inicia el flujo (mensaje, webhook, schedule, etc).

El flujo mínimo es un trigger y un solo nodo. Por ejemplo: un usuario escribe por WhatsApp → un agente IA responde. No necesitas más para tener un agente funcionando.

Uso de los Nodos

Los nodos son los bloques de construcción de un flujo. Cada uno cumple una función específica: algunos conversan con el usuario y razonan sobre su intención, otros conectan con APIs y bases de datos, algunos ramifican el flujo según condiciones, y otros procesan datos y contenido. Combinando diferentes tipos de nodos puedes construir desde flujos simples hasta sistemas complejos de atención al cliente con lógica, inteligencia y conexiones a sistemas externos.

Para la referencia completa de cada nodo, visita la seccion de Nodos.

Disparadores: como arranca un flujo

Un disparador es el evento que inicia un flujo. Puede ser un mensaje de WhatsApp, un webhook HTTP, un evento programado (cron) o un clic manual en el builder. Cada flujo se conecta a uno o más disparadores y solo se ejecuta cuando ese evento ocurre.

Ver Triggers para la referencia completa.

Ejecucion de principio a fin

Asi se ejecuta un flujo cuando llega un evento:

1. El trigger recibe el evento — El sistema valida que el evento es autentico y esta bien formado.
2. Se identifica el flujo activo — Segun el canal por donde llego el evento, se selecciona el flujo configurado para responder.
3. Se prepara el contexto de ejecucion — Se carga la memoria, el historial y el estado de la conversacion.
4. Los nodos se ejecutan en orden — Cada nodo procesa su tarea y pasa el resultado al siguiente. Los nodos independientes pueden correr en paralelo.
5. Las decisiones ramifican el flujo — Los nodos de condicion evaluan el contexto y eligen que rama seguir.
6. La respuesta llega al usuario — El resultado se envia por el canal correspondiente (WhatsApp, widget, etc) y la ejecucion queda registrada.

Pausa y reanudacion

Un flujo puede pausarse y continuar despues. Esto es util para:

• Esperar respuesta del usuario: El flujo se pausa hasta que el usuario envie otro mensaje.
• Esperar un evento externo: Como la confirmacion de un pago o la llegada de un webhook.
• Programar continuacion: Usando wait_until, el flujo puede pausarse hasta una fecha especifica.

Cuando el flujo se pausa, el estado se conserva de forma segura. Cuando llega el evento esperado, el motor retoma la ejecucion desde donde se quedo.

Memoria de ejecución y eventos

Cada flujo tiene un estado compartido que se actualiza en cada nodo. No confundir con la Base de Conocimiento — la memoria de ejecución guarda el estado de la conversación, mientras que la Base de Conocimiento son los documentos que el agente consulta.

// El estado compartido a lo largo de un flujo
interface ExecutionMemory {
  facts: Record<string, any>      // datos extraidos (clave-valor)
  messages: Message[]             // historial de la conversacion
  variables: Record<string, any>  // estado local
  state: Record<string, any>      // estado persistente entre nodos
}

• Facts: Datos que los nodos extraen del contexto (nombre del usuario, intencion, etc).
• Variables: Estado local que se puede usar en condicionales o para personalizar respuestas.

Saber más sobre Memoria →

Publicar y conectar flujos

Publicar flujo

Publicar un flujo es cambiar su estado de draft a active. Solo los flujos activos responden a mensajes reales. Puedes hacerlo desde el editor o via API.

Los flujos pueden estar en cuatro estados:

• Draft: En construccion. No se ejecuta con eventos reales.
• Active: Publicado y ejecutandose. Responde a los triggers configurados.
• Paused: Pausado manualmente. No responde pero conserva el estado para reanudar.
• Archived: Desactivado. No se ejecuta pero se conserva el historial.

Vincular un flujo a un canal

Un canal es por donde llegan los mensajes: WhatsApp, widget web, Instagram, etc. Para que un flujo responda por un canal, necesitas vincularlo.

Puedes vincular un solo flujo a varios canales (el mismo agente atiende WhatsApp y widget) o tener flujos diferentes por canal (uno para WhatsApp, otro para el widget).

Si vinculas varios flujos al mismo canal, uno de ellos debe ser el por defecto. Cuando un usuario escribe por ese canal, el motor ejecuta el flujo por defecto. Los demas flujos vinculados no se ejecutan automaticamente — solo se invocan via webhook o cuando otro flujo los llama como subflujo.

Requisitos para activar un flujo

• Plan activo: La organizacion necesita un plan de pago o saldo de credits para ejecutar flujos.
• Limite de nodos: Cada plan define cuantos nodos puede tener un flujo (configurable por la organizacion).
• Limite de flujos: Cada plan define cuantos flujos puedes crear en total.

Si el flujo no tiene suficientes credits o supera los limites del plan, el motor rechaza la ejecucion y responde con un mensaje de error.

Prueba tu flujo en el playground

Arriba a la derecha del editor hay un boton Probar. Abrelo y empieza a chatear con tu flujo. Cada turno te muestra que nodo se ejecuto, que datos pasaron por cada rama y cuanto costo en tokens. Si algo no responde como esperas, edita el system prompt o ajusta los nodos sin salir de la pantalla — todos los cambios se aplican al instante.

Puedes gestionar flujos via API:

# Listar los flujos de tu organizacion
GET /v1/public/flows

# Leer un flujo (grafo, estado, disparador)
GET /v1/public/flows/{id}

# Actualizar el grafo, el estado o el nombre
PUT /v1/public/flows/{id}

Patrones avanzados

Para flujos complejos, Daguito soporta patrones como:

• Fan-out: Un nodo puede enviar datos a multiples salidas simultaneamente, ejecutando varias ramas en paralelo.
• Subflows: Un nodo puede invocar otro flujo como sub-rutina, reutilizando logica.
• Streaming: Algunos nodos pueden enviar tokens al canal de respuesta en tiempo real mientras procesan.
• Detached: Ejecuciones que corren en segundo plano sin bloquear el flujo principal.
• Base de Conocimiento integrada: Nodos que buscan en bases de conocimiento y enriquecen el contexto del LLM.

What's next?