Дослідники запропонували архітектурний патерн Persona-Execution Separation — опис з’явився в препринті на arXiv у серпні 2026 року (arXiv 2608.27427). Суть проста, хоч і незручна для більшості чинних агентних систем: «персона» агента — те, як він мислить, спілкується, розставляє пріоритети — і виконавчий шар, який реально діє, викликає інструменти, пише файли, ініціює транзакції, мають жити в окремих контурах, а не зливатись в один нероздільний потік токенів.

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

У чому суть патерну Persona-Execution Separation?

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

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

Чому аудит поведінки агентів — окрема проблема?

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

Це вписується в ширшу стурбованість індустрії некерованою поведінкою агентів: наприклад, OpenAI, Anthropic і Google публічно попереджали про ризики rogue AI — агентів, чиї дії розходяться з наміром розробника. Архітектурне розділення персони й виконання — один з можливих способів зменшити цей клас ризиків, не забороняючи агенту гнучко міркувати.

Кому і коли варто застосувати цей підхід?

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

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

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

Висновок AiiN: що це означає для розробників агентів

Наша теза: Persona-Execution Separation — це не заміна наявних guardrails (політик доступу, human-in-the-loop, rate limits), а додатковий шар архітектурної дисципліни, який робить ці guardrails простіше перевіряти post-factum. Якщо ваш агент уже логує виклики інструментів окремо від «міркувань» моделі — ви фактично рухаєтесь у цьому напрямку інтуїтивно; патерн просто дає цьому підходу назву і обґрунтування. Командам, що проєктують агентів для регульованих доменів, варто вже зараз закладати розділення persona-шару і execution-шару в схему логування, а не намагатися розплутувати єдиний трейс постфактум після інциденту.

Що таке «персона» агента в цьому контексті?

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

Чи означає розділення відмову від гнучкості LLM?

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