Runlayer і Rippling закрили взаємні позови, але справжня боротьба лише починається

Суперечка між Runlayer і Rippling завершилася майже так само швидко, як і почалася. 20 серпня 2026 року компанії спільно закрили взаємні позови з остаточним припиненням проваджень. Судові документи свідчать: жодна зі сторін не отримала компенсації, витрати на адвокатів не відшкодовувалися, а мирової угоди між компаніями не було. Після цього Rippling випустила MCP-шлюз, який був у центрі конфлікту. 101

Однак завершення справи не означає, що суд підтвердив або спростував звинувачення. Суд не встановив, чи використала Rippling конфіденційні дані Runlayer, і не вирішив, чи порушила Runlayer патенти Rippling. Юридична суперечка закінчилася, але комерційне протистояння продовжилося.

Як виник конфлікт

28 липня Runlayer подала позов проти Rippling. За твердженням стартапу, більша компанія понад рік тестувала його MCP-шлюз, а інженерні команди тісно співпрацювали. Зрештою Rippling нібито не стала клієнтом, а використала отриману під час оцінювання конфіденційну інформацію для створення конкуруючого продукту. Rippling заперечила ці звинувачення. 1417

У відповідь Rippling подала патентний позов, заявивши, що Runlayer порушила три її патенти. Компанія також підтвердила, що розробляє власний MCP-шлюз, який безпосередньо конкуруватиме з продуктом Runlayer. 7

Взаємні справи тривали приблизно три тижні, після чого сторони подали спільні заяви про припинення проваджень. Формулювання «з остаточним припиненням» означає, що саме ці справи закриті назавжди, але воно не підтверджує правдивість вимог жодної зі сторін. Кожна компанія залишилася зі своїми юридичними витратами. 10

Чому запуск Rippling став головним підсумком

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

Rippling позиціонує шлюз як частину ширшої системи управління AI у своїй платформі для корпоративного програмного забезпечення. Runlayer натомість описує себе як комплекснішу інфраструктурну платформу для MCP-серверів, Skills, плагінів, AI-клієнтів і агентів. У матеріалах Runlayer згадуються MCP-шлюз, політики доступу й OAuth, захист під час виконання, журнали аудиту, середовище для запуску агентів, а також інструменти для пошуку некерованих або «тіньових» MCP-розгортань. 293127

Доступні джерела не дають підстав стверджувати, що продукти мають однакову архітектуру чи набір функцій. Обережніше порівняння таке: обидві компанії змагаються за корпоративний рівень, який контролює доступ AI-агентів до інструментів і робочих даних. Водночас Runlayer подає свій продукт як спеціалізовану багатокомпонентну платформу керування. 71429

Що таке MCP-шлюз

MCP — Model Context Protocol, або протокол контексту моделей — це стандартний спосіб, за допомогою якого AI-клієнти та агенти підключаються до зовнішніх інструментів і даних. MCP-шлюз працює між агентом та корпоративними системами й створює централізовану точку для контролю доступу та моніторингу активності. 2132

На практиці такий шлюз може допомагати компанії:

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

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

Що відомо про Runlayer

Runlayer — нью-йоркський стартап у сфері корпоративної AI-інфраструктури, який вийшов із режиму прихованої розробки у листопаді 2025 року. На старті компанія залучила 11 мільйонів доларів посівного фінансування від Felicis і Khosla Ventures. 47

У червні 2026 року Runlayer оголосила про залучення 30 мільйонів доларів у раунді Series A під керівництвом Felicis за участю Khosla Ventures. Загальний обсяг заявленого фінансування досяг 42 мільйонів доларів. Компанію очолює співзасновник і генеральний директор Ендрю Берман, який раніше заснував Nanit і працював із напрямом AI у Zapier. 404547

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

Урок для засновників: тестування може перетворитися на конкурентну взаємодію

Звинувачення сторін залишаються спірними, але базовий бізнес-ризик очевидний. Тривалий proof of concept — перевірка продукту в умовах, наближених до реального використання, — може охоплювати доступ до дорожніх карт, технічної документації, архітектури, інженерних процесів, а іноді й вихідного коду.

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

Для AI-інфраструктури цей ризик особливо великий. Протоколи, можливості моделей, вимоги до безпеки та самі категорії продуктів змінюються швидко, тому традиційне річне оцінювання може втратити сенс ще до завершення. У випадку Runlayer і Rippling тривалий процес оцінювання за кілька тижнів перетворився на позов, обмежене розкриття матеріалів, припинення справ і запуск конкуруючого продукту. 1014

Стартапам варто розглянути практичні запобіжники:

1. Обмежувати масштаб пілота. Демонструвати лише ті можливості, які потрібні для ухвалення рішення про купівлю.
2. Розкривати інформацію поетапно. Архітектуру, дорожню карту та деталі реалізації варто відкривати лише після чітко визначених етапів.
3. Встановлювати кінцеву дату оцінювання. Пілот має завершуватися у визначений строк і передбачати документований процес ухвалення рішення.
4. Заздалегідь погоджувати критерії переходу до купівлі. Сторони мають розуміти, що саме означають успіх, закупівля та розгортання продукту.
5. Контролювати технічний доступ. Використовувати ізольовані середовища, детальні дозволи, журналювання та відкличні облікові дані.
6. Запроваджувати перевірку «створити чи купити». Варто рано з’ясувати, чи клієнт оцінює постачальника, чи збирає вимоги для власного продукту.

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

Що ця історія показує ринку

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

Runlayer увійшла в цю історію як профінансований спеціалізований стартап, що створює керовану платформу для корпоративних AI-агентів. Rippling вийшла з неї із запущеним конкуруючим шлюзом — одразу після припинення справ.

Оскільки не було ні мирової угоди, ні виплат, ні ліцензійної домовленості, ні судового рішення по суті, тепер вирішальним стає комерційне питання: якому підходу корпоративні клієнти довірять контроль над дедалі важливішим з’єднанням між AI-агентами, інструментами та даними компаній?