Design a flow people can trust

Design before configuration

A reliable flow begins on paper, not on the canvas

Start with visitor goals, business ownership, and safe outcomes. Add a specialist only when it needs different instructions, knowledge, tools, or boundaries. The most dependable workflow is usually the smallest one that represents the real customer journey.

Begin with outcomes, not departments

A company org chart is rarely a good chatbot flow. Visitors do not think in internal team names; they think “I need to change my booking,” “Where is my order?” or “I do not understand this charge.” Design around those recognizable intentions.

For each intention, write four short answers:

1. What is the visitor trying to achieve?
2. What facts must be known before a useful answer or action is possible?
3. Which source or tool is allowed to supply those facts or perform that action?
4. When must the AI stop, ask for confirmation, return to Base Assistant, or involve a human?

A one-page planning worksheet

Visitor goalReschedule an existing appointment

Required detailsName, contact detail, existing appointment reference, preferred new time

Trusted sourcesPublished rescheduling policy and appointment lookup webhook

Safe finishShow the proposed change, ask for confirmation, submit once, and clearly report the result

ExitReturn general service questions to Base; send unclear payment questions to Billing; offer human contact if the record cannot be found

If two proposed specialists produce almost identical worksheets, combine them. If one worksheet contains unrelated goals with different risk levels, split it.

A worked example: a small clinic flow

The clinic’s Base Assistant already answers opening hours, service descriptions, location, preparation guidance, and broad website questions. The advanced flow adds three bounded specialists:

General ownerBase AssistantWebsite questions and knowledge

→ book, move, cancel

SpecialistAppointmentsCollect and verify booking details

SpecialistBillingInvoices, deposits, payment policies

SpecialistDe-escalationCalm, acknowledge, clarify, offer human help

This is intentionally not six or twelve agents. Services, hours, preparation, and directions remain knowledge topics for Base Assistant. An “FAQ Agent” would duplicate Base. A separate agent for every appointment type would multiply overlapping scopes. The three specialists exist because their conversational rules and outcomes differ.

The responsibilities in the clinic example

Owner	Owns	Does not own	Likely capabilities
Base Assistant	Greetings, service information, location, opening hours, broad website knowledge	Making or changing a booking; resolving account-specific billing	Knowledge Base and any general tools not owned by a specialist
Appointments	New bookings, rescheduling, cancellation, availability questions tied to booking intent	General service education; unexplained charges; medical advice	Appointment lookup and confirmed booking-request submission
Billing	Invoices, deposits, receipts, payment-policy explanation	Taking card details in chat; clinical questions; appointment availability	Published billing knowledge and a safe contact or ticket action
De-escalation	Clearly angry, overwhelmed, or repeatedly frustrated visitors who need acknowledgement and a calmer next step	Pretending to resolve matters it cannot verify; emergency or crisis intervention	Human-support contact information; normally no broad action access

Decide which connections deserve explicit handoffs

SmartSite can generate entry routes from specialist descriptions, but important paths should be explicit. An explicit handoff says both “this destination is allowed” and “this is the intent that justifies it.”

For the clinic, useful connections include:

• Base → Appointments: schedule, reschedule, cancel, check booking, or ask availability as part of booking.
• Base → Billing: invoice, receipt, charge, deposit, payment method, or billing-policy question.
• Appointments → Billing: the visitor changes from arranging the booking to a clearly separate payment or invoice problem.
• Any relevant owner → De-escalation: the newest message shows clear agitation, confusion, or repeated frustration and would benefit from a calmer specialized response.
• Specialist → Base: broad website question outside the specialist’s scope, when Return to Base Assistant is permitted.

Avoid a complete web where every specialist connects to every other specialist. Too many generic exits encourage unnecessary movement. Add the routes that represent real topic changes, then let Base be the home for everything broad or unowned.

A route is not always a runtime handoff

SmartSite may choose the best specialist before the agent run starts. Analytics records that as a route decision. A handoff is counted only when one running agent transfers ownership to another during the run. This is why a conversation can show “1 route / 0 handoffs” even though the selected specialist differs from the previous conversational owner.

Create the workflow shell

Go to AI Website Chat → Agent Flows → New Workflow. At this stage, create only the container. You will tune routing later.

Workflow Basics fields

