Introduction

Some calls are a conversation and some are a procedure: a booking that needs five details in a particular order, an intake where the safety question has to come before anything else. A task group is that procedure written down once: an ordered list of steps your assistant works through with the caller, in the order you decide.

Overview#

A task group is a named flow made up of tasks. Each task says what it is for, how the assistant should go about it, and (where it matters) what the assistant should come away with and which of your tools it is allowed to use on that step. You decide the order, and you can change the order later without rewriting any of the steps.

A flow is not tied to one assistant. You build it once and link it to as many assistants as need it, and any one of those assistants can be given different wording for a single step without changing the shared flow. That is what makes one booking procedure workable across ten locations: the same steps everywhere, with the one local difference recorded against the assistant that needs it. An assistant follows the flows linked to it only when task-driven mode is turned on for that assistant, so nothing changes on your live calls until you say so.

• Take a booking the same way every time: party size, date, time, name, contact number, in that order, on every call and on every line.
• Run an intake in a safe order: ask the question that decides whether to continue before collecting anything else, so the assistant never gathers details it should not have asked for.
• Qualify a lead consistently: budget, timeline, who signs off; the same three questions from every assistant your team runs.
• Reuse one procedure across sites or brands: one flow linked to every assistant, with a per-assistant tweak where a site genuinely differs (parking, seating, opening times).
• Change a step in one place: edit the step on the shared flow and every assistant linked to it works from the new version.

Limits & FAQ#

• A flow's steps are explicitly ordered, and reordering the whole flow is a single operation: you do not renumber steps one at a time.
• An assistant can be linked to more than one flow, and a flow can be linked to more than one assistant.
• Task-driven mode is off by default. An assistant with no flows linked, or with the mode switched off, behaves exactly as it does today.
• A per-assistant change is recorded against that assistant, not against the flow. The shared flow is never edited by it, and the other assistants linked to the flow are unaffected.

Can several assistants share one procedure? Yes. That is the point of building it as a flow rather than writing it into each assistant's instructions. Link the same flow to each assistant that needs it.

What if one location does a step slightly differently? Give that assistant its own wording for that one step. The shared flow stays as it is, the other assistants keep the original wording, and removing the change later puts that assistant back on the shared step.

How do we retire a flow? Unlink it from an assistant when that assistant should stop following it. The flow itself is a separate thing, so unlinking it from one assistant leaves it in place for every other assistant still using it.

Next steps#

• Manage task groups: build a flow, order its steps, link it to assistants, and set per-assistant overrides through the API.
• Create and configure an assistant: the assistant that runs the flow, and where task-driven mode is switched on.
• Prompts: the standing instructions that shape everything a flow does not cover.