> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tied.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Chatbot
> Scripted conversation paths for the things that must happen the same way every time.
A chatbot flow is a graph you draw: nodes that send messages, wait for replies, branch on what the customer said, and eventually either finish or hand to a human.
It is the deterministic half of Tied. The [AI agent](/agents) handles the long tail — the questions you could never enumerate. A flow handles the paths where you need the same thing to happen every time, in the same order, with no interpretation.
## When to build a flow instead of letting the agent handle it
Reach for a flow when **the sequence itself matters**:
* A returns process with strict eligibility rules that must be checked in order
* Onboarding that collects specific things before it can continue
* Anything with a compliance script, where the wording is not yours to improvise
* A qualification path where the next question depends on the last answer
Let the agent handle everything else. A flow that tries to anticipate every question becomes an unmaintainable decision tree, which is exactly the failure mode that gave scripted bots a bad name.
**Most accounts run both, and the split is usually obvious in hindsight.** If you find yourself
writing a branch for "customer asked something unexpected", that is the agent's job, not the flow's.
End the flow and hand over.
## How a flow runs
Triggers are a nestable condition tree — `any` or `all`, arbitrarily deep. Conditions include a new
conversation, a new message, out-of-hours, and contact attribute matches.
**Out-of-hours here means a fixed 09:00–18:00 window in the account's timezone, not the inbox's own
configured business hours.** A working-hours service exists and is what [ongoing
campaigns](/campaigns/ongoing) genuinely gate on — flow triggers don't use it yet. If your inbox's
real hours differ from 09:00–18:00, a flow's "out-of-hours" trigger won't line up with them.
Node by node, one conversation at a time. Execution state is tracked, so a flow can pause at a
`wait_for_reply` for as long as it needs and resume when the customer answers.
A flow ends one of three ways: it completes, it hands the turn to the [AI agent](/agents) through a branch's `agent` fallback, or it goes to a human — and each handoff is recorded.
## Versioning, and one thing to know before you edit a live flow
Flows are **versioned**, and a conversation already mid-flow when you publish is not yanked onto the new graph halfway through. That part works well.
**"Save draft" publishes.** Both the save and publish controls dispatch the same action against the
same endpoint — the only difference between them is the version label recorded. There is currently no
way to save work-in-progress without making it live.
Until that changes, treat every save on a live flow as a deployment. Duplicate the flow and edit the
copy if you need somewhere safe to work.
See [Versions and publishing](/chatbot/versions).
## Templates
Rather than starting from an empty canvas, you can start from a prebuilt flow and adapt it. See [Flow templates](/chatbot/templates).
## Flows and billing
A flow does not change how resolutions are classified. If a flow resolves a customer's problem and a positive signal confirms it, that is a resolution priced by [what it actually touched](/pricing/resolution-pricing) — the same as if the agent had done it.
Two things worth knowing:
* A flow that **hands off to a human** produces no billable resolution once the human messages the customer. Same rule as agent handoff, and free.
* A flow that ends without a positive signal bills nothing. See [What counts as a resolution](/pricing/resolutions).
## In this section
Navigating, adding and connecting nodes.
The nine node types, what each does, and what is not yet available.
Conditions, captured variables and Liquid templating.
Emitting AMB primitives from inside a flow.
Starting from a prebuilt flow.
Running a flow before a customer does.
Draft versus live, history and rollback.
The other half — everything a flow should not try to script.
## Next
Start here — the node set defines what a flow can actually do.
Where building a flow fits in the order of setting Tied up.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.