Build it visually
Every workflow is edited through the same definition in three interchangeable views — pick whichever fits the moment, and switch anytime without losing anything.See the whole flow at a glance
Every workflow — and every running instance of it — renders as a diagram, not just a list of steps. Abranch step expands into labeled then/else lanes right where it sits, so the decision tree is visible without opening the editor. Below is the shape of the lead-qualification workflow from the JSON example further down:
This is the same diagram whether you’re looking at the workflow’s definition or a live, running instance — running instances recolor each node from execution history: completed, current, waiting, failed (with the error inline), or not yet reached.
Branching
Abranch step evaluates one or more conditions against the instance context — the same condition shape used everywhere else in Hookie (equals · not_equals · contains · exists · gt · lt) — and runs then when they match, else otherwise. Because conditions read the context, you can branch on anything an earlier step produced: score a lead with AI, then route high-scorers one way and everyone else another. Branches nest up to 3 levels deep, and every taken path is recorded in step history so you can see exactly which way an instance went.
Branch sub-steps run synchronously — emit_event, call_ai, agent_call, and nested branch only. A delay or wait_for_event can’t sit inside a branch; put it after the branch instead. This keeps a branch’s execution atomic and its outcome immediately visible in the diagram.
Branching on an AI answer
gt and lt compare numbers, and a model replies with text — so what a call_ai or agent_call step puts in the context matters. A reply that is a JSON value is stored as that value; anything else is stored as the text the model wrote. So "8" becomes the number 8 and {"score": 8, "reason": "…"} becomes an object, while "Looks like a good fit" stays a string.
That gives you two shapes that work, and it is worth picking one deliberately:
- Ask for the bare value — “reply with the number only” with
"output_key": "score", then branch on{ "path": "score", "op": "gt", "value": 7 }. That is the example above. - Ask for an object — “reply with JSON: score and reason” with
"output_key": "ai", then branch on{ "path": "ai.score", "op": "gt", "value": 7 }. Conditions take dotted paths, so the reason travels with the score and both are visible in the instance context.
output_key itself — path: "score" would resolve to the whole object, and a numeric comparison against an object is false. A branch whose condition can never hold isn’t an error; it just takes else every time. The instance context is shown in full on the instance drill-down — check there first when a branch always goes the same way.
output_dataset is unaffected by any of this: it always records the model’s reply as the text it actually wrote, so the audit trail is what was said, not what was inferred from it.
Defining a workflow
Create workflows in the console under Project → Workflows — start in Canvas, Form, or JSON, whichever you reach for first. Entry conditions use the shared condition shape — an empty array matches every record in the dataset.Step types
AI agents
An AI agent is a reusable, named LLM persona — a model, a system prompt, a bounded token cap, and an optional memory dataset that every output is also written to for recall. Define agents next to your workflows in the console, then reference one from any workflow with anagent_call step — including inside a branch. Update the agent once; every workflow that uses it picks up the change.
Instances & observability
Each matching entry record starts an instance. The console lists instances per workflow with a drill-down into the live context, the recolored progress diagram, and a per-step history (started / completed / failed, including which branch was taken), so you can see exactly where a flow is and why it stopped.Limits
- Up to 32 steps per workflow (branch sub-steps count toward the total).
- Branch nesting depth: 3 levels.
- Active-instance cap per plan: 25 on Free, 500 on Pro, 2,000 on Team.
delayandwait_for_eventtimeouts resolve on the platform scheduler (~5-minute resolution).- AI steps are bounded to 1,024 output tokens per step. (The monthly AI run quota applies to AI triggers, not to workflow steps.)