Наступний користувач вашого програмного забезпечення — агент ШІ. Чи готова ваша архітектура?

Уявіть, що агент ШІ розглядає спір клієнта щодо рахунку. Він читає скаргу, перевіряє історію рахунку й визначає, що клієнтові належить компенсувати суму. І все це — за лічені секунди.

Вражає. А тепер попросіть його справді оформити компенсаційне зарахування.

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

Агент розуміє, що потрібно зробити, але архітектура не дає йому завершити роботу.

Саме з такою проблемою, на мою думку, дедалі частіше стикатимуться підприємства, коли агентний ШІ переходить до практичного використання. Однак парадокс у тому, що перешкода, яка заважає виконати завдання, майже не пов’язана з інтелектом агента.

Роками ми модернізували корпоративне програмне забезпечення для людей, які ним користуються. Тепер потрібно модернізувати його для агентів, які дедалі частіше працюватимуть із ним.

Інтерфейс користувача ніколи не був усім продуктом

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

Агентові не обов’язково потрібні ці екрани. Він може отримувати інформацію та ініціювати дії через API, сервери Model Context Protocol (MCP) та інші програмні інтерфейси. Це частина переходу до безінтерфейсної архітектури.

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

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

Це має й комерційні наслідки: до 234 мільярдів доларів, які витрачають на корпоративні застосунки, можуть опинитися під загрозою через вплив агентного ШІ до 2030 року. Йдеться про витрати, яким загрожують зміни, а не про гарантоване зникнення цих витрат. А коли агенти виконують роботу, яку раніше робили люди в панелях керування, модель оплати за кожне робоче місце може дедалі частіше поступатися моделям, що ґрунтуються на використанні, виконаних діях або результатах.

Для постачальників програмного забезпечення це виклик для бізнес-моделі. Для підприємств, які покладаються на їхні застосунки, — виклик для архітектури.

Ми модернізували окремі компоненти, але не робочий процес

Більшість підприємств модернізується вже багато років. Одна команда оновлює застарілі застосунки. Інша об’єднує фрагментовані дані на сучасній платформі. Третя створює інтеграції або просто оновлює інтерфейс користувача.

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

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

В обох випадках ми модернізували частини технологічного середовища, але не саму роботу.

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

Ось як це виглядає на практиці. Клієнтові потрібно було пришвидшити підготовку цінових пропозицій для складного ремонту двигунів, де контракти визначають, які деталі можна відремонтувати, замінити або відновити. Підготовка кожної пропозиції потребувала кількох днів, а іноді й тижнів ручного пошуку інформації в контрактах і посібниках з технічного обслуговування. Клієнт уже модернізував свою платформу даних, але пропозиції не почали готуватися швидше, адже вузьким місцем були аж ніяк не дані. Ним був пошук інформації. Ми перебудували цей робочий процес навколо комплексу дослідницьких агентів, скоротили час на пошук інформації на 80%, і підготовка пропозицій почала просуватися зовсім в іншому темпі.

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

Сам по собі API не робить систему готовою до роботи з агентами

Може виникнути спокуса подумати, що все просто: відкрити кінцеві точки, під’єднати агента — і готово.

Хотілося б, щоб усе було так просто.

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

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

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

Чи може агент отримувати достовірні дані з авторитетних джерел? Чи чітко визначені бізнес-правила та чи послідовно їх застосовують? Чи може агент рекомендувати дію, але виконувати лише ті дії, на виконання яких він має повноваження? Якщо щось піде не так, чи зможемо ми відстежити дію, усунути проблему та, коли це можливо, скасувати її?

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

Починайте з робочих процесів, а не з технологій

З чого ж почати?

Я б не починав із переведення кожного застосунку на безінтерфейсну архітектуру чи відкриття доступу до кожного наявного API. Я б почав з одного важливого для бізнесу робочого процесу.

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

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

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

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

Справжні зміни — це більше, ніж безінтерфейсна архітектура

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

Але цього не станеться, якщо просто додати агента до архітектури, яку ніколи не проєктували для роботи з ним.

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