Коротко: агент для Business Central складається з п'яти компонентів, і жоден із них не є моделлю в цікавому сенсі. Модель — замінна частина. Цінність і ризик зосереджені в шарі інструментів, моделі доступу й журналюванні.
П'ять компонентів
Мінімальна робоча конфігурація виглядає так. Кожен компонент можна замінити, не переписуючи решту, — і саме це й є ознака того, що архітектура вибрана правильно.
- Точка входу. Те, звідки приходить завдання: інтерфейс чату, кнопка на сторінці Business Central, розклад, подія в системі, лист. Часто їх кілька.
- Оркестратор. Виконує цикл агента: тримає мету, історію кроків, ліміти, вирішує, коли зупинитися. Це ваш код, і саме тут живе логіка процесу.
- Модель. Обирає інструмент і формує параметри. Замінна: перехід з однієї моделі на іншу не має вимагати переписування решти.
- Шар інструментів. Перелік дозволених операцій із перевіркою параметрів. Автентифікується в Business Central. Найважливіший компонент з погляду безпеки — детально про його реалізацію на сторінці про MCP і шар інтеграції.
- Сховище стану й журналу. Що агент робив, коли, з яким результатом, що людина відхилила.
Компонент 5 у першій версії пропускають частіше за інші, і це помилка, яку помічають пізно. Без журналу неможливо ані розібрати інцидент, ані відповісти на питання, чи готовий процес до підвищення рівня автономності.
Де що розгортається
Три робочі варіанти, і вибір між ними майже завжди диктується політикою щодо даних, а не технікою.
| Варіант | Де компоненти | Дані назовні | Кому підходить |
|---|---|---|---|
| У вашому тенанті Azure | Усе у вас, модель через Azure OpenAI | Не залишають тенант | Жорсткі вимоги до даних |
| Змішаний | Оркестратор і інструменти у вас, модель — API провайдера | Тільки те, що в запиті | Більшість компаній |
| Керований підрядником | Усе в підрядника | Залежить від договору | Малі впровадження |
Другий варіант — типовий компроміс. Ключове в ньому: назовні йде рівно те, що потрапило в запит, а це визначається проєктуванням операцій, а не вибором провайдера. Операція, що повертає три потрібні рядки, безпечніша за ту, що віддає таблицю й лишає моделі відфільтрувати.
Третій варіант дешевший на старті й створює залежність. Якщо обираєте його, домовляйтеся про передачу компонентів на початку, а не тоді, коли захочете змінити підрядника.
Обліковий запис і доступ
Найважливіше архітектурне рішення й те, яке найдорожче переграти.
Сервісний обліковий запис. Агент працює під одним технічним записом Business Central із фіксованим набором дозволів. Просто реалізувати, передбачувано в поведінці. Наслідок: усі бачать однаковий зріз даних, і розділити доступ за ролями всередині агента вже не вийде.
Делегований доступ. Агент діє від імені того, хто поставив завдання. Кожен бачить своє, журнал показує реальну людину. Складніше, але для більшості компаній правильно — і, головне, це не те, що додається пізніше невеликою доробкою.
Незалежно від варіанта: окремий набір дозволів під агента, а не копія ролі бухгалтера. І окремий обліковий запис на кожного агента, якщо їх кілька, — інакше журнал змін не відповість, хто саме що зробив. Ширший контекст — у матеріалі про права користувачів.
Стан і журнал
Дві різні речі, які часто плутають.
Стан потрібен, щоб агент знав про свої попередні запуски: кому вже надсилали нагадування цього тижня, які позиції вже перевіряли. Між запусками агент за замовчуванням не пам'ятає нічого, тому пам'ять роблять явно — або записом у Business Central (наприклад, дата останнього контакту в картці), або окремим сховищем.
Перший спосіб кращий там, де він можливий: дані лишаються в системі, видимі людям і переживають заміну агента. Друге сховище заводять тільки під те, чому немає місця в Business Central.
Журнал потрібен для розбору й для рішень. Мінімальний набір: завдання, послідовність викликів із параметрами, результати, підсумок, реакція людини. Остання позиція найважливіша й найчастіше відсутня — без неї немає відповіді на питання, чи працює агент добре.
Середовища
Правило одне: у агента має бути стільки середовищ, скільки у вашого Business Central, і вони мають бути пов'язані.
- Пісочниця. Розробка й перевірка. Обов'язково окремі облікові дані — не ті самі, що в продуктиві.
- Продуктив. Свої ключі, свій обліковий запис, свій перелік дозволених операцій.
Дві типові помилки. Перша: конфігурацію пісочниці випадково розгортають у продуктив — очевидна проблема рівно до того моменту, поки вона не трапляється. Друга тонша: пісочниця має нереалістичний обсяг даних, тому запит, який там виконується миттєво, у продуктиві впирається в час очікування, а агент інтерпретує це як «даних немає». Тестувати треба на реалістичних обсягах.
Оновлення Business Central
Business Central оновлюється двічі на рік, і агент — така сама інтеграція, як будь-яка інша.
Рішення, побудовані на стандартному API, релізи переживають: їх треба перевіряти, а не переписувати. Це кілька годин на прогін ключових сценаріїв у пісочниці з новою версією до того, як оновлення дійде до продуктиву.
Рішення, що читають недокументовані внутрішні структури, релізи не переживають — і це головна причина лишатися на опублікованих ендпоїнтах, навіть коли обхідний шлях виглядає швидшим. Якщо потрібних даних у стандартному API немає, правильна відповідь — опублікувати власну API-сторінку на AL, а не обходити. Про межу доробок — у матеріалі коли AL виправданий.
Чотири рішення, які дорого змінювати
Решту в архітектурі агента можна переграти без болю. Ці чотири — практично ні, тому їх варто обговорити на discovery, а не залишати «на потім».
- Модель автентифікації. Перехід із сервісного запису на делегований доступ — це переробка інтеграції, а не налаштування.
- Де живе стан. Перенесення з окремого сховища в Business Central означає міграцію накопичених даних.
- Гранулярність операцій. Кілька широких інструментів замість багатьох вузьких — це рішення, яке визначає і безпеку, і поведінку агента. Переробляти доводиться разом із тестуванням.
- Хто хостить. Переїзд від підрядника до себе можливий, але дешевше домовитися про це до старту, ніж після.
Практична порада: попросіть підрядника описати ці чотири пункти письмово до початку робіт. Якщо відповіді розпливчасті, це найкращий момент це виявити. Що з цього складається у вигляді послуги — на сторінці AI-агенти для Business Central.
Часті запитання
Чи можна замінити модель після запуску?
Так, якщо архітектура правильна: модель має бути замінною частиною, а логіка процесу жити в оркестраторі й шарі інструментів. Якщо заміна моделі вимагає переписування рішення, це ознака того, що логіка розповзлася по промптах.
Де краще зберігати стан агента?
Там, де можливо — у самому Business Central: дата останнього контакту, позначка в картці. Дані лишаються видимими людям і переживають заміну агента. Окреме сховище заводять тільки під те, чому немає місця в системі.
Скільки середовищ потрібно?
Стільки, скільки у вашого Business Central, зазвичай два. З окремими обліковими даними для кожного. І пісочниця має мати реалістичний обсяг даних, інакше проблеми з часом очікування виявляться вже в продуктиві.
Що робиться перед оновленням Business Central?
Прогін ключових сценаріїв агента в пісочниці з новою версією. Це кілька годин, якщо рішення побудоване на стандартному API. Якщо воно читає недокументовані структури, це може бути переробка — тому такого підходу й уникають.
Чи можна почати з хостингу в підрядника й перейти до себе?
Можна, але умови передачі варто зафіксувати до старту, а не тоді, коли виникне потреба. Йдеться про доступ до коду, конфігурації й накопиченого стану.
Наскільки складно додати другого агента?
Значно простіше за першого: шар інструментів, автентифікація й журналювання вже є. Додається логіка нового процесу й, за потреби, нові операції. Це головна причина будувати перший агент вузьким, але акуратно.