Розмова про інтеграцію старої системи майже завжди починається однаково: «API немає». Раніше далі йшла пауза й кошторис на ручну роботу, а тепер є відповідь, яка звучить як універсальний ключ: хай агент просто клікає замість людини. Технічно це працює, і демонстрація виходить переконлива — агент відкриває вікно, знаходить поле, вписує значення, тисне «Зберегти». Складне питання інше: що станеться з цією автоматизацією через чотири місяці, коли вендор програми перенесе кнопку на два сантиметри вліво.
Відповідь залежить від того, на що агент спирається в момент дії — на письмовий контракт чи на картинку. Способи інтеграції вишиковуються в сходинки, де кожна наступна дає більше охоплення й менше опори. Розумний порядок дій — іти згори вниз і зупинитися на першій сходинці, яка закриває задачу.
Сходинки інтеграції за зростанням крихкості
Перша й найміцніша — документований API. Ви працюєте не з програмою, а з її письмовим контрактом: які поля існують, що повертається у відповідь, що вважається помилкою. Такий контракт теж змінюється, але змінюється оголошено: у нього є версії, а у вендора — графік підтримки старих. Поломка приходить з попередженням і з датою.
На другій сходинці стоять події та вебхуки, коли платформа сама штовхає вам повідомлення про зміну. Контракт тут ще є, а от доставка вже не гарантована: Bitrix24 прямо пише, що повторних відправок подій немає, а Shopify радить не покладатися на доставку вебхуків взагалі. Цей клас відмов ми розібрали окремо в матеріалі «Де закінчується ваша автоматизація» — посилання в кінці статті.
Третя — готовий конектор або iPaaS-платформа між вашими системами. Ви не пишете код, і це справжня економія, але між вами й системою з'явився ще один вендор зі своїм графіком релізів. Коли платформа оновлює API, конектор наздоганяє її не миттєво, і у вікні між цими двома подіями живете ви.
Четверта сходинка — файловий обмін: вивантаження за розкладом, імпорт за розкладом, CSV або XML у папці. Її регулярно пропускають як несучасну, і дарма. Обмін файлами не дає реального часу, зате структура вивантаження в корпоративних системах змінюється в рази рідше за екранні форми, а поломка помітна одразу: файл або відповідає очікуваній структурі, або ні. Якщо задача терпить затримку в годину, ця сходинка часто виявляється найдешевшою з тих, що взагалі надійно працюють.
Далі йде скрейпінг сторінки або звернення до внутрішнього недокументованого запиту, який ви підгледіли у вкладці «Мережа» браузера. Формально це вже робота без контракту: ви спираєтесь на розмітку й на адресу, яких вендор вам не обіцяв і які має право змінити в будь-який вівторок.
Шоста, остання — Computer Use. Опори немає взагалі: агент бачить те саме, що бачить людина, тобто зображення екрана, і кожна його дія — це здогад про те, що намальовано в цій точці. Усе, що на попередніх сходинках було записано текстом, тут доводиться щоразу впізнавати заново.
Що показують заміри
Напрям вимірюють публічно. Бенчмарк OSWorld від дослідників Гонконзького університету, Salesforce Research, Carnegie Mellon і Університету Ватерлоо саджає агента за справжню операційну систему й дає йому робочі задачі. У першій версії, опублікованій у 2024 році, люди виконували понад 72% завдань, а найкраща модель — 12.24%, причому провалювалась вона на найпростішому: не могла надійно зрозуміти, куди на екрані тиснути.
За два роки цю частину проблеми здебільшого закрили, і саме тому в червні 2026 року вийшла друга версія бенчмарку — зі 108 довгими наскрізними сценаріями замість коротких операцій. Медіанна задача забирає у кваліфікованої людини близько 1.6 години, майже 70% задач довші за годину, і на одну таку задачу агент витрачає в середньому 318 звернень до інструментів проти приблизно 30 у першій версії.
Результати на цих сценаріях такі. За основною метрикою — задача або доведена до кінця, або ні — найкращий результат показує Claude Opus 4.8 з максимальним обсягом міркувань: 20.6% завершених задач при частковому заліку 54.8%. GPT-5.5 значно економніший за токенами, але виходить на плато близько 14%. У таблиці лідерів бенчмарку станом на жовтень 2026 року першим іде Claude Opus 5: 44.33% завершених задач на оновленій версії набору задач v2.1 — більш ніж удвічі вище, але все ще менше половини.
Завершеність тримається лише на коротких сценаріях. Розкладку по тривалості автори будували на попередньому поколінні моделей — GPT-5.5 і Claude Opus 4.7, — тож загальні 20.6% у новішого Opus 4.8 набираються саме на коротких і середніх відрізках, а не рівномірно по всій шкалі. На сценаріях, коротших за 45 хвилин людської роботи, обидві моделі дають 20–24%, а далі падають швидко. У бін 137–163 хвилини вже жодна з протестованих моделей не перевищує 10%, а на всьому, що довше за 163 хвилини, завершеність дорівнює нулю для кожної з них. Це обрив, а не плавна деградація. Сценарій для Computer Use треба різати на короткі відрізки з перевіркою між ними, бо довгий ланцюжок просто не доїжджає.
Агенти ламаються не там, де очікують
Інтуїція підказує, що агент промахнеться мишею. Автори другої версії бенчмарку фіксують інше: моделі не спотикаються ні на базовому керуванні інтерфейсом, ні на коді. Вони гублять обмеження, поставлені на початку задачі, пропускають інформацію, яка приходить уже під час виконання, вгадують там, де варто було б перепитати, і не перевіряють власний результат. Найгірше їм дається робота, що залежить від прихованого стану — від того, чого не видно на поточному екрані.
Ось шість рядків із розкладки складнощів по 108 сценаріях:
- візуально-просторова точність — потрібна в 41.7% задач: влучити, вирівняти, звірити на рівні пікселів
- висновок про неявний стан — 39.8%: потрібне значення ніде не написане, його треба дістати з попередніх записів або журналів
- відстеження стану багатьох об'єктів — 39.8%: тримати десятки рядків, записів чи правок узгодженими між собою до кінця сценарію
- розв'язання суперечностей — 36.1%: два джерела кажуть різне, і треба зрозуміти, яке з них головне
- робота за інструкцією — 20.4%: витягти процедуру з PDF чи відео й застосувати її до випадку, який в інструкції не описаний
- зміна умов на льоту — 9.3%: лист або повідомлення в чаті посеред задачі змінює вимоги
Якщо операція, яку ви збираєтесь віддати агенту, тримається на тому, що виконавець пам'ятає домовленість тритижневої давності й знає, який з двох прайсів актуальний, — ви ставите автоматизацію рівно в ту точку, де вона зараз найслабша.
Що про це пише сам виробник
Anthropic перелічує обмеження свого інструменту computer use відкрито, і цей перелік вартий уваги до того, як ви щось плануєте. Латентність, за формулюванням документації, може бути завеликою порівняно зі звичайною роботою людини за комп'ютером, тому виробник радить сценарії, де швидкість не критична: фоновий збір інформації, автоматизоване тестування — і в довіреному середовищі. Модель може помилятися або вигадувати координати, коли визначає точку кліку. Надійність вибору інструмента падає на нішевих застосунках і тоді, коли в роботі кілька програм одночасно. Окремим пунктом серед обмежень стоїть прокручування: у застосунках, де скрол не спрацьовує, документація радить клавіатурні альтернативи на кшталт Page Down.
Зосередьтеся на сценаріях, де швидкість не критична, — наприклад, фоновий збір інформації чи автоматизоване тестування, — у довірених середовищах.
— Anthropic, розділ «Limitations» документації computer use
Окремо варто розібратися з тим, що саме залишає ваш контур, бо тут легко зробити хибний висновок. Computer use працює як клієнтський інструмент: сесія виконується на вашому боці, і скріншоти, рухи миші, введення з клавіатури та файли зберігаються у вашому середовищі, а не в постачальника моделі. Але зображення екрана все одно вирушають у модель — вона обробляє їх у реальному часі як частину виклику API, і саме за них ви платите вхідними токенами. Утримання цих запитів регулюється загальною політикою зберігання даних API, а сам режим сумісний з нульовим утриманням, бо місце й спосіб зберігання визначає ваш застосунок. Якщо на екрані в момент роботи агента видно персональні дані клієнтів, це предмет для угоди про обробку даних, а не для галочки «все лишається у нас».
Звідки береться вартість підтримки
Рахунок за Computer Use влаштований не так, як за виклик API, і це варто закласти в кошторис до старту. Агент бачить систему через скріншоти, кожен з яких коштує приблизно від тисячі до 1800 вхідних токенів, і робить такий знімок практично на кожному кроці. Пригадайте порядок величин з бенчмарку: 318 звернень на задачу проти 30 у коротких операціях. Витрата росте разом з довжиною сценарію, а не разом з його цінністю для бізнесу — саме тому дві операції з однаковою користю можуть відрізнятися за собівартістю в десять разів лише через кількість екранів на шляху.
Друга стаття витрат — переробки. Інтеграція через API живе до оголошеної зміни версії. Інтеграція через екран живе до наступного релізу інтерфейсу, про який вам ніхто не повідомить, бо для вендора перенесення кнопки не є зміною контракту — контракту з вами в нього й не було. Планувати тут треба не разове впровадження, а регулярний перегляд, прив'язаний до частоти оновлень тієї системи.
Третя, найнеприємніша — тиха поломка. Скрипт, що впав, видно одразу. Агент, який після переїзду кнопки впевнено натиснув сусідню, продовжує рапортувати про успіх, і різницю ви побачите тільки в даних, іноді через тижні. Тому моніторити треба результат операції в системі-приймачі, а не факт того, що агент відпрацював без помилки.
Коли Computer Use виправданий
Сукупно умови складаються в досить вузьке вікно, і чесніше перелічити його повністю:
- верхніх сходинок справді немає — ви перевірили не лише публічну документацію, а й партнерський доступ, вивантаження в файл і пряме читання бази для систем на власному сервері
- обсяг тримається в десятках операцій на день: на тисячах вартість екранів і частка помилок перевершать ручну роботу
- сценарій короткий — хвилини, а не години, або нарізаний на такі відрізки з перевіркою між ними
- процес стабільний — інтерфейс тієї системи оновлюється рідко, і ви знаєте, як часто
- результат можна перевірити машинно: є куди подивитися й переконатися, що дію справді виконано
- помилка оборотна — операція не переказує гроші, не видаляє записи й не йде клієнту без людського підтвердження
- є власник — людина, яка розбирає збої й відповідає за результат
Перший пункт відсіює більше проєктів, ніж очікують. Найдорожча помилка в цій темі взагалі не технічна: компанія будує крихку автоматизацію поверх екрана, маючи під рукою нічне вивантаження, яким ніхто не поцікавився, бо питання вендору ніхто не поставив.
Що зробити до впровадження
Почніть з ще одного заходу на пошук контракту. Питання вендору про партнерський API або регулярне вивантаження ставиться за один лист і закриває тему дешевше за будь-яку розробку. Наступний крок — письмова фіксація процесу: послідовність екранів, умови розгалуження, як виглядає успіх і як виглядає збій. Агент, що діє за екраном, не має де підглянути неписане правило, тому все, що зараз живе в голові співробітника, доведеться дістати назовні.
Далі йдуть чотири речі, які варто описати конкретно, а не назвати. Точки перевірки: після кожного змістовного кроку агент звіряє стан системи — створив контрагента, значить читає його картку й порівнює ЄДРПОУ з тим, що вписував. Межа незворотності: агент готує платіжку, а кнопку «Провести» тисне людина. План відкату: нічний дамп таблиці до запуску сценарію плюс ім'я того, хто виконує цю роботу руками, поки сценарій переробляють. І моніторинг за результатом у системі-приймачі — не «агент відпрацював без помилки», а «за вчора в CRM з'явилося 47 записів, як і в джерелі».
Ця робота однаково потрібна і для Computer Use, і для будь-якого способу автоматизації вище по сходинках. Різниця лише в тому, що на верхніх сходинках без неї можна протриматися довше, а тут її відсутність виявляється в перший же місяць.
Auspex будує автоматизацію та інтеграції CRM, і в проєктах зі старими успадкованими системами ця розмова виникає постійно. На практиці інвентаризація того, що система вміє віддавати назовні — партнерський доступ, вивантаження, база, — знімає питання про Computer Use частіше, ніж підтверджує його. Саме з неї починається наш аудит CRM та інтеграцій, посилання на нього нижче.