Війна за агентського клієнта: хто контролює AI-бекенд

Уявіть агентський enterprise-стек так, як вікторіанські інженери думали про залізничну колію. Всі погоджувалися, що потяги — це майбутнє. Справжня боротьба, та, що тихо вирішила, хто збагатіє на наступні п'ятдесят років, велася за колію під ними. Snowflake, Databricks, Microsoft, OpenAI та Anthropic — всі вони зараз прокладають свою колію, а більшість ринку досі сперечається про локомотиви.

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

Проблема

Агентський клієнт — це нова система взаємодії. Snowflake перейменував Snowflake Intelligence на CoWork і додав щось під назвою CoCo. Databricks має Genie. Microsoft має Copilot. Google має Gemini Enterprise. OpenAI має ChatGPT і Codex. Anthropic має Claude, і так, заплутано, також щось під брендом Cowork. Як SiliconANGLE сформулював у Breaking Analysis від Дейва Велланте та Джорджа Гілберта, більша боротьба — не Snowflake проти Databricks і не копілоти проти агентів. Вона про те, хто контролює інтелектуального клієнта та бекенд, що робить його корисним.

Кожен, хто намагався підключити чат-інтерфейс до реального enterprise-сховища, знає: нудна частина — не LLM. Це семантика. Агент повинен знати, що «активний клієнт» у фінансах означає щось інше, ніж «активний клієнт» у маркетингу, і що показник кількості персоналу з Workday узгоджується зі списком акаунтів Salesforce лише у другий вівторок кварталу. Цей контекст і є тією самою колією. Прокладіть її неправильно — і більше нічого не поїде зверху.

Стаття використовує «інтегровані інновації» Клея Крістенсена та «екстремальне співпроєктування» Дженсена Хуанга, щоб донести думку: агентський клієнт і бекенд мають бути розроблені разом, оскільки бекенд навчається на тому, як користувачі та розробники взаємодіють через клієнт. Цей цикл зворотного зв'язку і є рівом. Розробте два шари незалежно — і отримаєте те, що enterprise IT виробляє вже шістдесят років: ще більше силосів із доброзичливішим обличчям.

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

Варіанти на столі

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

Поставити на вендорів даних. Snowflake просуває Horizon Context і Cortex Sense разом із CoWork. Databricks будує data intelligence через Unity Catalog і майже напевно перетворить Data + AI Summit у середині червня на вітрину Genie. Обидва також тиснуть у сферу governance за допомогою Horizon, Polaris і Unity, що є поганою новиною для Collibra, Alation та Informatica. Пітч тут чесний: дані живуть у нас, семантична модель живе у нас, агент теж має бути тут. Ризик у тому, що клієнтський досвід ніколи не наздоганяє те, що кінцеві користувачі отримують від універсального чат-інструменту. Ви можете побачити, що вони поставляють, у документації Snowflake та документації Databricks відповідно — і розрив між платформенними амбіціями та поточним продуктом все ще реальний.

Поставити на гіперскейлерський набір. Microsoft просуває Work IQ та Fabric IQ за Copilot. Google має Gemini Enterprise. Аргумент пишеться сам: ваша електронна пошта, документи, ідентифікація та половина ваших даних уже тут, тож агент теж має бути тут. Компроміс — це прив'язка на глибшому рівні, ніж будь-коли раніше, бо рівень інтелекту складніше мігрувати, ніж базу даних.

Поставити на розробників моделей. OpenAI Group PBC та Anthropic PBC, найімовірніше, мають найвищий за обсягом агентський клієнтський трафік у світі прямо зараз. Breaking Analysis відвертий щодо слабкості: у них ще немає бекенду для захоплення та гармонізації інтелектуальних взаємодій, що проходять через ці клієнти. Вони будують локомотиви, не володіючи коліями. Очікуйте агресивних кроків для виправлення цього, ймовірно через поглинання або глибокі партнерства з одним із вендорів даних.

Поставити на системи обліку. SAP Business Data Cloud, Salesforce Data Cloud, ServiceNow і Celonis — всі стверджують, що агент має знаходитися поруч із транзакційним процесом, а не поруч із аналітичним сховищем. Вони мають рацію. Oracle, SAP, Salesforce і Workday — це місця, де насправді відбувається виконання бізнес-процесів, і система інтелекту, що їх ігнорує, — це система інтелекту про маркетингові дашборди.

Жодна з цих ставок поки що не домінує. Той, хто продає вам впевненість 8 червня 2026 року, продає щось інше.

Що насправді мають робити дата-команди

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

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

Практично це означає три речі. По-перше, ставтеся до каталогу як до продукту, а не до артефакту відповідності. Незалежно від того, на чому ви зупинитесь — Horizon, Polaris чи Unity — метадані, які ви туди завантажуєте, визначають стелю для будь-якого агента зверху. По-друге, інструментуйте агентського клієнта, якого ви пілотуєте, так щоб людські сліди міркувань, дії агентів та історія запитів поверталися до рівня інтелекту. Цикл зворотного зв'язку, на якому так наполягає стаття SiliconANGLE, реальний, і більшість пілотів його ігнорують. По-третє, не дозволяйте агентському клієнту володіти семантичними визначеннями. Якщо «дохід» визначено всередині CoWork або Copilot, а не всередині портативного шару, ви щойно обрали свого вендора на наступне десятиліття, не усвідомлюючи цього.

Контраріанський хід — і я б стверджував, що правильний для більшості команд середнього розміру — це тримати клієнтський шар навмисно замінним протягом наступних вісімнадцяти місяців. Запускайте Genie на стороні Databricks, Copilot на стороні Microsoft, можливо Claude для коду, і змушуйте їх усіх читати з однієї і тієї ж керованої семантичної моделі. Так, це більше роботи. Це також єдина позиція, яка дозволяє вам змінити думку у 2027 році без повного перезбирання.

Підводні камені та крайні випадки

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

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

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

Четвертий, і той, що болить о 3-й ночі, — недетермінованість. Один і той самий агент, отримавши те саме питання, може генерувати різний SQL у різні дні. Ваші контракти даних, тести та спостережуваність мають виходити з того, що споживач тепер є стохастичним процесом, а не відомим дашбордом.

Ключові висновки

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

• Стратегічна боротьба — це спільне проєктування агентського клієнта (CoWork, Genie, Copilot, Gemini Enterprise, ChatGPT/Codex, Claude) та системи інтелектуального бекенду, а не порівняння окремих продуктів.
• OpenAI та Anthropic мають клієнтську дистрибуцію, але ще не мають enterprise-бекенду. Очікуйте поглинань, партнерств або серйозного виходу в governance протягом дванадцяти місяців.
• Snowflake і Databricks поглинають частку ринку governance від Collibra, Alation та Informatica через Horizon, Polaris і Unity. Застарілим вендорам каталогів терміново потрібна нова стратегія.
• Інвестуйте в портативний семантичний шар і каталог рівня продукту, перш ніж зобов'язуватися перед одним агентським клієнтом. Шар знизу є довговічнішим, ніж чат-вікно зверху.
• Плануйте для недетермінованих споживачів, обмежених агентських ідентифікацій і несподіваних рахунків за обчислення. Операційна модель для агентів — не операційна модель для дашбордів.