Вимір, якого нам бракувало

У програмному забезпеченні є патерн, про який говорять занадто мало.

Кожна система, яку ми будуємо, має виміри. Не в абстрактному сенсі "чистої архітектури", у цілком реальному, операційному сенсі. Є вимір інтерфейсу: дашборди, адмін-панелі, форми, таблиці, кнопки, фронтсцена, де користувачі читають і змінюють дані. За ним, вимір логіки застосунку: API, WebSockets, черги, фонові воркери, все те, що рухає дані і запускає бізнес-події. Ще глибше, CLI-вимір: бекстейдж-інструменти для агрегацій, завдань обслуговування, міграцій, логіки, яка тихо працює "за кулісами".

Ці три виміри співіснують десятиліттями. Вони добре зрозумілі. Фреймворки, патерни на кшталт CQRS, інфраструктура черг, все це існує, щоб надійно організовувати й оперувати цими вимірами.

Але в цій архітектурі завжди була прихована проблема.

Вимір інтерфейсу, UI, проектувався під середній сценарій використання. Форми покривають 80% взаємодій, які відбуваються регулярно. Решта 20% або відсутні в UI, або вимагають від розробника нового екрану, або змушують користувача експортувати дані в Excel і розбиратися самостійно.

Цей розрив завжди існував. Ми просто з ним змирилися.

З'являється MCP

MCP: Model Context Protocol, вже не новинка. Хайп-цикл пройшов, що, чесно кажучи, робить цей момент кращим для розмови про нього: тепер можна говорити про те, що він реально робить, а не про те, що на нього проектували.

Коротко: MCP: це протокол, який дозволяє мовній моделі взаємодіяти з інструментами, які надає система. Модель знає, які інструменти доступні, розуміє їхні параметри і може міркувати, які з них і в якій послідовності викликати, на основі запиту користувача природною мовою.

Що це означає архітектурно: у вас з'являється новий вимір.

Не заміна UI-виміру. Не заміна API-виміру. Доповнення. Вимір, який існує поряд з наявними і дає користувачам принципово інший спосіб взаємодії з системою, яка вже є.

Якщо подивитися на стек зараз, він виглядає так:

Саме про цей четвертий вимір і йдеться в статті.

Проблема звіту для CFO

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

Такого вигляду в системі немає. Ніхто його не будував, бо ніхто не передбачав саме цієї комбінації фільтрів при проектуванні модуля звітності.

Варіанти сьогодні:

• Попросити розробників. Вони додають завдання в беклог. Воно потрапляє в наступний спринт. Через три тижні, готово.
• Вивантажити все в Excel і зібрати вручну. Займає години. Помилки неминучі.
• CFO не отримує звіт і приймає рішення на інтуїції.

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

Тепер підключіть MCP до цієї системи.

Ви відкриваєте набір інструментів-запитів: класи, які виконують структуровані запити до бази даних, параметризовані й ізольовані, що повертають типізовані дані. Відкриваєте сервіс побудови графіків, наявний, уже в кодовій базі. Відкриваєте інструмент генерації PDF поверх наявного рендерера HTML-у-PDF. Відкриваєте інструмент розсилки листів.

CFO відкриває AI-асистента в ERP. Описує потрібне природною мовою. Мовна модель читає запит, знаходить потрібні інструменти, викликає їх по черзі, запит → графік → PDF, і повертає готовий звіт. Якщо CFO хоче надіслати його листом, каже про це, і лист іде.

Розробник не написав нову функцію. Система не змінилася. CFO отримав саме те, що потребував.

Це не демо. Це виробничий сценарій, який можна реалізувати сьогодні з інструментами, що вже існують.

Що ви насправді робите

Важливо розуміти: MCP не вимагає «додати AI» у якомусь розмитому сенсі.

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

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

Це важливо в системах, де аудитованість не є опцією, а більшість серйозних бізнес-систем, будь то ERP, compliance-платформи чи CRM, саме такі.

Поза внутрішніми системами

Приклад з ERP, це закрита система: користувачі внутрішні, поверхня ризику обмежена, дані ваші. Але той самий патерн діє і назовні.

Уявіть e-commerce маркетплейс. Стандартний UI-патерн: фільтри, пошукове поле, навігація по категоріях. Користувачі, які знають, що шукають, знаходять. Ті, хто не знає точно, або чий запит не вкладається в наявну таксономію фільтрів, мають труднощі.

Підключіть MCP до сервісів продуктового каталогу. Користувач запитує: «Шукаю щось водонепроникне, достатньо компактне для ручної поклажі і до €80, їду в похід до Норвегії в червні». Це не фільтровий запит. Це задача на міркування. Модель розбирає намір, викликає потрібні інструменти і повертає підібрану добірку з поясненням.

Та сама архітектура. Інший контекст. Можливості системи, які ви вже побудували, стають адресованими зовсім по-іншому.

Ще один елемент: Graph RAG

MCP відповідає за частину «робити речі» AI-виміру. Graph RAG: за частину «знати речі».

Якщо поряд з MCP підключити базу знань Graph RAG: таку, що розуміє зв'язки у ваших бізнес-даних, доменні концепції, організаційне знання, система перестає бути реактивною і стає чимось ближчим до обізнаного колеги.

Не чатбот, який витягує документи. Система, яка розуміє, що ця накладна пов'язана з тим постачальником, у якого цей контракт, з такими умовами оплати, що впливають на ось цей прогноз руху коштів. Граф дає моделі реляційний контекст, якого пласка вибірка не дає.

Разом MCP і Graph RAG перетворюють наявну систему на щось, що може міркувати про ваш бізнес, діяти в його межах, і робити це природною мовою.

Коли це будувати

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

Ось тоді MCP додає цінність без додавання ризику. Система вже працює. Ви додаєте нову поверхню, а не перебудовуєте фундамент.

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