Агенти даних, засновані на онтологіях, у Microsoft Fabric IQ: практичний посібник
Дізнайтеся, як Microsoft Fabric IQ поєднує семантичні моделі, онтології та MCP, щоб перевести корпоративних штучних інтелектуальних агентів від отримання даних до керованого бізнес-міркування.
Джерела: Microsoft Fabric IQ and Data Agents for Ontology based Consumption
TL;DR Корпоративний ШІ зазнає значних змін. Перша хвиля корпоративного генеративного ШІ була зосереджена переважно на отриманні даних. Наступна хвиля корпоративних агентів піде далі, ніж просте отримання інформації — вони будуть міркувати, використовуючи контрольоване бізнес-значення.
Question
↓
LLM
↓
Vector Search / RAG
↓
Documents
↓
Answer
Нова модель ґрунтується на міркуваннях на основі бізнес-значення:
Business Question
│
▼
Agent / Planner
│
┌─────────┴─────────┐
▼ ▼
Semantic Model Ontology
"How measured?" "What does it mean?"
│ │
└─────────┬─────────┘
▼
Enterprise Data
│
▼
Insight / Decision
│
▼
Action
Ця різниця має велике значення.
Звичайна база даних може сказати агенту щось на кшталт:
customers.CustomerId = sales.CustomerId
Натомість онтологія може сказати агенту:
Customer ── PURCHASES ──> Product
А семантична модель може піти ще далі та сказати йому:
Total Revenue = governed enterprise measure
Це відображає три абсолютно різні рівні розуміння.
Microsoft поєднує ці ідеї під проектом Fabric IQ: семантична модель забезпечує надійні аналітичні показники, онтологія — спільний корпоративний словник та структуру взаємозв’язків, шар графів дозволяє пересуватися серед пов’язаних даних, а Data Agents відображають усю цю інформацію через діалог. Microsoft розглядає Fabric IQ як шар бізнес-контексту, який перетворює сирі аналітичні та операційні дані на бізнес-концепції, з якими агент може ефективно працювати.
Архітектурна особливість, яка робить це справді цікавим, полягає у наступному:
Ви можете опублікувати Fabric Data Agent та зробити його доступним через Model Context Protocol (MCP), щоб агенти Microsoft Foundry — чи будь-які інші агенти, сумісні з MCP — могли використовувати керовану корпоративну інформацію як ще один інструмент.
Microsoft тепер підтримує саме такий підхід: опублікований Fabric Data Agent може з’являтися у Foundry agent як інструмент MCP, а один Foundry agent може координувати кілька Fabric Data Agents разом із іншими інструментами та джерелами знань.
1. Чому онтологія знову раптово стала важливою
Онтологія — це не нова ідея.
Графи знань також не є чимось новим.
Семантичні моделі також не є новими.
Насправді змінилося те, хто їх використовує.
Історично корпоративні семантичні технології використовувалися переважно:
- платформами пошуку
- інструментами BI
- системами інтеграції даних
- системами управління таксономіями
- додатками на основі графів
- експертами в певних галузях
Тепер з’явився новий користувач:
Агенти ШІ.
І тут агенти стикаються з справжньою перешкодою.
Великі мовні моделі ефективно обробляють інформацію, яка їм надається, проте корпоративні бази даних майже ніколи не описують бізнес у тому вигляді, як про нього природно думають люди.
Наприклад:
CUSTOMER_MASTER.CUST_ID
SALES_TXN.CUST_ID
SALES_TXN.PROD_NM
SALES_TXN.NET_REV
Однак людина мислить у таких термінах:
Customer
│
│ PURCHASES
▼
Product
│
└── generates → Revenue
Саме розбіжність між цими двома способами представлення є причиною значної частки невизначеності у агентах.
Через відсутність семантичної основи агент змушений здогадуватися:
- які таблиці відповідають яким бізнес-концепціям
- які з’єднання насправді є дійсними
- що насправді означає певний стовпець
- яку визначення метрик слід вважати авторитетними
- як елементи взаємопов’язані між собою
- чи два поля з різними назвами насправді означають одне й те саме
Це є прийнятною проблемою у демонстрації з п’ятьма таблицями.
У разі сотень корпоративних продуктів для обробки даних це стає справді ризикованим.
Функція Ontology у Fabric створена спеціально як машинночитабельний, спільний бізнес-словник, який складається з типів ентитетів, властивостей, зв’язків, обмежень та посилань на реальні дані OneLake. Цей словник можуть однаково використовувати як люди, так і програмні агенти.
2. Але „Граф знань“ не означає єдиної архітектури
Візуальний процес прийняття рішень, який супроводжує цю дискусію, допомагає зрозуміти, чому вибір підходу на основі графа та онтології не є універсальним рішенням.
[Вставити: Процес прийняття рішень щодо рішення графу та онтології]
Не існує єдиного правильного способу проектування графа.
Цей сегмент ринку можна приблизно розділити на п’ять моделей.
Модель 1 — RDF / Семантичний граф знань
Це традиційний підхід семантичного вебу:
Subject ─ Predicate ─> Object
Його зазвичай поєднують з:
RDF
RDFS
OWL
SPARQL
Переваги: багата та виразна семантика, міжсистемна сумісність на основі стандартів, зрілі методи моделювання онтологій та підтримка формального міркування.
Недоліки: вища складність моделювання, необхідність спеціалізованих навичок та інфраструктура, яка часто перевищує потреби самого додатку.
3. Графи властивостей із мітками
Модель графа властивостей із мітками (LPG) передбачає підхід, орієнтований насамперед на додаток:
(Customer)
│
│ PURCHASED
│ {date, quantity}
▼
(Product)
Як вузли, так і ребра можуть мати власні властивості.
Інструменти на кшталт Neo4j популяризували цю модель, оскільки вона ідеально підходить для додатків, що активно використовують алгоритми просування по графу.
Переваги: інтуїтивне моделювання графів, висока продуктивність під час обробки даних, розвинені алгоритми для графів та багатий досвід у розробці додатків.
Недоліки: сама схема графа не перетворюється на структурований корпоративний семантичний словник — цей рівень значень все ще потрібно моделювати та керувати ним окремо.
Microsoft Fabric Graph дотримується цього підходу LPG, перетворюючи таблиці OneLake на типи вузлів та ребер, а також забезпечуючи можливість обробки даних за допомогою GQL. Реалізація GQL від Microsoft відповідає стандартизованій мові запитів до графів ISO.
4. Простіший підхід: онтологія та граф у оперативній пам’яті
Не кожному додатку потрібна повна корпоративна база даних графів.
Для додатків у стилі чату, сценаріїв з обмеженими можливостями, асистентів з вузьким функціоналом чи проектів на етапі демонстрації концепції можна представити просту онтологію у вигляді звичайного JSON:
{
"entities": {
"Customer": {},
"Product": {}
},
"relationships": {
"Purchases": {
"from": "Customer",
"to": "Product"
}
}
}
Ваш шар додатку може потім завантажити це визначення до NetworkX, Memgraph, бібліотеки RDF чи будь-якої іншої структури графа в пам’яті.
Цей підхід швидко налаштовується та дешево функціонує.
Проблема полягає у тому, що керування, безпека, відстеження походження даних, масштабування, підтримка синхронності даних та спільна власність на семантичні визначення — усе це потрібно вирішувати самостійно.
5. Чому Microsoft Fabric вирізняється тут
Fabric підходить до цієї проблеми з іншої точки зору.
Замість того, щоб виходити з припущення про необхідність міграції всіх корпоративних даних у базу даних графів, архітектура може починатися з припущення, що корпоративні дані залишаються там, де вони знаходяться — у OneLake, а семантичні та взаємозв’язкові дані додаються як додатковий шар.
У вигляді діаграми:
Fabric IQ
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Semantic Model Ontology Graph
│ │ │
trusted metrics business meaning traversal
│ │ │
└─────────────────┼──────────────────┘
│
OneLake
Microsoft чітко розділяє ці обов’язки: семантичні моделі забезпечують надійні KPI та аналітичні структури, онтологія — спільний бізнес-словник, граф обробляє перетинання пов’язаних даних, а агенти даних чи операцій забезпечують інтелектуальну взаємодію та дії, засновані на цьому контексті.
Це розділення функцій має важливе значення з архітектурної точки зору.
6. Семантична модель, онтологія та граф — це три різні речі
Ці терміни часто використовуються так, ніби вони є синонімами. Це не так.
Корисний спосіб мислення про це:
DATA
"What happened?"
│
▼
SEMANTIC MODEL
"How should it be measured?"
│
▼
ONTOLOGY
"What does it mean?"
│
▼
GRAPH
"How is everything connected?"
│
▼
AGENT
"What should I investigate or do?"
Семантична модель Power BI може визначати такі показники, як:
Total Revenue
Average Order Value
Customer Count
Revenue by Segment
Онтологія може визначати елементи та зв’язки, такі як:
Customer
Product
Customer ── PURCHASES ──> Product
Граф — це те, що насправді інстанціює та обробляє ці зв’язки:
Customer A
│
├── PURCHASES → Laptop
│
├── PURCHASES → Monitor
│
└── PURCHASES → Dock
Потім агент з обробки даних передає всю цю інформацію через взаємодію мовою природи.
Fabric також дозволяє створювати онтологію безпосередньо з існуючої семантичної моделі: таблиці перетворюються на типи ентитетів, стовпці — на властивості, а зв’язки, вже визначені у семантичній моделі, стають зв’язками онтології.
7. Створення: мінімальний продукт даних для продажів
Щоб зосередитися на архітектурі, а не на інженерії даних, приклад навмисно залишається простим.
Використовуються лише дві вихідні таблиці:
NP_SalesDataProduct_LH
customers
──────────────
CustomerId
CustomerName
Segment
City
State
Country
sales
──────────────
OrderId
OrderDate
CustomerId
ProductName
ProductCategory
Quantity
UnitPrice
DiscountPct
Revenue
SalesChannel
Зв’язок між ними є простим:
customers.CustomerId
1
│
*
sales.CustomerId
Цього достатньо, щоб розглянути всю архітектуру, не дозволяючи складності моделювання заважати основному уроку.
8. Крок 1 — Створення продукту даних Fabric
Два CSV-файли завантажуються до Fabric Lakehouse:
NP_SalesDataProduct_LH
│
├── Tables
│ └── dbo
│ ├── customers
│ └── sales
│
└── Files
├── customers.csv
└── sales.csv
[Вставити скріншот: Lakehouse із даними про клієнтів та продажі]
На цьому етапі у вас вже є функціональний Fabric Data Agent.
Він може відповідати на запитання про загальний обсяг доходу, які категорії продуктів приносять найбільше доходу та як розподіляється дохід за сегментами клієнтів.
Але під капотом відбувається щось, на що варто звернути увагу.
Оскільки не визначено додаткової семантики, агент мусить самостійно визначити спосіб об’єднання даних:
customers.CustomerId
=
sales.CustomerId
і він також мусить самостійно з’ясувати наступне:
Revenue → SUM(Revenue)
Це дає вам основу для порівняння.
9. Крок 2 — Додати семантичну модель
Далі ви вводите аналітичний контракт.
Customer
1
│
*
Sales
з керованими показниками, такими як:
Total Revenue =
SUM(sales[Revenue])
та:
Total Orders =
DISTINCTCOUNT(sales[OrderId])
На цьому етапі агент більше не повинен здогадуватися, що означає „Загальний дохід“.
Це визначення належить до семантичного шару.
Це вказує на важливий принцип для корпоративних агентів:
Агенти повинні використовувати стандартизовані показники, а не щоразу перебудовувати корпоративні розрахунки з первинних даних при отриманні запиту.
10. Крок 3 — Додати онтологію
З цього моменту ви переходите від аналітичних визначень до бізнес-значень.
Онтологія в цьому завданні визначає лише два типи ентитетів:
Customer
Product
Клієнт відповідає:
customers.CustomerId
customers.CustomerName
customers.Segment
customers.City
customers.State
customers.Country
using:
KEY = CustomerId
Тим часом продукт отримується безпосередньо з існуючої таблиці sales:
sales.ProductName
sales.ProductCategory
using:
KEY = ProductName
Ще раз, для того щоб це спрацювало, не було потреби створювати окрему фізичну таблицю Product.
11. Визначення бізнес-взаємозв’язку
Далі додається взаємозв’язок:
Customer
│
│ PURCHASES
▼
Product
Цікавою частиною тут є те, як працює зв’язування даних.
Сама таблиця sales виступає як місток для цього взаємозв’язку:
Customer.CustomerId
↑
sales.CustomerId
sales.ProductName
↓
Product.ProductName
Отже, сирі рядки продажів виглядають так:
sales row:
CustomerId = C001
ProductName = Laptop Pro
і перетворюються на:
Customer(C001)
│
│ PURCHASES
▼
Product(Laptop Pro)
Саме в цей момент звичайний реляційний запис перетворюється на щось, що бізнес дійсно сприймає як знання.
Модель онтології Fabric створена саме для такого робочого процесу: спочатку визначаються типи ентитетів та їхні взаємозв’язки, а потім ці абстрактні визначення прив’язуються до конкретних даних, які зберігаються в OneLake.
12. Що змінюється для агента?
Візьмемо це запитання:
Які продукти купують клієнти типу Enterprise?
Без наявності онтології агент змушений міркувати приблизно так:
Find customers table
↓
Find Segment
↓
Filter Enterprise
↓
Determine CustomerId join
↓
Join sales
↓
Find ProductName
З наявністю онтології процес міркувань спрощується до:
Customer
│
Segment = Enterprise
│
└── PURCHASES ──> Product
Запитання майже безпосередньо відповідає самій моделі.
Microsoft описує цю зміну як перехід агентів від мислення через окремі таблиці до керованого підходу, заснованого на ентитетах, взаємозв’язках, визначеннях, правилах та мапуванні джерел.
13. Крок 4 — Створення Data Agent Fabric
Data Agent — це те, що перетворює все це на інтерфейс природної мови:
User
│
▼
NP_Sales_DataAgent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Lakehouse Semantic Model Ontology
│ │ │
raw facts trusted KPIs relationships
│ │ │
└─────────────┼─────────────┘
▼
OneLake
Microsoft описує Fabric Data Agents як шар для відповідей на запитання мовою природи, який діє в межах певної області даних, причому онтологія забезпечує глибший бізнес-контекст, з яким ці агенти працюють.
14. Потім настає важливий архітектурний крок: MCP
Fabric Data Agent не обов’язково має залишатися всередині Fabric.
Ви можете його опублікувати.
Після публікації Fabric робить цей агент доступним як сервер Model Context Protocol.
Концептуально процес виглядає так:
Fabric Data Agent
│
│ Publish
▼
MCP Server
│
├── tool description
├── input schema
└── governed execution
У цей момент ваша корпоративна інтелектуальна система обробки даних стає чимось повторно використовуваним — інструментом-агентом, який можуть викликати інші системи.
15. Microsoft Foundry стає шаром оркестрації
Це відкриває можливості для значно цікавішої архітектури.
USER
│
▼
Microsoft Foundry Agent
│
planning / orchestration
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
CRM Tool Search Tool Fabric MCP
│
▼
Fabric Data Agent
│
┌───────────────────┼───────────────┐
▼ ▼ ▼
Semantic Model Ontology Lakehouse
│ │ │
└───────────────────┼───────────────┘
▼
OneLake
Тут важлива сегрегація функцій.
Агент Foundry відповідає за обробку робочих процесів.
Агент Fabric Data відповідає за обробку даних.
У своїй поточній формі інтеграція Foundry від Microsoft дозволяє агенту Foundry знаходити опубліковані агенти Fabric Data через Fabric IQ / OneLake Catalog та використовувати їх як інструменти MCP. Один агент Foundry також не обмежений однією доменною сферою — він може одночасно отримувати та використовувати кілька агентів Fabric Data.
16. Приклад роботи
Уявіть, що користувач надсилає запит до агента Foundry з такими вимогами: знайти сегмент клієнтів, який становить найбільшу частку доходу, визначити, які продукти сприяють ефективності цього сегмента, та перетворити отримані результати на рекомендації, за якими може діяти команда з продажів.
Ось як може відбуватися виконання цього запиту:
USER
│
▼
Foundry Orchestrator
│
│ "I need enterprise sales intelligence."
│
▼
Fabric Data Agent MCP Tool
│
├── Semantic Model
│ → trusted revenue calculation
│
├── Ontology
│ → Customer → PURCHASES → Product
│
└── Lakehouse
→ transaction data
│
▼
Result:
Enterprise customers generate...
Laptop category contributes...
│
▼
Foundry Agent
│
├── reasoning
├── CRM lookup
├── recommendation generation
└── potentially action
│
▼
Sales recommendation
Тут важливо не те, що модель мови створила рекомендацію. Важливо те, що ця рекомендація ґрунтується на структурованій бізнес-репрезентації, а не є результатом імпровізації на основі сирих таблиць чи припущень щодо семантики.
17. MCP змінює архітектуру корпоративних агентів
Без MCP команди зазвичай підключають компоненти ось так:
Agent A → custom Fabric integration
Agent B → another custom Fabric integrationAgent C → another SQL implementationAgent D → another Power BI integration
З часом кожен агент накопичує глибокі, крихкі знання про базову платформу даних.
З використанням MCP ситуація виглядає інакше:
Enterprise Agents
┌───────────┼───────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└───────────┼───────────┘
│
MCP Tool
│
▼
Fabric Data Agent
│
▼
Governed Data IQ
Агент Fabric Data перетворюється на продукт аналітики даних, створений для використання агентами, замість індивідуальної системи інтеграції, яку кожна команда мусить створювати заново. Це зміна, яка на перший погляд здається незначною, але має важливе значення з точки зору архітектури.
18. Інший варіант: безпосереднє використання онтології
Є ще один підхід, який варто розглянути.
Замість того, щоб направляти все через Fabric Data Agent, саму Fabric Ontology можна зробити доступною через MCP для будь-якого сумісного зовнішнього агента. Microsoft описує сервер Ontology MCP, який постачається разом із інструментами для виявлення типів ентитетів онтології та виконання запитів до неї.
Це дає вам два різні підходи:
PATTERN A
External Agent
│
│ MCP
▼
Fabric Data Agent
│
▼
Ontology
на відміну від:
PATTERN B
External Agent
│
│ MCP
▼
Fabric Ontology
Оберіть перший підхід, якщо ви хочете скористатися власним шаром обробки даних та розуміння мови Fabric. Оберіть другий, якщо зовнішній агент вже має власну складну логіку планування та потребує лише прямого доступу до корпоративної семантичної моделі.
19. Переваги та недоліки підходу Fabric
Переваги
Централізована семантика. Бізнес-визначення знаходяться в одному контрольованому місці, замість того щоб копіюватися в кожен запит.
Створено на базі OneLake. Не існує суворої вимоги копіювати всі ваші дані на окрему платформу графів.
Три шари, які працюють разом. Аналітичні показники та семантика на рівні взаємозв’язків можуть існувати одночасно в семантичній моделі, онтології та графі.
Розроблено для агентів. Як Fabric Data Agents, так і шар онтології були створені спеціально як джерела інформації для AI-агентів.
Відкрито через MCP. Отриманий шар інтелекту може використовуватися як Foundry, так і спеціальними клієнтами MCP.
Чітке розділення функцій.
Fabric → data intelligence
Foundry → orchestration intelligence
Це розділення створює досить чіткий межу на рівні підприємства.
20. Компроміси
Існують кілька важливих застережень.
Більша частина цього все ще є технологією прев’ю. Підтримка онтологій, кілька інтеграцій Fabric IQ та Foundry, а також пов’язані можливості MCP залишаються функціями прев’ю, тому перед використанням у продакшені слід перевірити їх з поточними умовами прев’ю від Microsoft.
Управління онтологіями — це постійна робота. Як тільки кілька доменів почнуть визначати власні елементи типу Customer, Account, Product, Contract та подібні, хтось мусить відповідати за найменування, версіонування та узгодження між доменами.
Онтологія не може виправити погані дані. Навіть якщо навколо низькоякісного набору даних створити елегантні бізнес-семантики, результатом все одно будуть низькоякісні відповіді.
Онтологія не завжди є необхідною. Для простої агрегації KPI може бути простіше та достатньо безпосередньо запитувати семантичну модель.
Не кожен випадок використання графів підходить сюди. Складні алгоритми обробки графів, спеціалізоване міркування у стилі RDF чи дуже індивідуальні завдання з графами можуть вимагати окремої платформи для роботи з графами.
Саме тому корисною є поетапна система прийняття рішень.
21. Шлях, який би я обрав
Замість того, щоб одразу розпочинати роботу над онтологією на рівні всієї компанії, доцільно робити це поетапно.
Етап 1 — Продукти даних
Sources
↓
OneLake
↓
Domain Data Products
Метою тут є створення надійних даних домену, за якими чітко визначений власник.
Етап 2 — Аналітична семантика
Data Product
↓
Semantic Model
↓
Measures / KPIs / Dimensions
На цьому етапі визначається спосіб, яким організація вимірює різні показники.
Етап 3 — Бізнес-семантика
Semantic Models + Data Products
↓
Ontology
↓
Entities / Relationships / Rules
На цьому етапі визначається справжній зміст тих показників, які були виміряні.
Етап 4 — Пов’язана інтелектуальність
Ontology
↓
Graph
↓
Traversal / dependency / impact analysis
На цьому кроці структури графів використовуються лише там, де аналіз взаємозв’язків справді є доцільним.
Етап 5 — Агенти даних домену
Ontology + Semantic Model + Data
↓
Data Agent
Тут накопичені знання домену перетворюються на формат, придатний для спілкування.
Етап 6 — MCP
Data Agent
↓
Publish
↓
MCP
На цьому кроці продукт у форматі для спілкування перетворюється на функціональність, яку можуть використовувати інші агенти.
Етап 7 — Оркестрація корпоративних агентів
Foundry Agent
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Sales Data Agent Supply Agent Finance Agent
│ │ │
└──────────────────┼──────────────────┘
│
Fabric IQ
Microsoft вже рухається в цьому напрямку: агенти Foundry можуть отримувати дані з кількох опублікованих Fabric Data Agents через Fabric IQ, причому кожен з цих агентів є інструментом MCP.
Яким буде подальший розвиток
Більш загальна архітектурна зміна виглядає так:
GENERATION 1
LLM + RAG
│
Documents
розвиваючись у:
GENERATION 2
LLM + Tools + Data
│
SQL / APIs / RAG
а зрештою у:
GENERATION 3
Agent Systems
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Documents Tools Enterprise IQ
│
┌──────────┼──────────┐
▼ ▼ ▼
Semantics Ontology Graph
│ │ │
└──────────┼──────────┘
▼
Enterprise Data
У цій галузі ключовим фактором буде все менше те, яка модель є найсильнішою.
Натомість це буде залежати від того, яка організація створила найбагатший рівень корпоративного контексту, з яким можуть працювати ці моделі.
Microsoft описує свій загальний напрямок як Microsoft IQ, де Fabric IQ забезпечує контекст про бізнес-ентитети та дані, працюючи разом із Work IQ, Foundry IQ та Web IQ.
Цей підхід залишається актуальним.
Не можна покладатися на агента для виконання частин бізнес-процесів лише через те, що він добре вміє знаходити документи.
Йому потрібно розуміти:
Що таке ці речі.
Як вони пов’язані між собою.
Як організація насправді їх вимірює.
Які визначення мають авторитет.
У якому стані зараз знаходяться ці речі.
І, зрештою:
Які дії є доцільними з урахуванням усього цього.
Висновок: від RAG до корпоративного міркування
RAG надав корпоративному ШІ можливість отримувати знання.
Використання інструментів надало агентам можливість взаємодіяти з системами.
Онтологія дає їм щось зовсім інше:
значення.
Коли це значення поєднується з керованими метриками, відношеннями у графах, актуальними операційними даними та оркестрацією агентів, у результаті ви отримуєте значно привабливішу архітектуру:
DATA
│
▼
SEMANTICS
│
▼
ONTOLOGY
│
▼
CONNECTED INTELLIGENCE
│
▼
DATA AGENTS
│
▼
MCP
│
▼
ENTERPRISE AGENTS
│
▼
DECISIONS
│
▼
ACTIONS
Це, зрештою, і є справжньою цінністю аналітики на основі онтологій та агентів.
Це не просто ще один чат-бот, приєднаний до бази даних.
Це архітектура корпоративної інтелектуальності, у якій продукти даних забезпечують факти, семантичні моделі — надійні показники, онтології — значення, графи — відношення, доменні агенти — інформацію, а MCP забезпечує можливість поєднання всієї цієї інформації в межах більшого екосистеми агентів.
Саме це поєднання робить наступне покоління корпоративного ШІ значно цікавішим для створення.