Як впроваджувати AI-агенти для роботи з мільйонами клієнтів – 5 принципів, що підійдуть бізнесам

AI перестає бути «пілотним проєктом» і стає частиною інфраструктури компанії, коли починає ухвалювати рішення, які раніше ухвалювали люди – і робить це швидше, дешевше або одночасно і швидше, і дешевше.

Як оркеструвати AI-агентів для 240 мільйонів клієнтів. Фото: Іван Добровольський

Я працюю з AI-агентами для supply chain у Walmart – конкретно над автоматизацією кампаній та асортиментного планування. Якщо раніше site merchandiser витрачав дні або тижні, щоб вручну зібрати асортимент із тисячі товарів для кампанії, то зараз AI-агент робить це за кілька годин. І йдеться не про чернетку, яку потім переробляють, а про production-ready асортименти, які мерчандайзер рев’ює і затверджує.

Але ось що важливо: штучний інтелект стає інфраструктурою не тоді, коли компанія запускає один бот. А тоді, коли їх десятки і вони мають працювати разом. Тож падіння одного ламає процес для мільйонів клієнтів. Щотижня Walmart обслуговує 240 мільйонів людей у 19 країнах. Тому це не середовище для експериментів – це production із нульовою толерантністю до помилок.

Найбільша помилка: «AI навчений на наших даних»

Найпоширеніше хибне уявлення про enterprise AI-агентів – що агенти «навчені на даних компанії», адже побудовані на фундаментальних моделях. Але це не так.

GPT-4, Claude, Gemini – це загальні моделі, натреновані на публічних даних. Вони нічого не знають про конкретну компанію, її клієнтів чи бізнес-правила.

Всю необхідну інформацію ви передаєте з кожним промптом у контекстне вікно. Кожен запит до моделі – це повний пакет, який включає інструкції, правила, релевантні дані, історію попередніх кроків. Модель не «пам’ятає» – це ви щоразу нагадуєте їй, що робити.

Тут вступає RAG – Retrieval-Augmented Generation. Замість того щоб запихати все у промпт, система витягує з бази даних лише релевантну інформацію. Це можуть бути конкретні товари, вибрані правила для конкретної категорії, історія попередніх рішень. Векторні бази даних індексують ці знання, і так агент отримує саме те, що потрібно для поточного кроку.

З цього випливають два ключові технічні виклики: вартість токенів і галюцинації.

Контекстне вікно коштує грошей. Кожен токен, відправлений моделі, – це гроші. На масштабі сотень мільйонів запитів різниця між 4 000 і 40 000 токенами у промпті – це різниця в мільйонах доларів на рік. Тому оптимізація контексту – не nice-to-have, а необхідність.

Є кілька технік управління контекстом:

• Sliding window – зберігання лише N останніх кроків розмови;
•  Summarization – стиснення довгих діалогів у короткі зведення; Episodes – розбиття складних задач на окремі епізоди з чітким контекстом;
• окремо виділяють також short-term memory (контекстне вікно поточної сесії) і long-term memory (критичну інформацію, збережену окремо і підтягнуту через RAG).

Але найважливіший архітектурний принцип – підтримка O(1), тобто константного контекстного вікна. Якщо асортимент містить 100 товарів або 100 000 товарів, LLM ніколи не отримує список усіх товарів. Натомість агент формулює набір правил або агрегацій, які виконуються детерміністично. Модель міркує про стратегію, а не перебирає дані, тобто створює план дій замість шукати збіги в тому масиві інформації, який має.

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

Три стовпи агента: reasoning, execution, synthesis

Архітектуру ефективного AI-агента я б писав як систему з трьох стовпів.

