Перейти до основного вмісту

Workflows

Workflow — це візуальна мапа того, що ваш агент має робити крок за кроком — хто говорить першим, що запитувати, коли розгалужуватись, коли переводити дзвінок і коли передавати його іншому агенту. Ви будуєте її на полотні, розміщуючи ноди й з'єднуючи їх.

Використовуйте workflow, коли одного промпта недостатньо — коли в дзвінку є чіткі етапи («спершу кваліфікувати, потім зібрати деталі, потім записати або перевести»), коли потрібна детермінована маршрутизація за відповідями абонента (не «AI зазвичай впорається»), або коли агент має передати частину роботи фахівцю.

Prompt vs Workflow

Prompt — це одна довга інструкція. Агент читає її один раз і використовує впродовж усього дзвінка. Workflow — це багато маленьких інструкцій, по одній на ноду, з явними переходами між ними. Граф керує дзвінком — агент кожної ноди відповідає лише за свій шматок.

Якщо ваш агент уже добре працює з одним промптом, workflow вам не потрібен. Переходьте на workflows, коли починаєте накопичувати в промпті правила «якщо X, то Y», і вони перестають надійно працювати.


Редактор

Редактор workflow живе на власній вкладці на сторінці агента. Ви бачите полотно з нодою Start і нодою End за замовчуванням. Додаєте ноди з тулбара, перетягуєте їх на полотно та з'єднуєте ребрами.

Права панель змінюється залежно від того, що ви вибрали:

  • Клік по ноді — відкриває її панель налаштувань (промпт, поля, змінні екстракції тощо).
  • Клік по ребру — відкриває налаштування його тригера (AI decides / Condition / Always).
  • Панель Variables (кнопка в тулбарі) показує кожну змінну, яку workflow оголошує або використовує, з переходом одним кліком до ноди, яка її встановлює або читає.

Запустіть Test Call у браузері просто з редактора — світний світлячок слідкує за позицією в реальному часі, щоб ви бачили, яка нода зараз активна в кожну мить.

Undo / Redo (v2.8) — редактор зберігає історію до 20 кроків, тож ви можете відкотити хибний хід (або повторити його) без перебудови. Видалення ноди спершу запитує підтвердження (v2.8), щоб ви не втратили крок через випадковий клік.

Build as a workflow (v3.0)

Вам не обов'язково починати з чистого полотна. Точка входу «build as workflow» створює workflow для агента й одразу переносить вас у білдер — одна дія створює workflow і відкриває редактор, готовий до додавання нод.

Збереження та стани

Workflows мають три стани:

  • Draft — редагований, ще не в проді. Використовуйте Test Call, щоб протестувати.
  • Active — у проді для реальних дзвінків. Агент використовує цей workflow з наступного дзвінка.
  • Template — повторно використовуваний шаблон, ніколи не прив'язаний прямо до агента. Можна інстанціювати на кілька агентів.

Ноди

Кожна нода — це крок у розмові. Різні типи нод роблять різні речі — одні говорять, інші слухають, інші маршрутизують, четверті виконують інструменти.

Agent

Нода Agent — серце етапу workflow. Коли граф доходить до ноди Agent, цей агент бере слово й веде розмову, доки щось не запустить перехід.

Ви налаштовуєте особистість і завдання ноди Agent безпосередньо на полотні (вкладка Prompt відкривається після кліку на ноду) — це промпт для цього шматка розмови, не для всього дзвінка. Також можна прикріпляти бази знань та інструменти по ноді.

Greeting — відкривальна фраза. Якщо це вхідна нода (перша зупинка після Start), це перше, що чує абонент.

Граф керує персоною

Коли граф керує дзвінком, промпт активної ноди накладається поверх основного промпта агента (того, що у вкладці Model). Граф володіє особистістю та завданням на кожному етапі, а базові інструкції агента залишаються на місці як фундамент.

Subagent

Subagent — це помічник, який працює інлайн — забирає розмову для конкретного завдання й повертає результат тому, хто його викликав.

