У Лондоні команда платформи Braintrust разом із інженерами Trainline провела практичний воркшоп про те, як будувати складні, багатокрокові AI-застосунки, які реально працюють у продакшені. Центральним прикладом став агент тріажу звернень у підтримку для вигаданого застосунку — не «іграшковий чат-бот», а повноцінний конвеєр із кількох етапів, який можна інструментувати, тестувати й поступово посилювати.
Цей матеріал розбирає саме цей приклад і розробницький стек воркшопу: як влаштований пайплайн тріажу, які інструменти потрібні учасникам, як організований код на Node.js і як Git-теги перетворюють навчання на серію контрольованих чекпойнтів.
Фіктивний застосунок, реальні проблеми: навіщо агент тріажу підтримки
Організатори воркшопу поставили перед учасниками завдання, яке дуже схоже на те, з чим стикаються продуктові команди у великих компаніях. Потрібно побудувати агента, який обробляє звернення користувачів до служби підтримки: збирає контекст, класифікує запит, перевіряє політики, формує відповідь і вирішує, чи треба ескалювати кейс людині.
Сценарій свідомо зроблено фіктивним, щоб уникнути обмежень реальних даних і конфіденційності. Але структура задачі — максимально наближена до продакшену. Це не просто один виклик LLM із довгим промптом, а багатоступеневий workflow, де кожен крок має свою відповідальність і може окремо спостерігатися та оцінюватися.
Такий вибір прикладу показовий. Більшість команд уже вміють зробити «демо», яке працює на ноутбуці: один запит до моделі, вражаюча відповідь, кілька вдалих сценаріїв. Проблеми починаються, коли це потрібно перетворити на сервіс, який щодня обробляє тисячі реальних звернень, підкоряється політикам компанії, не «ламається» від рідкісних кейсів і дає змогу зрозуміти, що саме пішло не так, коли щось ламається.
Агент тріажу підтримки у воркшопі виконує роль навчального полігону для всіх цих викликів. Він достатньо простий, щоб учасники могли його зібрати за одну сесію, але водночас достатньо складний, щоб продемонструвати, як виглядає реалістичний, багатокроковий AI-конвеєр.
Усередині пайплайна: п’ять етапів, які можна вимірювати окремо
Ключова ідея воркшопу — розбити роботу агента на чіткі стадії. Замість одного «магічного» промпта, який має робити все, пайплайн тріажу підтримки складається з кількох послідовних кроків. Кожен із них можна логувати, трасувати, тестувати й покращувати незалежно.
Перший етап — збирання контексту. Агент не повинен відповідати, спираючись лише на текст звернення користувача. Йому потрібні дані про акаунт, історію замовлень, попередні тікети, можливо — статус платежів чи поїздок (у реальному застосунку на кшталт Trainline це критично). На цьому кроці система викликає локальні інструменти або API, щоб зібрати все, що може знадобитися для коректної відповіді.
Другий етап — власне тріаж. Тут агент класифікує звернення: про що йдеться, наскільки це терміново, чи є це типовим запитом або потенційною проблемою, що потребує особливої уваги. На цьому рівні можуть визначатися категорії, SLA, пріоритети черги.
Третій етап — перевірка політик. Навіть якщо модель «знає», як відповісти, компанія може мати чіткі правила: що можна обіцяти користувачеві, які компенсації дозволені, як поводитися в разі підозри на шахрайство. На цьому кроці агент співвідносить запропоноване рішення з політиками, щоб уникнути небажаних обіцянок або порушень регуляцій.
Четвертий етап — чернетка відповіді. Лише після того, як зібрано контекст, виконано тріаж і перевірено політики, агент формує текст, який потенційно отримає користувач. Тут важлива не лише коректність змісту, а й тон, структура, зрозумілість. У реальних командах цей крок часто стає полем для A/B-тестів і тонкого тюнінгу промптів.
П’ятий етап — рішення про ескалацію. Не всі кейси варто закривати автоматично. Частина звернень має йти до живого оператора: через складність, ризики, емоційний контекст або просто невпевненість моделі. На цьому кроці агент вирішує, чи відправити відповідь автоматично, чи передати її як чернетку людині, чи взагалі підняти прапорець для спеціальної групи.
Така декомпозиція робить систему схожою на класичну мікросервісну архітектуру. Замість одного монолітного промпта — набір спеціалізованих «сервісів» у межах одного агентного флоу. Це дозволяє:
по-перше, локалізувати помилки. Якщо щось пішло не так, можна подивитися, на якому етапі це сталося: контекст не зібрався, тріаж неправильно класифікував, політики не спрацювали чи відповідь сформульовано невдало.
по-друге, окремо оцінювати якість кожного кроку. Наприклад, мати золотий набір кейсів для тріажу й інший — для перевірки політик.
по-третє, еволюціонувати систему поетапно. Можна замінити модель або промпт на одному етапі, не чіпаючи інші, і відстежити, як це вплинуло на загальну якість.
Саме навколо такого пайплайна й побудовано практичну частину воркшопу.
Інфраструктура воркшопу: Slack, Braintrust, OpenAI та GitHub
Щоб учасники могли пройти весь шлях від коду до спостережності, організатори побудували доволі чіткий набір вимог до середовища.
Перший крок — комунікація. Учасників просять приєднатися до організації AI Engineer у Slack і зайти в публічний канал ai-engineer-europe-2026-braintrust-workshop. Саме там пропонують ставити запитання, ділитися проблемами з налаштуванням середовища й отримувати допомогу від команди Braintrust і Trainline. Для живого воркшопу це критично: коли десятки людей одночасно намагаються запустити один і той самий стек, завжди знаходяться ті, у кого щось не працює через локальні особливості.
Другий крок — облікові записи й ключі. Щоб виконувати вправи повністю, учасникам потрібно зареєструвати безкоштовний акаунт у Braintrust. Платформа використовується як «хребет» спостережності й оцінювання: через неї проходять трейси агентного флоу, там же можна дивитися, як поводиться система на різних етапах.
Крім того, потрібен ключ OpenAI API. Саме через нього воркшопний код звертається до моделей, які виконують окремі кроки пайплайна тріажу. Без цього ключа можна хіба що переглядати код, але не запускати повноцінні сценарії.
Третій крок — вихідний код і документація. Організатори надають GitHub-репозиторій із усіма активами, які використовуються під час сесії. До нього додається покроковий «cheat sheet» — інструкція, яка дозволяє не загубитися в деталях. Якщо хтось відстав на одному з етапів, він може за інструкцією швидко наздогнати групу, не витрачаючи час на здогадки.
Такий набір інструментів перетворює воркшоп із пасивної лекції на справжню лабораторну роботу. Учасники не просто дивляться на слайди, а заходять у термінал, запускають команди, дивляться в UI Braintrust, спостерігають за тим, як їхній агент тріажу поводиться на реальних запитах.
Node.js 22, pnpm і make: чому стек має значення
Окремої уваги заслуговує вибір технологічного стека. Кодова база воркшопу побудована навколо Node.js версії 22. Це сучасна гілка платформи, яка дає змогу використовувати актуальні можливості JavaScript і водночас достатньо стабільна для серйозних застосунків.
Для керування залежностями використовується pnpm. На відміну від класичного npm, pnpm агресивно реюзує пакети через жорсткі посилання, що робить інсталяцію швидшою й економнішим використанням диску. Для воркшопу, де десятки учасників одночасно клонують репозиторій і ставлять залежності, це зменшує час очікування й кількість проблем.
Над усім цим — make як обгортка для типових команд. Замість того, щоб кожен учасник запам’ятовував довгі рядки з npm-скриптами або параметрами CLI, організатори пропонують прості цілі на кшталт make install, make run чи make test (конкретні назви в інструкції). Це вирівнює досвід між різними операційними системами й shell-середовищами: незалежно від того, чи працює людина на macOS, Linux або Windows, вона викликає ті самі make-команди.
Такий підхід знімає значну частину «тертя» на рівні інфраструктури. Замість того, щоб витрачати пів воркшопу на боротьбу з версіями Node.js, різними пакетними менеджерами й дрібними відмінностями в командах, учасники можуть зосередитися на тому, як влаштований сам агент тріажу й як його спостерігати через Braintrust.
Git-теги як чекпойнти: як не загубитися в багатокроковому флоу
Ще один важливий елемент воркшопної архітектури — використання Git-тегів для позначення ключових етапів. Кожна велика стадія побудови агента має свій тег у репозиторії. Це означає, що в будь-який момент учасник може виконати git checkout на конкретний тег і отримати «еталонну» реалізацію на цьому кроці.
Для навчання це вирішує одразу кілька проблем.
По-перше, знімає страх помилитися. Якщо хтось зіпсував локальний код, заплутався в конфліктах або випадково видалив важливий файл, завжди є можливість повернутися до відомо робочого стану, просто переключившись на відповідний тег.
По-друге, дозволяє приєднатися до воркшопу на будь-якому етапі. Якщо учасник запізнився або змушений був відволіктися, він може пропустити кілька кроків ручного редагування коду й одразу перейти до потрібного чекпойнта, не перериваючи загальний темп групи.
По-третє, створює чітку ментальну карту прогресу. Кожен тег відповідає певному концептуальному кроку: від базового «single-shot» промптингу до додавання локальних інструментів, впровадження спеціалізованих стадій агентного флоу, інструментування й оцінювання. Це допомагає учасникам не лише виконати вправи, а й зрозуміти логіку еволюції системи.
У результаті Git перестає бути просто системою контролю версій і перетворюється на навчальний навігатор, який веде розробника через усі стадії побудови складного AI-застосунку.
Воркшоп як модель продакшену: від локального коду до спостережності
Хоча цей матеріал зосереджується на самому агенті тріажу й стеку інструментів, важливо розуміти, як усе це вписується в ширший задум воркшопу.
Організатори прямо говорять про розрив між прототипами й продакшеном. У багатьох компаніях є успішні POC на базі генеративних моделей, які так і не доходять до реальних користувачів. Причина не в тому, що моделі «недостатньо розумні», а в тому, що операційна дисципліна навколо них не встигає за швидкістю експериментів.
Агент тріажу підтримки у воркшопі побудований так, щоб змусити учасників мислити категоріями продакшену вже на етапі навчання. Розбиття на стадії, чіткі інтерфейси між ними, можливість інструментувати кожен крок, наявність золотих наборів для оцінювання, використання платформи спостережності — усе це елементи, без яких реальний сервіс підтримки на базі LLM швидко перетворився б на некерований «чорний ящик».
Важливо й те, що воркшоп не обмежується лише кодом. Slack-канал для підтримки, покроковий cheat sheet, Git-теги як чекпойнти, вимога мати акаунт у Braintrust і ключ OpenAI — усе це моделює реальну екосистему, у якій працюють сучасні AI-команди. Вони не існують у вакуумі одного репозиторію, а взаємодіють із платформами спостережності, інфраструктурою, внутрішніми чатами підтримки й зовнішніми API.
Висновок: навчальний агент, який вчить думати як AI-інженер
Фіктивний агент тріажу підтримки, побудований на воркшопі Braintrust і Trainline, — це значно більше, ніж просто приклад коду. Це концентрована модель того, як сьогодні виглядає робота AI-інженера, який намагається довести систему з LLM від демо до продакшену.
Багатоступеневий пайплайн із чіткими стадіями, можливість інструментувати й оцінювати кожен крок окремо, використання сучасного стека на Node.js 22 із pnpm і make, Git-теги як навчальні чекпойнти, інтеграція з Braintrust і OpenAI, підтримка через Slack і детальний cheat sheet — усе це разом формує практичний шаблон, який можна перенести у власні проєкти.
У світі, де «показати демо» стало надто легко, такі воркшопи нагадують: справжня складність починається там, де потрібно зробити систему спостережуваною, керованою й здатною еволюціонувати без втрати якості. Агент тріажу підтримки — зручний спосіб навчитися цьому на безпечному полігоні, перш ніж застосовувати ті самі принципи до реальних користувачів і реальних бізнес-процесів.