• Перший стовп – Reasoning (імовірний). Це те, що робить LLM: аналізує контекст, формулює стратегію, вирішує, який наступний крок. Наприклад: «Для цієї кампанії потрібні товари з маржею вище 15% у категоріях, які є трендовими за останній місяць». Це природна мова, імовірнісний процес, і тут можуть бути галюцинації.
• Другий стовп – Execution (детерміністичний). Тут LLM не залучена. Агент виконує конкретні дії: запит до бази даних, виклик зовнішнього API, агрегація даних, арифметичні обчислення, комунікація з іншими сервісами через MCP. Це rule-based, передбачуване, перевірене. Зважайте на те, що AI погано рахує. Арифметика, агрегації, статистика – це завдання для коду, не для моделі.
• Третій стовп – Synthesis (формування результату). Агент бере результати детерміністичного виконання і формує зрозумілу відповідь для користувача. LLM знову залучена, але працює з верифікованими даними, а не з уявою.

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

Пам’ять агента: short-term, long-term і episodes

Один із найскладніших аспектів роботи з AI-агентами – управління пам’яттю. LLM не має власної пам’яті між викликами. Кожен запит – це чистий аркуш. Все, що агент «знає», – це те, що інженери явно передали в контекстне вікно. Тому архітектура пам’яті – це повністю відповідальність розробників.

В production зазвичай використовують три типи пам’яті.

• Short-term memory – контекстне вікно поточної сесії. Це те, що LLM бачить прямо зараз: поточний промпт, останні кроки діалогу, релевантні дані. Вони обмежені розміром контекстного вікна моделі і бюджетом на токени. Техніка sliding window дозволяє зберігати лише N останніх кроків, відкидаючи старіші.
• Long-term memory – критична інформація, збережена за межами сесії. Це факти, які агент має «пам’ятати» між сесіями: вподобання користувача, результати попередніх кампаній, вивчені правила. Long-term memory зберігається окремо у векторній базі даних або key-value store і підтягується через RAG, коли це відповідає поточному запиту. Агент не «пам’ятає» – він щоразу шукає відповідь в зовнішньому сховищі.
• Episodes – розбиття складних задач на ізольовані етапи. Коли задача занадто велика для одного контекстного вікна (наприклад, повне асортиментне планування кампанії з десятками категорій), вона розбивається на епізоди. Кожен епізод має власний контекст, виконується незалежно, а між епізодами передається лише стислий summary попереднього результату. Це дозволяє працювати з задачами будь-якої складності, не роздуваючи контекстне вікно.

Додатково використовується summarization. Коли накопичена історія стає занадто довгою, вона стискається до ключових фактів і рішень. Це компроміс, за якого втрачаються деталі, але зберігається  загальний контекст за фіксованої кількості токенів.

Навіщо потрібні всі ці техніки? Відповідь проста – вони повинні підтримувати той самий принцип O(1) контекстного вікна. Незалежно від того, наскільки складна задача або як довго працює агент, розмір промпту залишається контрольованим і передбачуваним.

Оркестрація: як агенти спілкуються між собою

Насамперед варто уточнити, що A2A (Agent-to-Agent) від Google – це не окремий мережевий протокол. Це стандарт комунікації, побудований на технологіях, що вже існують, – HTTP, JSON-RPC, Server-Sent Events. Він визначає, як агенти знаходять один одного (Agent Cards), домовляються про можливості й делегують задачі. A2A доповнює MCP (Model Context Protocol) від Anthropic, який стандартизує доступ агентів до інструментів і даних.

Але протокол – це лише контракт. Під капотом потрібен реальний транспорт. На масштабі Walmart це Apache Kafka для асинхронної комунікації між агентами, Apache Cassandra як швидке сховище стану агентів, а для складніших data pipelines – Apache Beam і Google Cloud Dataflow.

Для прототипування та швидкого тестування ідей Google Cloud  добре працює такий стек:

• Vertex AI для ML-експериментів, B
• igQuery для аналітики,
• Dataflow для потокової обробки.

На рівні фреймворків варто звернути увагу на два open-source інструменти:

