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

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

Кожна система, яку ми будуємо, має виміри. Не в абстрактному сенсі "чистої архітектури" — у цілком реальному, операційному сенсі. Є вимір інтерфейсу: дашборди, адмін-панелі, форми, таблиці, кнопки — фронтсцена, де користувачі читають і змінюють дані. За ним — вимір логіки застосунку: 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 в архітектуру з першого дня. Не як основний інтерфейс — форми й таблиці все одно виконують більшу частину роботи, — але як спроектований вимір, з обдуманими межами інструментів і дозволами від самого початку, а не нашарований пізніше.