Field	What it controls	How a non-technical admin should use it
Name	The friendly title shown in the workflow library and builder.	Use the visitor journey or business area: “Clinic visitor support,” not “Workflow 2.”
Key	A stable internal identifier for the workflow.	Use short lowercase words with underscores, such as clinic_support. Avoid changing it merely because the display name changes.
Status	Draft is not live; Active identifies the published live workflow; Paused stops serving visitors.	New work begins as Draft. Publishing makes a tested revision live. Pause before major maintenance or deletion.
Description	Explains the purpose of this workflow to administrators.	State the audience, owned journeys, and exclusions in two or three sentences. This is team documentation, not a prompt for one agent.
Start Agent	Chooses a configured specialist to start, or uses Auto / first agent.	Prefer normal routing from Base for a mixed-purpose website. Set a specialist only when every conversation entering this workflow should begin there.
Fallback Message	Provides the visitor-facing response when the flow cannot complete normally.	Use a calm, honest sentence with a real next step. Do not claim an action succeeded. Example: “I could not complete that request. Please contact our team at …”

The Status field does not publish draft edits by itself. The live visitor configuration is created through Publish Workflow or Publish Changes after readiness checks. This separation lets admins keep editing without changing what visitors currently use.

Build in this order

1. 01

   Keep Base Assistant healthy

   Review its general instructions and synchronized knowledge first. Advanced routing still depends on Base as the broad owner and fallback.

2. 02

   Add one specialist

   Write a narrow description and full playbook. Test several entry messages before adding more roles.

3. 03

   Add an explicit Base entry

   Create a Base-to-specialist handoff with a concrete condition. This gives admins direct control instead of depending only on generated scope.

4. 04

   Attach the minimum capabilities

   Assign only tools the specialist needs. Configure and test the underlying SmartSite Tool before exposing it in the flow.

5. 05

   Add exits and topic changes

   Decide when to return to Base and which specialist-to-specialist moves are genuine. Avoid generic “send elsewhere” rules.

6. 06

   Test, observe, then expand

   Use Expected handler tests and real conversation traces. Add the second specialist only when the first path is understandable.

Use the AI Flow Builder as a draft partner

The AI Flow Builder accepts a description of the business process, visitor goals, and systems involved, then generates a plan you can review and apply. It can save time when turning a well-defined process into a first layout. It is not a substitute for ownership and safety decisions.

A useful request names:

• the visitor groups and top goals;
• what Base Assistant should retain;
• the proposed specialists and their boundaries;
• available knowledge and existing SmartSite Tools;
• actions that require confirmation;
• when to return to Base or offer human help;
• information the system must never request or invent.

Useful builder request

“Create a small clinic support flow. Keep general service, location, opening-hours, and preparation questions with Base Assistant. Add Appointments for scheduling, moving, and cancelling bookings; Billing for deposits, invoices, and receipts; and De-escalation for clearly frustrated visitors. Appointments may use the existing appointment lookup and booking request tools. Never request medical history or card details. Protected actions must be confirmed. Return unrelated questions to Base.”

Too vague

“Make a complete flow for my clinic that handles everything.”

Always review the generated plan field by field. Confirm that no tool was assigned too broadly, no specialist claims professional authority it should not have, and no route creates a loop or an impossible exit.

Architecture mistakes visitors will notice

Healthy shape

• Three to five clearly different responsibilities.
• Specific entry conditions written in visitor language.
• Base owns general and uncertain questions.
• Tools live with the specialist accountable for their outcome.
• Every narrow specialist has a sensible exit.

Warning signs

• Agents named General, Helper, Support 1, and Support 2.
• The same tool attached to several roles without a reason.
• Conditions that all say “when the user needs help.”
• No route back to Base and no explicit specialist exit.
• A flow mirroring every internal department regardless of visitor need.

Review the canvas as a story

Open the builder and read from Base Assistant outward. For every line, say aloud: “When the visitor ___, conversation ownership may move from ___ to ___.” If the sentence is vague, rewrite the handoff condition. For every tool, say: “This specialist may use ___ only after it knows ___, and the visitor must confirm if ___.”

The canvas supports dragging for layout, selecting a node or line to inspect it, adding agents/tools/handoffs from the inspector, and switching the canvas theme. Layout changes make the diagram easier for administrators to read; they do not alter routing logic. The fields and connections do.

agentic-flows-design-workflow

Screenshot capture pending /images/screenshots/agentic-flows/design-workflow.webp

A complete but intentionally small workflow canvas

Capture

Open a synthetic appointment workflow with Base Assistant, Appointments, Billing, and De-escalation specialists plus two clearly named tools.

Show

Base Assistant, specialist nodes, tool nodes, explicit handoff lines, canvas controls, and inspector

Viewport

Desktop, 1440 × 1000

Annotate

Number the Base Assistant, one specialist, one tool, and one handoff as the four building blocks.

Redact

API keys, private URLs, personal data, real visitor messages, and production action details

Before moving to field configuration

You are ready to build when each specialist has one named outcome, a clear non-goal, a trusted source for facts, a small capability set, and an exit. Next, write the specialist fields, then connect tools and handoffs. Do not tune advanced routing to compensate for unclear responsibilities; fix the design first.