• LangGraph – це бібліотека від LangChain для побудови stateful мультиагентних графів із підтримкою циклів, умовних переходів і human-in-the-loop;
• Google Agent Development Kit (ADK) – open-source фреймворк від Google (не плутайте з Vertex AI – ADK є окремою бібліотекою), який нативно підтримує A2A і спрощує побудову агентів, їхнє тестування та деплой. Обидва інструменти значно знижують поріг входу для команд, які починають працювати з агентами.

Але коли йдеться про production на масштабі сотень мільйонів клієнтів щотижня з мільярдами товарних позицій, то фреймворки для прототипування не завжди витримують. Тут потрібна інфраструктура, яка тримає навантаження.

І ось що нині мало обговорюють: Python залишається лідером в AI-світі, але агенти та MCP-сервери у великому enterprise все ще віддають перевагу мультипоточним мовам. Walmart – це Java-компанія. Python чудово підходить для ML-досліджень і прототипів, але коли конкурентних запитів сотні мільйонів, GIL (Global Interpreter Lock) стає реальним обмеженням. Java тримає production-навантаження без компромісів.

Які головні виклики впровадження на масштабі

Я б назвав чотири головні виклики:

• Оркестрація. Коли десятки агентів залежать один від одного, одне повільне рішення каскадно впливає на все. Потрібен чіткий orchestration layer із таймаутами, fallback-стратегіями і circuit breakers.
• Масштабованість. Наприклад, навантаження на Walmart нелінійне – воно стрибає в 10–50 разів під час Black Friday, Різдва, back-to-school. Агентна інфраструктура повинна масштабуватися горизонтально без деградації якості відповідей.
• Governance. Хто відповідає за неправильні рішення агента? Потрібен audit trail кожного кроку: який контекст отримав агент, яке рішення ухвалив і чому. Без observability мультиагентна система – це чорна скринька.
• Вартість. Кожен виклик LLM коштує грошей. Помножте на мільярди взаємодій – і оптимізація токенів стає бізнес-критичним завданням. Саме тому O(1) контекстне вікно і правильний вибір моделі (це не завжди має бути саме GPT-4, часто достатньо SLM) – це не оптимізація, а необхідність.

Що будь-яка компанія може адаптувати вже сьогодні

Зі свого досвіду я сформував п’ять практичних принципів, які можна використовувати в бізнесі незалежно від його масштабу.

• Рахуйте бізнес-цінність до початку розробки. Агентів створюють не тому, що це модно. Кожен з них має пройти оцінку – скільки коштує процес зараз, скільки коштуватиме з агентом, який ROI і за який період. Якщо бізнес-кейс не сходиться – агент не будується.
• Розділяйте reasoning, execution і synthesis. Це працює на будь-якому масштабі. Навіть для одного агента внутрішнього інструменту ніколи не давайте LLM генерувати дані. Він міркує і формулює, а факти приходять із бази.
• Тримайте контекстне вікно константним. Не масштабуйте промпт лінійно з даними. Якщо каталог зростає з 1 000 до 100 000 позицій, промпт не повинен зростати пропорційно. Агент має працювати через правила й агрегації, а не через перелік.
• Обирайте правильну модель для задачі. Не кожна задача потребує GPT-4. Для класифікації, роутингу, простого reasoning – SLM на 7B параметрів часто достатньо і коштує в 10–100 разів менше. Гібридний підхід – легка модель для рутини, важка для складних випадків – це те, що використовує Big Tech.
• Інвестуйте в якість, а не в кількість. Користувачі ненавидять AI slop і галюцинації. Один надійний агент, який розв’язує конкретну проблему, коштує більше, ніж десять, які «загалом допомагають».

Коли ж мультиагентні екосистеми стануть стандартом? У великих компаніях це відбувається вже. У середніх бізнесів, на мій погляд, є ще 2-3 роки для адаптації. До речі, інструменти на кшталт LangGraph, Google ADK і Vertex AI значно знижують поріг входу.

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