MCP, A2A та ACP на практиці: як банк під’єднує інструменти та агентів між собою.

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

Інженерні зусилля змістилися від простого розміру моделей до розробки протоколів. Три специфікації спрямовані на вирішення проблеми з’єднання: MCP (Model Context Protocol), A2A (Agent-to-Agent) та ACP (Agent Communication Protocol). Разом вони визначають, як модель отримує доступ до інструментів, як один агент взаємодіє з іншим та як кілька агентів можуть спільно виконувати завдання, не впадаючи в хаос.

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

Чому проста модель потребує протоколів

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

На початковому етапі для вирішення проблем моделі під’єднували безпосередньо до REST API, по одному з’єднувачу за іншим. Для асистента з виявлення шахрайства створювали спеціальний код для API основного банкінгу, ще більше коду — для CRM, а ще більше — для керування справами. Невеликі проєкти справлялися з цим. У більших проєктах виникали три проблеми:

• Нічого не можна було використати знову. Коннектор для роботи з основними банківськими системами у команди з боротьби з шахрайством не був корисним для команди з кредитування, хоча обидві групи потребували ідентичних даних транзакцій, тож кожен проект доводилося починати з нуля.
• Стан зникав між запитами. API за своєю конструкцією є безстановими. Аналітик, який отримав дані про транзакції клієнта, а через кілька запитань почав шукати щось незвичайне в „цих даних“, з’ясував, що звичайна інтеграція API не зберігає зв’язку між двома запитами, якщо тільки інженери вручну не створять шар пам’яті.
• Дозволи додавались окремо. Кожна банківська операція вимагає перевірки дозволів та створення запису для аудиторів. Молодший аналітик з боротьби з шахрайством може читати історію транзакцій, але не може схвалити скасування переказу. Індивідуальна налаштування кожного API ускладнювали дотримання таких детальних правил та ускладнювали їх демонстрацію аудитору.

Протокол укладає контракт один раз. Жодному банку не потрібно розробляти власний метод для того, щоб модель могла звернутися до механізму виявлення шахрайств, оскільки MCP забезпечує єдиний інтерфейс. Жодній команді не потрібно створювати власний спосіб передачі справи від агента з боротьби зі шахрайствами до агента з дотримання правил, оскільки A2A пропонує інший спосіб. HTTP робив це для мережевих додатків, а SQL — для баз даних: єдина спільна мова, яка дозволяє незалежно розробленим системам працювати разом.

П’ять етапів проектування

У банківській сфері та в інших галузях проектування систем пройшло п’ять етапів.

1. Простий LLM. Модель відповідає лише на основі даних навчання. Вона може пояснити, що таке KYC, але не може сказати, чи відповідає профіль певного клієнта правилам KYC банку, оскільки ніколи не бачить запису цього клієнта.
2. Генерація з підсиленням за допомогою пошуку. Модель підключається до сховища документів, такого як посібник з дотримання вимог та попередні рекомендації регуляторів, тож відповіді ґрунтуються на актуальному, приватному контенті, специфічному для організації, а не на загальних знаннях, отриманих під час навчання.
3. Агенти. Модель може не лише здійснювати пошук, а й виконувати дії. Асистент з дотримання вимог тепер може посилатися на політику KYC та перевіряти документи клієнта у базі даних згідно з нею, виявляючи будь-які розбіжності.
4. Багатоагентні системи. Коли один агент одночасно виконує завдання з виявлення шахрайства, оцінки кредитоспроможності та спілкування з клієнтами, він стає ненадійним та важким для керування. Роботу розподіляють між спеціалістами — агентом з боротьби зі шахрайством, агентом з надання кредитів та агентом зі спілкування з клієнтами, кожен з яких є експертом у своїй вузькій галузі.
5. Протоколи. Коли існує багато агентів та систем, потрібен стандартний спосіб для того, щоб вони могли знаходити один одного, обмінюватися контекстом та безпечно спілкуватися. MCP, A2A та ACP задовольняють цю потребу.

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

Виклик інструментів — шар під MCP

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

