Коротко: так, агент може писати в Business Central через MCP — але тільки ті операції, які ви явно спроєктували й дозволили. Загального права запису не існує. Уся складність не в дозволі, а в поведінці системи при повторах, часткових невдачах і помилках зв'язку.
Коротка відповідь
MCP-сервер віддає моделі перелік операцій. Серед них можуть бути такі, що змінюють дані: створити замовлення, оновити поле, подати запит на погодження. Модель обирає операцію, сервер перевіряє параметри й виконує виклик до Business Central під обліковим записом інтеграції.
Тобто питання «чи може агент писати» насправді розпадається на три:
- Чи є така операція в переліку? Якщо ні — не може, і жодне формулювання запиту цього не змінить.
- Чи має обліковий запис відповідні права? Якщо ні — Business Central відмовить.
- Чи не вимагає ця дія погодження? Якщо вимагає — запит піде в той самий процес, що й людський.
Три незалежні шари, і кожен тримає окремо. Детальніше про модель захисту — у розборі безпеки MCP.
Як виглядає правильна операція запису
Тут проходить межа між робочим рішенням і небезпечним. Три правила.
Вузько, а не універсально. Не «оновити картку клієнта», а «оновити дату останнього контакту». Перше дозволяє змінити кредитний ліміт, друге — ні, і це обмеження діє в коді, а не в надії на розсудливість моделі.
Явні параметри з перевіркою. Операція приймає визначені поля з визначеними типами й діапазонами. Сума за межами розумного, дата з майбутнього, чужий код компанії — усе це відхиляється до звернення до Business Central.
Один намір — одна операція. Спокуса зробити «створити або оновити залежно від того, чи існує запис» велика й погана: модель не завжди розуміє, що саме сталося, а журнал стає нечитабельним. Краще дві операції, кожна з передбачуваним результатом.
Повтори: головна технічна проблема
Найважливіший розділ, і його майже не обговорюють у матеріалах про AI.
Сценарій: агент викликає «створити замовлення закупівлі», Business Central створює його, але відповідь губиться через мережу. Агент вважає, що виклик не вдався, і повторює. Тепер у вас два однакові замовлення.
Це не гіпотеза — це нормальна поведінка розподілених систем, і вона трапляється тим частіше, чим більше операцій виконує агент. Три способи впоратися:
- Ключ ідемпотентності. Операція приймає унікальний ідентифікатор наміру. Повторний виклик із тим самим ключем повертає результат першого, а не створює новий запис. Найнадійніший спосіб.
- Перевірка перед створенням. Операція спершу шукає запис із такими ознаками й повертає його, якщо знайшла. Простіше, але має свої граничні випадки.
- Заборона автоматичного повтору для операцій запису. При невизначеній відповіді агент не повторює, а зупиняється й повідомляє. Найпростіше й достатньо для більшості сценаріїв рівня «підготувати чернетку».
Якщо в описі архітектури підрядника немає жодного з цих трьох підходів, це слабке місце, яке проявиться не одразу.
Часткові невдачі
Друга ситуація, яка визначає, придатне рішення до продуктиву чи ні.
Агент мав створити двадцять записів. Сімнадцять створилися, три ні. Що далі?
Неправильна поведінка: зупинитися й повідомити про помилку, лишивши сімнадцять у системі без згадки про них. Людина побачить «не вдалося» й не знатиме, що більшість роботи виконана.
Правильна: завершити по тих, де вдалося, і окремо повідомити, які саме три не пройшли й чому. Тоді результат зрозумілий і виправний.
Окреме питання — чи потрібна транзакційність «усе або нічого». У більшості сценаріїв, де агент готує роботу, вона не потрібна й лише додає складності. Вона потрібна там, де записи мають сенс тільки разом — але такі сценарії зазвичай і не віддають агенту в першу чергу.
Що не віддають узагалі
Перелік короткий і твердий — не через технічні обмеження, а тому що ціна рідкісної помилки перевищує суму вигоди від усіх правильних спрацювань.
- Проведення документів у фінансових сценаріях. Сторнування лишається в аудиторському сліді назавжди.
- Платежі назовні. Агент готує пропозицію, людина виконує.
- Зміна кредитних лімітів і цінових умов. Комерційні рішення з прямим фінансовим ризиком.
- Закриття періоду. Тут зовнішня відповідальність.
- Видалення записів. Практично ніколи: майже завжди достатньо позначки, а видалення необоротне.
Розгорнуто про рівні самостійності — у статті про автономні AI-агенти.
Дозволи як остання межа
Найнадійніший запобіжник реалізується не кодом, а налаштуванням: набір дозволів облікового запису без права проведення для фінансових сценаріїв.
Він працює незалежно від того, наскільки добре спроєктований ваш сервер і як поводиться модель. Якщо права немає, платформа відмовить. Це єдиний шар, який не залежить від якості вашої роботи, — і тому його ставлять першим.
Плюс окремий обліковий запис на кожного агента: інакше журнал змін не відповість, хто саме створив запис. Питання ставлять зазвичай тоді, коли вже щось сталося.
Як це тестувати
Перевірка правильної роботи — менша частина. Ось що перевіряють обов'язково:
- Повторний виклик тієї самої операції — не створює дублікат.
- Виклик операції, якої немає в переліку — відмова, без пошуку обхідного шляху.
- Операція поза набором дозволів — Business Central відмовляє, помилка обробляється.
- Часткова невдача — результат по успішних, окреме повідомлення про решту.
- Параметри поза діапазоном — відхиляються до звернення до Business Central.
- Аномальний обсяг — тисяча записів замість звичних двадцяти зупиняє процес.
- Обрив зв'язку посеред операції — стан системи лишається зрозумілим.
Що зробите самі
Рішення про те, які операції взагалі дозволені, — ваше й тільки ваше: це питання політики, а не техніки. Набір дозволів без права проведення теж налаштує ваш адміністратор швидше за зовнішнього підрядника.
Складна частина — проєктування операцій запису з урахуванням повторів і часткових невдач. Це небагато коду, але це той код, де помилки виявляються через місяці й у формі дублікатів у базі.
Орієнтир: AI Discovery від $750 із письмовою рекомендацією щодо архітектури; агент із операціями запису від $6 000, під конкретний бізнес-процес від $10 000. Різниця з асистентом майже повністю в тестуванні.
Часті запитання
Чи може агент випадково видалити дані?
Тільки якщо ви створили операцію видалення й дали відповідні права. Ми таких операцій практично ніколи не робимо: майже завжди достатньо позначки про неактуальність, а видалення необоротне.
Що станеться при обриві зв'язку посеред запису?
Це головна технічна проблема запису, і вирішується вона ключем ідемпотентності або забороною автоматичного повтору для операцій запису. Якщо жодного з підходів немає, повторний виклик створить дублікат.
Чи потрібна транзакційність «усе або нічого»?
У більшості сценаріїв, де агент готує роботу, — ні, вона лише додає складності. Вона потрібна там, де записи мають сенс тільки разом, але такі процеси зазвичай і не віддають агенту першими.
Чи обходить агент процеси погодження?
Ні. Якщо дія вимагає погодження за вашими налаштуваннями, запит агента йде в той самий процес. Це забезпечує платформа, а агент виступає просто ще одним заявником.
Як зрозуміти, що запис зробив агент, а не людина?
З журналу змін, за умови що в агента власний обліковий запис. Під спільним сервісним записом розділити дії постфактум складно, і вирішувати це треба при проєктуванні.
Чи можна дозволити запис поступово?
Так, і це правильний підхід: почати з операцій, які створюють непроведені документи, подивитися місяць на частку відхилень, і тільки потім розширювати перелік.