Ринок AI‑асистентів стрімко рухається від «розумних чатів» до повноцінних агентів, які можуть працювати з реальними сервісами — від Gmail і Google Drive до Salesforce, Slack чи Figma. У новому туторіалі на каналі Tech With Tim демонструється практичний сценарій: як за допомогою платформи Composio підключити Claude Co-Work до десятків і навіть сотень зовнішніх застосунків, налаштувати безпечний доступ і навчити модель ланцюжити дії між різними інструментами.
Цей матеріал розбирає саме практичний бік: як працює on‑demand discovery інструментів у Composio, як відбувається інтеграція з Claude, як виглядає реальний сценарій з Gmail і Google Drive, що відбувається з безпекою, логами та тарифами — і чому все це критично для тих, хто хоче будувати на базі LLM не просто чат, а робочий інструмент.
On‑demand discovery: як не «вбити» модель сотнями інструментів
Головна технічна проблема сучасних AI‑агентів — контекстне перевантаження. Коли користувач додає до Claude або іншого LLM десятки нативних конекторів, кожен з яких містить десятки окремих інструментів, модель змушена на кожен запит отримувати в системному промпті список з сотень або навіть тисяч доступних функцій.
У випадку Claude це виглядає як довгий перелік офіційно схвалених конекторів. Якщо підключити один‑два — це майже не відчувається. Але варто додати, наприклад, десять сервісів, кожен з яких має по 50 окремих дій, — і модель уже бачить близько 500 інструментів при кожному зверненні. Це одразу створює три ефекти.
По‑перше, різко зростає кількість токенів у системному промпті, а отже і вартість кожної взаємодії. По‑друге, падає точність вибору інструментів: LLM гірше орієнтується в довгому переліку функцій і частіше помиляється з вибором. По‑третє, збільшується час обробки запиту, оскільки модель має «переварити» значно більший обсяг контексту. Це не теоретична проблема, а добре задокументований ефект: LLM погано працюють, коли їм одночасно пропонують тисячі можливих дій.
Composio пропонує іншу архітектуру — on‑demand tool discovery. Замість того, щоб одразу показувати моделі сотні конкретних інструментів, платформа спочатку відкриває для Claude лише один або кілька мета‑інструментів. Ключовий серед них — функція пошуку інструментів.
Сценарій виглядає так. Користувач формулює запит, наприклад: «Надішли команді підсумковий лист про сьогоднішній стендап». Claude, замість того щоб гортати список з сотень дій, спершу викликає єдину функцію search tools, яку надає Composio. Далі вже Composio, використовуючи власну семантичну пошукову систему, підбирає невеликий, цільовий список інструментів, які відповідають запиту: скажімо, «Gmail: надіслати лист», «Slack: надіслати повідомлення в канал» тощо.
Claude отримує цю коротку вибірку, обирає потрібний інструмент і викликає його. Таким чином, модель працює не з сотнями функцій, а з кількома релевантними варіантами, підібраними зовнішньою системою. Контекст залишається компактним, а точність вибору інструментів зростає.
Ще один важливий елемент — обрізання результатів. Відповіді від зовнішніх сервісів можуть бути великими: листи, документи, списки задач. Composio перед поверненням результату в модель підрізає ці дані, щоб не роздувати контекст. Це безпосередньо економить токени і зменшує ризик того, що промпт стане надто великим і дорогим.
У підсумку Claude бачить лише невеликий набір мета‑інструментів Composio, а всі деталі про конкретні інтеграції, їхню кількість і структуру залишаються «за кулісами» в окремому шарі, який не навантажує LLM.
Єдиний шар інтеграцій: як працює дашборд і автентифікація
Щоб така схема взагалі була можливою, потрібен окремий рівень інфраструктури, який бере на себе всю роботу з підключенням сервісів, зберіганням токенів і управлінням сесіями. У випадку Composio цю роль виконує веб‑дашборд.
Після реєстрації користувач потрапляє в інтерфейс, де можна переглядати доступні інтеграції — від Instagram, YouTube, Slack, Reddit, Monday і Twitter до Salesforce, HubSpot, Gmail, Google Drive, LinkedIn, DocuSign та десятків інших. Заявлено підтримку до приблизно тисячі різних застосунків, і пошук по каталогу відкритий безкоштовно.
Підключення відбувається через знайомі OAuth‑подібні потоки. Наприклад, щоб додати Gmail, користувач натискає «Connect», переходить на сторінку авторизації Google, надає доступ, після чого Composio отримує необхідні токени. Далі всі сесії, оновлення токенів і повторна автентифікація відбуваються на боці Composio, а не Claude чи іншої AI‑платформи.
Це знімає одразу кілька практичних проблем. По‑перше, не потрібно покладатися на те, як саме кожна AI‑платформа реалізувала власні конектори й оновлення токенів. Якщо нативний конектор у Claude «відвалився» через закінчення сесії, користувачеві доводиться вручну перепідключати сервіс. У Composio оновлення токенів відбувається автоматично, і ризик простою через автентифікацію зменшується.
По‑друге, з’являється можливість підключати кілька акаунтів одного й того самого сервісу. У дашборді для Gmail можна додати одразу кілька поштових скриньок, дати кожній зрозумілу назву і тримати всі підключення активними одночасно. Те саме стосується Google Drive та інших сервісів. Нативні конектори Claude наразі дозволяють працювати лише з одним акаунтом на сервіс, що для багатьох професійних сценаріїв — серйозне обмеження.
Крім того, дашборд дозволяє керувати вже створеними підключеннями, переглядати список доступних інструментів для кожного сервісу, а також організовувати їх за кількома організаціями. Це дає змогу розділяти робочі й особисті інтеграції або, наприклад, налаштовувати окремі середовища для різних команд чи проєктів.
Ключовий момент: усі ці налаштування виконуються один раз у Composio, після чого їх можна використовувати з різними AI‑платформами — Claude, Codeex, Gemini та іншими. Замість того щоб підключати Gmail, Slack чи HubSpot окремо в кожному інструменті, користувач просто вказує їм один і той самий MCP‑конектор Composio, який уже містить усю конфігурацію.
Інтеграція з Claude Co‑Work: один конектор, кілька мета‑інструментів
З технічного погляду підключення Composio до Claude Co‑Work виглядає досить просто, але важливо розуміти, що саме відбувається «під капотом».
У налаштуваннях Claude Co‑Work є розділ Connectors, де можна додати власний MCP‑конектор. Composio надає спеціальний URL, який потрібно вставити в поле «Custom connector». Користувач задає назву, наприклад «Composio», вставляє URL і натискає «Add».
Після цього Claude пропонує натиснути «Connect» — і відкриває в браузері сторінку авторизації Composio. Якщо користувач уже залогінений у Composio на цьому комп’ютері, достатньо натиснути «Authorize». З цього моменту Claude і Composio пов’язані: Claude може викликати мета‑інструменти Composio, а Composio — звертатися до підключених сервісів від імені користувача.
У налаштуваннях конектора в Claude можна побачити, що насправді відкрито лише невеликий набір інструментів. Це, зокрема, manage connections, multi‑execute tool, remote bash tool, remote workbench, wafer connection, search tool і get tool schemas. Саме ці мета‑інструменти й потрібні, щоб керувати всією екосистемою інтеграцій, не розкриваючи моделі сотні конкретних дій.
Окремо налаштовуються дозволи. Claude дозволяє вказати, які дії можна виконувати завжди, а які — лише з підтвердженням користувача. У прикладі read‑only операції (наприклад, читання листів) позначаються як «always allow», тоді як дії запису чи видалення (надсилання листів, зміна файлів, видалення об’єктів) вимагають явного схвалення. Це створює додатковий рівень безпеки: агент може вільно досліджувати доступні інструменти, але не зможе змінювати дані без участі людини.
Якщо під час роботи Claude стикається з потребою використати інструмент, який ще не підключений у Composio, система може прямо в інтерфейсі AI показати підказку з посиланням на підключення потрібного сервісу. Таким чином, розширення можливостей агента відбувається поступово й інтерактивно, без необхідності заздалегідь налаштовувати всі можливі інтеграції.
Практика: від Gmail до Google Docs і Drive в одному ланцюжку
Теоретична архітектура набуває сенсу лише тоді, коли її можна застосувати до реальних робочих задач. Один із продемонстрованих сценаріїв — робота з поштою та документами Google.
Після підключення Gmail у дашборді Composio і зв’язування Composio з Claude Co‑Work користувач формулює запит у стилі: «Використовуючи Composio, зайди в мою пошту, знайди останні три листи у вхідних і зроби короткий підсумок з ключовими моментами». Важливий нюанс: у промпті варто явно згадати Composio, щоб модель зрозуміла, що потрібно скористатися саме цим конектором, оскільки його назва не є інтуїтивно зрозумілою для LLM.
Далі починається типовий для Composio процес. Claude викликає search tools, щоб знайти інструменти, пов’язані з Gmail. Composio повертає список, де, зокрема, є функція на кшталт «Gmail: fetch emails». Claude обирає її, викликає з параметрами «останні три листи у вхідних», отримує обрізаний результат і на його основі формує текстовий підсумок для користувача.
На цьому ланцюжок не закінчується. У тому ж середовищі можна продовжити завдання: попросити агента створити Google Doc з цим підсумком, зберегти його на Google Drive і повернути посилання. Для цього в Composio мають бути підключені Google Docs і Google Drive, але з погляду Claude це все ще той самий конектор Composio.
Модель знову звертається до search tools, цього разу шукаючи інструменти для створення документа і збереження файлу на диску. Composio повертає відповідні функції, Claude викликає їх у потрібній послідовності, а користувач на виході отримує не лише текстовий підсумок листів, а й посилання на документ у Google Drive, створений автоматично.
Цей приклад показує, як Composio дозволяє ланцюжити кілька інструментів у межах одного запиту, не перевантажуючи модель деталями про кожен окремий API. Для користувача це виглядає як діалог з агентом, який «уміє» читати пошту, створювати документи й працювати з хмарним сховищем, хоча технічно всі ці дії виконуються через окремий шар інфраструктури.
Логи, SDK і тарифи: що відбувається за лаштунками
Ще один аспект, який важливий для розробників і power‑користувачів, — прозорість і контроль над тим, що саме робить агент. Composio надає журнали викликів інструментів: можна подивитися, які інструменти запускалися, коли саме, у якій послідовності, які були «стрики» використання. Це корисно як для налагодження складних ланцюжків дій, так і для аудиту — особливо коли агент отримує доступ до робочих систем на кшталт CRM чи рекламних кабінетів.
Окремо згадується SDK для побудови й керування AI‑агентами поверх Composio. Деталі його використання залишаються за межами конкретного туторіалу, але сам факт наявності SDK означає, що платформу можна інтегрувати не лише з готовими інтерфейсами на кшталт Claude Co‑Work, а й із власними застосунками, де LLM виступає як бекенд‑агент, що керує зовнішніми сервісами через Composio.
Фінансовий бік виглядає досить помірковано. Є безкоштовний тариф із лімітом у 20 000 викликів інструментів на місяць. Автор туторіалу зазначає, що, попри активне використання Composio в кількох акаунтах, йому жодного разу не вдалося перевищити цей ліміт. Для більш інтенсивних сценаріїв передбачений платний план за 29 доларів на місяць із 200 000 викликів, а також вищий рівень із 2 мільйонами викликів на місяць і окремими enterprise‑опціями.
З огляду на те, що Composio додатково економить токени за рахунок обрізання результатів і зменшення контексту, загальна вартість володіння для складних агентних сценаріїв може виявитися нижчою, ніж при використанні великої кількості нативних конекторів, які роздувають системний промпт.
Висновок: інфраструктура для агентів, а не ще один конектор
Підключення Composio до Claude Co‑Work виглядає як простий крок у налаштуваннях, але по суті це додавання цілого інфраструктурного шару між LLM і зовнішніми сервісами. Саме цей шар бере на себе найскладніші завдання: керування сотнями інтеграцій, зберігання й оновлення токенів, семантичний пошук потрібних інструментів, обрізання результатів і логування всіх дій.
Для користувача це означає, що Claude перестає бути ізольованим чатботом і перетворюється на агента, який може працювати з поштою, документами, CRM, соцмережами та іншими робочими інструментами, не втрачаючи точності й не роздуваючи контекст до некерованих розмірів. А для розробників — що з’являється єдиний, повторно використовуваний шар інтеграцій, який можна підключати до різних AI‑платформ і власних застосунків.
У найближчі роки саме такі інфраструктурні рішення, а не окремі нативні конектори, ймовірно, визначатимуть, наскільки практичними й масштабованими будуть AI‑агенти в реальних бізнес‑процесах.