Механізм є простим. Для кожного доступного інструменту розробник пише JSON Schema з назвою, описом та параметрами з визначеним типом, а потім надсилає його до моделі разом із запитом. Коли модель вирішує, що потрібен інструмент, вона нічого не виконує. Її результатом є структурований JSON-об’єкт із назвою інструменту та аргументами, а супутнє додатку виконує цю функцію та повертає результат моделі. Схема для банківських операцій виглядає так:

{
  "name": "get_customer_transactions",
  "description": "Returns transactions for a customer above a given amount, within a date range",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "min_amount": {"type": "number"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"}
    },
    "required": ["customer_id", "start_date", "end_date"]
  }
}

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

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

MCP детальніше

MCP з’явився від Anthropic наприкінці 2024 року як відкритий стандарт для під’єднання ШІ-застосунків до зовнішніх систем. Уявіть собі універсальний адаптер. Раніше для під’єднання банківського асистента до основної банківської системи, двигуна виявлення шахрайств та CRM потрібно було три несумісні інтеграції. Тепер будь-який клієнт, що відповідає стандарту MCP, може взаємодіяти з будь-яким сервером, що також відповідає цьому стандарту, так само, як будь-який USB-пристрій підходить до будь-якого USB-порту.

Арифметика M помножене на N

Основна проблема є комбінаторною. Під’єднання M інструментів до N застосунків створює матрицю, яка стає некерованою зі зростанням обох чисел. Банк із п’ятьма внутрішніми системами та чотирма асистентами (для виявлення шахрайств, кредитування, обслуговування клієнтів, дотримання норм) потребував би до двадцяти індивідуальних з’єднувачів. Стандартний протокол скорочує це до п’яти плюс чотири, оскільки кожна система та кожен асистент реалізують MCP лише один раз.

Три ролі

• Хост: додаток ШІ, який фактично бачить користувач, наприклад інтерфейс асистента аналітика шахрайств.
• Клієнт: компонент усередині хоста, який керує одним з’єднанням із сервером MCP та обробляє комунікацію на рівні протоколу.
• Сервер: сторона, яка надає можливості, тобто дані чи дії. Банк може мати один сервер перед основною банківською системою, інший перед механізмом виявлення шахрайств та ще один перед сховищем документів; кожен з них підтримується командою, яка відповідає за відповідну систему.

Три примітиви, які може надати сервер

• Ресурси містять лише для читання дані, які модель може використовувати в контексті, наприклад виписку з рахунку чи статус документів для верифікації особи. Як і запити типу GET, вони лише надають інформацію та нічого не змінюють.

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

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

Вибірка, аналіз та передача даних

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

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

Формат передачі даних — JSON-RPC 2.0 через один із двох поширених каналів передачі. Stdio підходить для сервера, що працює на власному комп’ютері клієнта. HTTP з Server-Sent Events або streamable HTTP підходять для віддаленого сервера. До сервера банківських операцій у дата-центрі, який знаходиться за брандмауером, можна під’єднатися через віддалений HTTP із належною автентифікацією, а не через stdio.

Безпека

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

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

Як виглядає розгортання MCP

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

При розслідуванні шахрайства відображається шлях запиту:

1. Аналітик хоче отримати інформацію про кожну транзакцію на суму понад десять тисяч доларів для певного клієнта за останні тридцять днів, а також перевірити, чи не змінився нещодавно «відбиток пристрою».
2. LLM хоста визначає, що потрібні два виклики інструментів, та просить клієнта виконати get_transactions на сервері основної банківської системи та get_device_history на сервері механізму виявлення шахрайств.

Клієнт надсилає запити JSON-RPC до обох серверів через HTTPS.

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

Клієнт передає обидві відповіді моделі, яка об’єднує їх у один огляд.

Усе — як запити, так і відповіді, а також ідентифікатор аналітика — записується до журналу аудиту.

