Skip to main content

Automation Flow Builder

Repositions Qontak's bot conversation "tree diagram" into a Qontak-native general automation flow builder — replacing the tree diagram rather than sitting beside it. A bot conversation becomes one specific case of a workflow: trigger = message received (keyword/channel/NLP), and the conversational steps (ask question, send message, AI agent, reuse response, WhatsApp Flow) become node types in the same NodeRegistry catalog as automation actions (CRM, HTTP, delay, tag, assign). One graph, one canvas, one run history — so a tenant can build a single continuous flow that starts with a customer message, lets the bot/AI handle it, and continues into post-conversation automation (wait → CSAT → CRM sync → escalate) without handing off to a second system.

Built on the existing AI-agent NodeRegistry + node_executions engine (chatbot BE), which already implements ~70% of a general action-execution engine; the legacy Path/Intent/Response tree and its custom FE canvas are migrated onto the new engine rather than generalized in place. Explicitly avoids a dependency on the external Mekari Workflow product — the squad owns the full critical path.

The motivating event: from 1 October 2026, Meta charges per WhatsApp service message (no volume discount — Bifrost squad, meta-whatsapp-pricing-oct-2026), making automation that resolves or deflects conversations directly money-saving for every WhatsApp tenant.

Status: desk-validated 🟢 GO (competitive/pricing comparison vs Sleekflow, Respond.io, WATI, Trengo, Gallabox — see documentations/). Pre-PRD; open product decisions were resolved in a grilling session on 2026-07-22 (see documentations/grilling-decisions-2026-07-22.md): P0+P1 committed unconditionally, P2 conditional on a 3-criteria feasibility spike, design-partner-first migration, admin+supervisor authoring, pricing gates launch not the PRD, and write-prd is unblocked (spike, design brief, and volume pull run in parallel). PRD authoring deliberately not yet started.

Delegated responder engines (concept note, 2026-07-21)​

The flow engine is a control-plane router over pluggable responder engines — Qontak AI, human agents, Meta Business Agent (MBA), and future providers. Engines split into two classes:

  • Per-turn engines (Qontak AI, bot responses, human assignment): the flow both orchestrates and executes — it generates/sends replies and can interleave steps between turns, as today.
  • Boundary-control engines (MBA; any provider that answers outside Qontak): the flow orchestrates only at hand-off boundaries. For MBA: hand off = Thread Control release (after which Qontak receives only standby copies), take back = send a message, observe = standby persistence. No per-turn steps are possible while the delegated provider holds the conversation — so the only node classes that can ever exist for such providers are hand-off / take-back / observe, and a hand-off node is always terminal for its branch.

Design consequences (from the MBA case — chatbot/meta-business-agent, ANCHOR §6a 2026-07-21):

  • No provider-specific flow types. One multi-channel flow serves all providers; a "Hand over to Meta Business Agent" node is capability-gated per channel and per number (WA Cloud + MBA active), with a fallback output port taken wherever the gate fails — so the same flow behaves correctly on webchat, IG, and mixed MBA/non-MBA numbers.
  • NodeRegistry capability metadata. Node types declare supported_channels / requires (the existing WhatsApp-Flow node needs the same gating, today ad-hoc); publish runs a save-time lint: "this branch uses a WhatsApp-only node but the flow also serves webchat — its fallback branch will run there."
  • Per-number topology, not per-flow: either MBA-primary (flow dormant on that number; Qontak observes on standby) or flow-primary (flow orchestrates; MBA reachable as a node). Wireframe: ../meta-business-agent/wireframes/lifecycle-1-onboard.svg (Panel D).

Documentation​