Subagents добрі, коли шматок роботи повторно використовуваний або відчувається окремим: «перевір особу абонента», «збери адресу доставки», «кваліфікуй лід за методом SPIN». Батьківський агент викликає subagent, той робить своє діло, повертає результат, батько продовжує з того місця, де зупинився.

Ноди Subagent мають ті самі вкладки, що й нода Agent (Prompt, Knowledge, Tools, Actions) — редактор автоматично створює прихованого backing-агента за вас. Цього прихованого агента не видно в основному списку агентів, і він не зараховується в ліміт агентів вашого тарифу.

Return variable — поле, куди зберегти результат subagent (наприклад, identity_verified, lead_score).

Хто говорить першим

За замовчуванням subagent відкриває свій хід мовленням — він вітається або ставить своє перше запитання тієї ж миті, як перебирає керування. Це змінюють два перемикачі:

  • Wait for the caller (don't speak first) — subagent мовчить на вході й відповідає лише після того, як абонент щось скаже. Увімкніть це, коли subagent — перша зупинка в дзвінку і ви хочете, щоб абонент почав сам (справжнє «Алло?»), а не агент відкривав розмову — або посеред дзвінка, коли попередній крок уже все сказав, і subagent має просто слухати відповідь.
  • Silent step (don't speak) — subagent взагалі ніколи не говорить. Він читає розмову, що відбулася досі, визначає результат і одразу повертає керування. Використовуйте його як невидимий маршрутизатор: «прочитай, що запитав абонент, і виріши, який це відділ» — без жодного сказаного слова, лише рішення, на якому граф розгалужується.

Allowed result values

Subagent зазвичай фіналізує з тим значенням, яке визнав доречним. Якщо ви збираєтесь розгалужуватись на цьому результаті за допомогою Condition-ребер, закріпіть його за закритим списком дозволених значень:

  • Перелічіть кожне дозволене значення під Allowed result values (наприклад, sales, support, billing).
  • Subagent має фіналізувати рівно одним із них — він не може вигадати нове.
  • Поєднайте кожне значення з Condition-ребром (result is "sales" → …) для чистої, передбачуваної маршрутизації.

Це надійний спосіб змусити subagent вирішувати й маршрутизувати: результат гарантовано збігається з однією з ваших гілок.

Маршрутизація з subagent

Subagent повертає єдиний результат, коли завершує роботу. Налаштуйте, що буде далі, за допомогою ребер Condition або Always на цьому результаті — вихід subagent не використовує ребра «AI decides». Саме тому Allowed result values + Condition-ребра — рекомендований патерн для маршрутизуючого subagent.

Message

Нода Message вимовляє фіксовану фразу — без ходу AI, без імпровізації. Використовуйте для переходів («Хвилинку, переводжу…»), обов'язкових правових повідомлень або заздалегідь визначених підтверджень, де важливі конкретні слова.

Text — що сказати. Підтримує токени {{variable}} для підставлення захоплених значень, наприклад "Thanks {{first_name}}, I've booked you for {{appointment_time}}."

Нода Message використовує хід — агент згори нічого не додасть.

Gather input

Нода Gather input ставить одне запитання і захоплює відповідь абонента у змінну.

Prompt — питання, яке поставити. Підтримує {{tokens}}. Variable — ім'я поля, куди зберегти відповідь. Max silence (v2.8) — межа для окремого запитання на те, скільки чекати відповіді абонента, перш ніж рухатися далі. Задавайте її для кожної ноди Gather input, тож швидке запитання «так/ні» може вичерпати час раніше, ніж запитання, де абонента просять зачитати довгий номер рахунку.

Використовуйте щоразу, коли вам потрібне конкретне значення перед продовженням — email, номер рахунку, кількість осіб, категорію проблеми. Наступний хід абонента стає значенням; на ньому можна розгалужуватись ребром Condition відразу після.

Update state

Нода Update state записує одне чи кілька значень у змінні workflow, нічого не кажучи і не запитуючи. Використовуйте для попереднього встановлення значень за замовчуванням, позначення флагів прогресу або композиції значень з попередніх кроків.

Variable / Value — пара ключ-значення. More variables (optional) — додаткові пари ключ-значення.

Як ключі, так і значення підтримують {{tokens}}, тож можна складати нові значення з існуючих.

Condition

Нода Condition — це нода виключно для маршрутизації — не говорить, не запитує, просто надсилає дзвінок по вихідній гілці, що збіглась.

Сама умова живе на кожному вихідному ребрі, не на ноді — див. ребра Condition нижче.

Використовуйте ноду Condition, коли хочете чіткої точки «fan-out» у своєму графі: багато гілок, що залежать від значення однієї змінної. Порівняно з умовами на ребрах Agent-нод, виділена нода Condition робить логіку маршрутизації візуально очевидною.

Tool

Нода Tool виконує один з підключених інструментів агента як крок графа — без участі AI у рішенні про виклик. Використовуйте, коли потрібен факт, а не розмова: «знайди цього клієнта», «перевір залишок на складі», «GET поточної погоди».

Можна:

  • Вибрати один з наявних в агента інструментів (пошук по календарю, пошук у базі знань, конкретна дія інтеграції), або
  • Налаштувати inline HTTP-виклик просто в ноді (URL, метод, заголовки, параметри, body).

Відповідь інструмента стає доступною всім наступним нодам. Якщо відповідь — JSON-об'єкт, кожне поле верхнього рівня стає окремою змінною — відповідь на кшталт {"is_known": true, "tier": "gold"} запише і is_known, і tier, щоб ви могли на них розгалужуватись.

Токени в Tool

Кожне текстове поле в ноді Tool — URL, значення заголовків, body — підтримує {{tokens}}. Вставте змінну в шлях URL, заголовок або body запиту без написання коду.

Якщо виклик інструмента впав (HTTP-помилка, таймаут, мережа), нода логує помилку і граф іде далі — без даних. Сплануйте наступні умови так, щоб вони обробили випадок «немає значення».

Knowledge (RAG)

Нода Knowledge (RAG) — це варіант Tool, сфокусований на пошуку в базі знань. Виберіть одну з баз знань агента, напишіть пошуковий запит (з {{tokens}}, якщо хочете), і нода виконає пошук як крок графа.

Використовуйте, коли хочете, щоб workflow щось знайшов перед тим, як заговорить Agent-нода — наприклад, дістати останнє замовлення клієнта, щоб наступна Agent-нода могла його згадати, не питаючи. Знайдений контент потрапляє у змінну, яку можна підставити в промпти й повідомлення.

Integration

Нода Integration — це сфокусований варіант Tool для підключених зовнішніх сервісів — Google Calendar, Outlook, HubSpot. Вибираєте провайдера й конкретну дію (наприклад, check_availability, create_event), задаєте параметри, і нода детерміновано викликає інтеграцію.

Якщо інтеграція не підключена в цього агента, нода проходить без дії — ваш граф продовжується. Перевіряйте наступні умови на випадок «не спрацювало».

Phone transfer

Нода Phone transfer переводить дзвінок (warm transfer) на зовнішній телефонний номер. Після успішного переведення дзвінок покинув ваш workflow — ваш агент більше не на лінії.

Number — пункт призначення у міжнародному форматі з + на початку (наприклад, +15551234567). Підтримує {{tokens}}, тож пункт призначення може прийти з попереднього кроку (наприклад, відповідь на «з яким офісом вас з'єднати?»).

Якщо переведення не відбулося (неправильний номер, немає відповіді, не налаштовано телефонне підключення), граф відкочується і поточний агент залишається на лінії. Розмова триває як звичайно — агент може вибачитись і спробувати інший шлях.

End call

Нода End call закриває — агент вимовляє налаштоване прощання і кладе слухавку. Використовуйте як чистий термінал для гілок «все зроблено» або для гілки «не можемо допомогти, вибачте» з важкого для обробки Condition.

Не вимагає конфігурації, окрім вхідного ребра.

Повторне використання workflow (Sub-workflow)

Нода Sub-workflow зарезервована для вбудовування іншого workflow як під-графа. Ця нода є в редакторі, але ще не повністю підключена — граф проходить через неї нічого не роблячи. Не покладайтесь на неї для продакшен-дзвінків. Ми її увімкнемо, коли випустимо повторно використовувані під-графи.


Ребра (Connections)

З'єднуєте одну ноду з наступною через ребро. Тригер ребра вирішує, коли спрацьовує перехід.

Є три тригери:

ТригерХто вирішуєКоли спрацьовує
AI decidesAIКоли розмова робить це природним наступним кроком. AI отримує «інструмент переходу», який може викликати.
ConditionРантаймКоли змінна збігається з правилом, яке ви написали. Оцінюється до відповіді AI.
AlwaysРантаймБезумовно — як тільки джерельна нода завершилась. Без вводу абонента, без AI.

AI decides (за інтентом)

Використовуйте AI decides, коли тільки AI може вирішити, коли перемикати — «якщо абонент питає про ціни, переведи на агента продажів», «якщо звучить як скарга, запусти subagent вибачень».

Ви пишете короткий опис інтента на ребрі (наприклад, «Абонент питає про ціни або хоче проапгрейдити тариф»). AI бачить це як інструмент, позначений цим інтентом, і вирішує, чи викликати його на основі розмови. Якщо присутні кілька AI-decides ребер, AI обирає максимум одне за хід.

Condition (детерміноване розгалуження)

Використовуйте Condition, коли хочете, щоб граф — не AI — вирішував за відомим фактом: «якщо lead_score is more than 7, надішли на closer; інакше — ввічливо завершити дзвінок».

Conditions оцінюються до відповіді AI, тож вони завжди перемагають AI в цьому ході. AI не може перевизначити умову, що збіглась.

Можна будувати умову з цих операторів:

ОператорЗначенняПриклад
isточне збігання (регістронезалежно для тексту)intent is "billing"
is notне збігаєтьсяstatus is not "active"
containsпідрядок (регістронезалежно)feedback contains "broken"
is more thanчислове >lead_score is more than 7
is less thanчислове <wait_minutes is less than 5

Можна також комбінувати клаузи через All (усі мають збігтись — AND) або Any (хоча б одна має збігтись — OR), та вкладати їх. Тож правило на кшталт «абонент відомий і його tier gold або premium» стає:

All:
- is_known is true
- Any:
- tier is gold
- tier is premium
Відсутні змінні ніколи не збігаються

Якщо посилаєтесь на змінну, яка ще не встановлена (наприклад, AI її ніколи не зібрав), умови на ній завжди не виконуються — вони не дають помилку, вони просто не збігаються. Тож loyalty_tier is "gold" поверне false, якщо loyalty_tier ніколи не встановлювався. Проектуйте гілки так, щоб обробити це — зазвичай через гілку else (див. нижче).

Гілка else — коли жодна умова не збіглась

Якщо у вас кілька Condition-ребер виходить з ноди й жодне не збіглось, дзвінок падає на не-Condition ребро найнижчого пріоритету (Always або AI-decides ребро). Якщо fallback немає взагалі, AI повертає собі контроль і може продовжувати вільно.

Поширений патерн: кілька Conditions для відомих шляхів плюс Always ребро на catch-all (сказати щось через Message, потім End call або перевести).

Always (auto-advance)

Використовуйте Always, коли наступний крок безумовний — без рішення, без вводу абонента. Два природних застосування:

  • Ланцюжок кроків: Message → Update state → Message → Tool → Condition. Кожен крок завершується, і Always-ребро відразу просуває далі.
  • Авто-просування після того, як агент закінчив говорити: Agent-нода з вихідним Always-ребром означає «як тільки AI замовкне, рухайся далі» — без необхідності відповіді абонента. Корисно для монологових потоків, наприклад агента-презентера, який вимовляє свою частину і переходить до наступної секції.
Пріоритет між тригерами

Condition та Always (детерміновані) завжди перемагають AI decides. Якщо Condition збіглось, інструменти переходу AI ігноруються в цьому ході. Це те, що дозволяє писати правила, які AI не може обійти.

Порядок гілок

Коли з однієї ноди виходить кілька ребер, редактор дозволяє задати пріоритет, перетягуючи рядки вгору або вниз. Гілки з нижчим пріоритетом перевіряються першими. Це має значення лише тоді, коли дві гілки можуть спрацювати на одному й тому ж ході — зазвичай два Condition-ребра з правилами, що перетинаються. Перша гілка, що збіглась, перемагає.

Carry context — скільки наступний агент пам'ятає

Кожне ребро має налаштування Carry context, що контролює, скільки транскрипту попередньої розмови бачить наступна нода:

  • Full transcript (за замовчуванням) — наступний агент бачить усе, що було сказано досі.
  • Summary only — платформа підсумовує попередню розмову і передає коротке резюме наступному агенту.
  • Nothing — наступний агент починає з чистого аркуша, без попереднього транскрипту.

Використовуйте Summary only, коли передаєте розмову спеціалізованому агенту, якому не потрібне кожне слово — це економить токени й тримає нового агента сфокусованим. Використовуйте Nothing для гілок, де персона нового агента має бути відокремленою (наприклад, опитування про задоволеність у кінці дзвінка).


Змінні

Змінні — це пам'ять workflow. Більшість речей у workflow — це або встановлення змінної, або її читання.

Оголошення змінних

Панель Variables (кнопка в тулбарі) показує кожну змінну workflow з кроками, що її встановлюють або читають. Клік по змінній — перехід до сетера; це найшвидший спосіб знайти, де щось іде не так.

Можна оголосити змінну зі значенням за замовчуванням на панелі — корисно для флагів на кшталт escalated=false, які мають існувати від самого початку, щоб ваші умови ніколи тихо не падали через «відсутність».

Вбудовані змінні дзвінка

Кілька змінних заповнюються за вас на самому початку кожного дзвінка — ви їх не оголошуєте й не встановлюєте, вони просто є, щоб їх читати:

ЗміннаЩо містить
{{call_from}}Номер телефону абонента
{{call_to}}Номер, на який зателефонували (ваш номер)
{{call_direction}}inbound або outbound

Оскільки вони існують від першої миті, на них можна розгалужуватись на найпершій ноді — наприклад, Condition на call_from, щоб привітати відомого VIP на ім'я, маршрутизувати за кодом країни або відправити невідомі номери шляхом верифікації, перш ніж станеться щось інше.

Як змінні встановлюються

ДжерелоПриклад
Значення за замовчуванням (оголошені на панелі Variables)escalated = false встановлено до початку дзвінка
Gather inputГолосова відповідь абонента захоплюється в змінну ноди
Update stateВи записуєте значення (літерал або композиція з {{tokens}}) безпосередньо
Результат Tool / IntegrationУся відповідь зберігається під ім'ям ноди; якщо відповідь — JSON-об'єкт, кожне поле верхнього рівня теж стає окремою змінною
Return із SubagentТе, чим subagent фіналізує, зберігається в return-змінну ноди subagent

Читання змінних — {{tokens}}

Усюди, де можна писати текст у ноді — Agent-промпт, Message-текст, Gather-промпт, URL / body / headers у Tool, номер у Phone transfer, значення в Update state, значення умов — можна вставити {{variable}}, і воно підставиться в рантаймі.

Шляхи з крапкою теж працюють для вкладених даних — наприклад, якщо Tool-відповідь була {"customer": {"name": "Anna", "tier": "gold"}}, можна читати {{customer.name}} або {{customer.tier}}.

Невідомі токени залишаються видимими

Якщо токен посилається на неіснуючу змінну, літеральний текст {{name}} лишається як є (не очищається). Це навмисно — робить зламані шаблони легко помітними в test call, замість того щоб тихо їх ковтати.


Поширені патерни

Кваліфікація → Розгалуження → Маршрутизація

Start
└─ Agent (greeting + qualify)
└─ Gather input (intent)
└─ Condition: intent == "sales" → Agent (sales)
└─ Condition: intent == "support" → Subagent (triage)
└─ Always (catch-all) → Message "Let me connect you" → Phone transfer

Пошук → Персоналізація

Start
└─ Tool (CRM lookup, writes is_known, name, tier)
└─ Condition: is_known == true → Agent (warm greeting with {{name}})
└─ Always (else) → Agent (cold greeting)

Повторно використовуваний хелпер (side-trip Subagent)

Agent (main conversation)
└─ AI decides: "Caller mentions an address" → Subagent (address collector)
└─ on finish: result = full_address
└─ Agent continues with {{full_address}}

Що заблоковано під час workflow-дзвінка

Деякі значення за замовчуванням змінюються, коли дзвінок керується графом:

  • Мова заблокована на тій, що використовується першим агентом workflow. AI не може змінити мову посеред дзвінка. Це запобігає тому, щоб модель з'їхала не на ту мову на галасливому ході.
  • Основний промпт агента замінюється промптом активної ноди. Це правило «граф володіє персоною» — див. warning під Agent.
  • Перше повідомлення приходить з greeting вхідної ноди, а не з поля «Begin Message» агента.

Захист від циклів — Step Budget

Кожен workflow має максимальне число переходів на дзвінок (за замовчуванням 25). Щоразу, коли граф переходить до нової ноди, лічильник зменшується на одиницю. Коли доходить до нуля, workflow перестає стрибати між нодами, щоб запобігти розрослим циклам.

Для цього випадку можна вибрати fallback-ноду (зазвичай Phone transfer або End call) — дзвінок відхиляється туди, як тільки бюджет вичерпано. Інакше AI повертає собі контроль, і граф фактично застигає на решту дзвінка.

Про це дуже рідко доводиться думати — це страховка для графів, які випадково зациклюються. Якщо ви потрапили в це за звичайного користування, скоріше за все десь у вас цикл.


Тестування

Кнопка Test Call у редакторі відкриває браузерний дзвінок з поточним draft workflow. Поки дзвінок іде, світний світлячок рухається між нодами на полотні, щоб ви бачили, де саме зараз дзвінок. Редактор заблоковано на час test call, щоб зміни не розсинхронізувалися з живим станом.

Використовуйте Test Call, щоб перевірити:

  • Ваші умови збігаються зі значеннями, які ви очікуєте (дивіться, чи не перестрибує світлячок гілку, яку ви думали запустити).
  • Ваші токени підставляються правильно (слухайте зависле {{name}}, якщо значення ще не було встановлено).
  • Збої інструментів деградують вишукано (ваш fallback-маршрут дійсно спрацьовує).

Збої, про які варто знати

СитуаціяЩо відбувається
Виклик Tool / Integration впавГраф іде далі без даних. Ваші наступні умови мають обробляти відсутню змінну.
Phone transfer не відбувся (неправильний номер, немає відповіді, не налаштовано телефонне підключення)Граф відкочується, поточний агент залишається на лінії, і розмова триває як звичайно.
Subagent не запустивсяБічна гілка скасовується, батьківський агент залишається на лінії, вимовляється коротка фраза про збій.
{{missing_variable}} у текстіЗалишається літералом у виводі — легко помітити під час test calls.
Нода Sub-workflowЗараз проходить повз, нічого не роблячи. Поки не покладайтеся на неї.
Step budget вичерпаноВідхиляється на fallback-ноду, якщо задана, інакше AI повертає собі контроль.

Коли НЕ використовувати Workflow

Workflows потужні, але не завжди правильна відповідь для кожного агента. Залиштесь з одним промптом, коли:

  • Розмова відкрита («відповідати на питання абонента про наші продукти»).
  • У вас немає чіткої логіки розгалуження — більшість рішень — це судження, з якими AI добре справляється.
  • Ви б написали лише одну Agent-ноду й одну End call — це просто промпт із зайвими кроками.

Переходьте на workflow, коли:

  • Можете накидати дзвінок як блок-схему з трьома чи більше чіткими етапами.
  • Потрібне хоча б одне детерміноване розгалуження за змінною (Condition).
  • Хочете повторно використати шматок розмови між кількома агентами (subagent).
  • Уже накопичуєте правила «якщо абонент каже X, тоді роби Y» у промпті, і вони ненадійні.