Мінімальний сервер на Python, створений за зразком офіційного SDK, демонструє, скільки коду потрібно для такого інструменту:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("core-banking-server")
@mcp.tool()
def get_transactions(customer_id: str, min_amount: float, days: int) -> list:
    """Fetch transactions above a threshold for a customer, scoped to the caller's authorization."""
    # In production this calls the real core banking API,
    # scoped and logged, never queried directly by the model.
    return query_core_banking(customer_id, min_amount, days)
@mcp.tool()
def place_transaction_hold(transaction_id: str, reason: str) -> dict:
    """Places a temporary hold on a transaction pending review. Requires human confirmation before execution."""
    return execute_hold(transaction_id, reason)
if __name__ == "__main__":
    mcp.run(transport="stdio")

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

Деякі звички допомагають підтримувати сервери у стані готовності до роботи:

• Надавайте кожному серверу одну систему для обробки, а не моноліт, який охоплює основні банківські функції, боротьбу з шахрайством та CRM.
• Пишіть описи інструментів у форматі документації для нового аналітика, адже модель вирішує, коли інструмент застосовувати, виключно на основі цього тексту.
• Ведіть версіонування схем інструментів. Зміна обов’язкового параметра в get_transactions без попередження порушує роботу всіх асистентів, які від нього залежать, включаючи тих, хто працює поза командою з боротьби з шахрайством.

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

A2A, агенти, які спілкуються між собою

MCP керує зв’язком між моделлю та інструментами. A2A, який Google представила у 2025 році та який тепер підтримується Linux Foundation, керує іншим типом зв’язку: один автономний агент викликає інший, особливо коли їх створили різні команди чи постачальники.

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

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

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

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

По-друге, агент з боротьби з шахрайством перевіряє цей звинувачення, звертаючись до серверів MCP для корпоративного банкінгу та до механізму виявлення шахрайств для отримання даних про транзакції та пристрої. Коли його впевненість у вердикті щодо шахрайства є низькою, він уникає припущень та передає справу через механізм A2A агенту з перевірки дотримання правил, який застосовує суворіші регуляторні вимоги, а за потреби — передає її людському співробітнику, відповідальному за дотримання правил. Консультант клієнта, агент з боротьби з шахрайством, агент з перевірки дотримання правил, людина — саме така структурована передача обов’язків є основою функціонування механізму A2A.

ACP — шар обміну повідомленнями

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

• Архітектура. Розмови перетворюються на послідовності введених повідомлень. Кожне повідомлення містить зміст та метадані про його відправника, потік розмови та тип відповіді, яку воно очікує. Тому процес підвищення рівня складності справи, пов’язаної з шахрайством, включатиме більше, ніж саму справу: структуровані поля для ідентифікатора справи, агента, який подав запит, рівня терміновості та типу очікуваної відповіді.
• Обмін повідомленнями. Структура замінює собою неструктурований текст — так само, як електронний лист має тему, відправника та тіло, а не є єдиним блоком символів. Коли десятки агентів працюють над одним процесом надання кредиту, кожне повідомлення має потрапити до правильного агента та до відповідальної особи всередині нього.

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

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

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

Як порівнюються ці п’ять підходів

Якщо розглядати їх поруч, варіанти відрізняються за кількома критеріями:

• Що вони з’єднують. Звичайний API з’єднує одне додатку з іншим. Виклик інструменту з’єднує модель з функцією. MCP з’єднує модель чи додаток з інструментами, даними та запитами. A2A з’єднує агента з агентом. ACP з’єднує агентів на рівні повідомлень.
• Стандартизація між постачальниками. Звичайні API — ні. Виклик інструменту — частково. MCP, A2A та ACP — так.
• Виявлення можливостей. Немає для звичайних API та викликів інструментів. Динамічне для MCP через картки агентів у режимі A2A, обмежене для ACP.
• Вбудовані конвенції стану та пам’яті. Немає для звичайних API та викликів інструментів, часткове застосування для MCP та A2A, основна увага приділяється ACP.
• Ілюстрація у банківській сфері. Банківська система, що взаємодіє з CRM; асистент, який викликає задану функцію для перевірки балансу; асистент, який виявляє та викликає інструменти банківської системи, системи боротьби з шахрайством та системи обробки документів однаково; агент з боротьби з шахрайством, який делегує завдання агенту з перевірки дотримання правил; відстеження статусу схвалення кредиту на кілька днів між трьома агентами.

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

