Skip to main content
The Planner is the system that turns a conversation into a workflow. You say what you want; CelerFlow clarifies the goal, assembles the right steps from your agent pool, checks for blockers, and deploys. Say it once. It’s done.

​
Two agents, one flow

Authoring involves two distinct agents:
  • Interview agent — Runs in the chat. It clarifies your intent and produces a Requirement Brief: a versioned, structured statement of what you want (draft → confirmed → superseded). It never builds the DAG itself.
  • Planner — A system-level control-plane agent. Once you confirm a brief, the Planner (and its build-time wrapper) compiles the brief into a DAG. The Planner only composes from already-registered platform agents — it never calls third-party tools directly, which keeps it from hallucinating tool calls.
The confirmed Requirement Brief is the single hand-off between the two — and the source of truth for the build.

​
Conversation order

A session follows a consistent flow:
  1. Clarify goal and destination — The Interview agent confirms what outcome you want and where the result should land (e.g. a Notion page, an email, an Attio record, or a run detail view), then writes a Requirement Brief.
  2. Confirm the brief — You approve the brief; this is what advances to the build.
  3. Match available agents — The Planner inspects your team’s agent pool to see which platform agents can cover the required steps.
  4. Draft the plan — A proposed DAG is shown on the canvas. You can accept it or ask for changes in chat.
  5. Gate on blockers — Missing connections or unresolved delivery targets pause the build. See HITL pause points below.
  6. Deploy — You confirm and the workflow is created and queued for deployment.

​
How the pipeline works

Behind the build is a LangGraph pipeline with four logical nodes: intent (parse the brief into a structured request), match (find pool agents that cover the required capabilities), assemble (wire the steps into a DAG with bound inputs and output keys), and validate (check for missing connections, placeholder target IDs, and binding correctness). The pipeline produces one of three outcomes: draft_ready, needs_clarification, or validation_failed. Only draft_ready advances to deploy. The graph uses real LangGraph interrupt with a Postgres checkpointer, so a build can genuinely pause for human input and resume where it left off.

​
HITL pause points

The build stops and waits for a human action in two cases: Missing OAuth connection — If a step requires an app (e.g. Gmail, Notion, Slack) that isn’t connected to the team, a connection card appears in the chat. You connect it in place and the build resumes. See Connections. Delivery target selection — Before deploying a workflow that writes to a destination like Notion, the Planner asks which database or page to write into. Placeholder IDs are rejected at validation and the Planner asks again until a real target is confirmed. See Approvals.

​
Deploy and redeploy

When the plan is accepted, the Planner asks “Ready to deploy?” Confirming creates the workflow record and queues a deploy command to Trigger.dev. If you refine and redeploy in the same session, the existing workflow is upgraded in place — no duplicate is created. See Workflows for details on the lifecycle. For a step-by-step UI walkthrough, see Building a workflow.