Одне повідомлення клієнта, від початку до кінця

Візьмемо одне повідомлення: клієнт не розуміє зняття коштів у розмірі п’ятисот доларів та також хоче дізнатися про кращу ставку за іпотеку. Усі компоненти системи реагують крок за кроком.

1. Клієнт надсилає повідомлення до AI Assistant — додатку-хоста всередині банківського додатку.
2. За допомогою A2A асистент передає запит щодо шахрайства агенту з боротьби зі шахрайством та запит щодо іпотеки агенту з надання кредитів, причому обидва процеси виконуються одночасно.

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

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

Обидва агенти повідомляють про стан справи асистенту через A2A, використовуючи структуровані повідомлення у стилі ACP, які містять інформацію про статус справи, очікувані людські схвалення та висновки.

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

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

Безпека між агентами та протоколами

• Вставка запиту. Ворожа інструкція, прихована в документі, електронному листі чи завантаженому файлі, може спробувати контролювати наступний крок агента. Уявіть собі шахрайський спір із прихованим текстом, який наказує агенту з боротьби з шахрайством схвалити заявку без перевірки. Інструменти MCP змінюють реальний стан, тому небезпека є реальною. Заходи протидії: розглядати всі отримані дані як ненадійні, ніколи не дозволяти результатам роботи моделі запускати інструменти високого ризику, такі як place_transaction_hold, без перевірки політики, а також обмежувати перелік інструментів, які модель може бачити в певному контексті.
• Аутентифікація. Кожне з’єднання клієнт-сервер MCP та кожна передача даних між компонентами A2A потребує аутентифікації, зазвичай за допомогою OAuth 2.1, тож анонімний користувач не може використовувати інструменти основного банкінгу чи доручати завдання агенту з перевірки дотримання правил.

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

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

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

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

Куди це прямує

Напрямок роботи легко зрозуміти. Протоколи на кшталт MCP стають шаром драйверів пристроїв для ШІ — стандартним шляхом від будь-якої моделі до будь-якого інструменту без необхідності створення спеціальних з’єднувачів. Очікуйте, що операційні системи ШІ стануть окремою категорією, де сервери у стилі MCP будуть вважатися інфраструктурою першого класу, подібною до баз даних та черг повідомлень, а сервери банківських операцій — цим, до чого кожен внутрішній проект ШІ підключатиметься без необхідності їх повторної розробки. Очікуйте ринки серверів, які вже пройшли перевірку та аудит, щоб банк міг використовувати сервери верифікації KYC, схвалені регуляторами, замість того, щоб їх створювати самостійно. Очікуйте розвитку інструментів управління для аудиту викликів MCP та делегувань типу A2A, адже команди зі забезпечення дотримання правил та управління ризиками потребуватимуть такої прозорості ще до того, як усе це почне впливати на реальні гроші. І очікуйте, що ці ж патерни поширяться не лише на банківську сферу, а й на будь-яку галузь, де системам міркувань потрібен стандартний, підлягаючий аудиту спосіб дії у світі.

Коротка версія

Один лише модель не може перевіряти баланс, заблокувати рахунок чи оцінювати іпотеку. Стандарт MCP уніфікує спосіб доступу до інструментів, даних та команд, що дозволяє асистенту з боротьби з шахрайством та асистенту з кредитами користуватися одним сервером корпоративного банкінгу без дублювання інтеграцій. Стандарт A2A уніфікує спосіб передачі завдань між спеціалізованими агентами без необхідності вивчення їхньої внутрішньої структури. Стандарт ACP уніфікує обмін повідомленнями, керування станом та обробку помилок у складних процесах, таких як схвалення кредиту протягом кількох днів. У банках ці протоколи — це не просто зручності; саме вони забезпечують можливість масштабованого застосування процедур авторизації, ведення аудитних записів та людського схвалення.

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