Open‑source проєкт Paperclip, який його творець Dotta описує як «human control plane for AI labor», пропонує не просто набір агентів на базі LLM, а повноцінну інфраструктуру для керування «штатом» штучних співробітників. Його позиціонують як оркестратор для zero‑human компаній, де бізнес‑процеси виконують десятки й сотні агентів — від CEO до кодерів, маркетологів і QA.
Ключова ідея Paperclip у тому, щоб перетворити хаотичне використання окремих моделей на керовану, повторювану систему роботи: зі скілами, планами, перевірками якості, браузерною автоматизацією та рутинами, які можна запускати за розкладом. Саме цей рівень «операційки» відрізняє Paperclip від чергового інтерфейсу до LLM.
Скіли як нова «інфраструктура компетенцій» для агентів
У центрі підходу Paperclip — скіли. Це не просто окремі функції чи плагіни, а будівельні блоки компетенцій, які можна встановлювати, перевикористовувати й ділитися ними між агентами та організаціями.
У Paperclip вбудований менеджер скілів, а інтеграція зі стороннім репозиторієм skills.sh дозволяє встановлювати готові інструменти буквально як пакети. Будь‑який агент у цій системі — це не лише «модель плюс інструкції», а ще й набір підключених скілів, які визначають, що він реально вміє робити.
Показовий приклад — робота з відео. Для створення ролика, що святкує 40 000 GitHub‑зірок Paperclip, у системі було використано скіл Remotion best practices. Remotion — open‑source інструмент для генерації відео на базі React, і замість того, щоб щоразу пояснювати агенту, як правильно з ним працювати, ці знання було винесено в окремий скіл.
Організаційний рівень тут критичний: CEO‑агент у Paperclip вміє самостійно «наймати» нових агентів і встановлювати їм потрібні скіли. У сценарії з відео CEO створив роль video writer, підключив їй Remotion best practices і передав завдання. Далі агент уже працював як спеціалізований відео‑продюсер, а не як «чиста» LLM.
Цей підхід дозволяє кодувати доменну експертизу безпосередньо в агентів. Наприклад, можна створити Paperclip‑специфічний скіл, який включає бренд‑гайд, візуальний стиль, типову тривалість кадрів, тональність тексту. З часом, аналізуючи фідбек, який люди дають агентам (наприклад, що всі зрізи у відео мають бути по 2 секунди, а не по 6), ці патерни можна винести в окремий скіл і зробити їх частиною «корпоративної пам’яті» для всіх відео‑агентів.
Таким чином, skills.sh і вбудований менеджер скілів у Paperclip перетворюють розрізнені інструкції на централізовану систему компетенцій, яку легко масштабувати на всю організацію агентів.
Планування як окремий артефакт: чому розділення «думати» і «робити» підвищує надійність
Одна з найбільших проблем у роботі з LLM‑агентами — їхня схильність одразу «кидатися в дію», пропускаючи етап чіткого планування. Це призводить до нестабільних результатів, пропущених кроків і труднощів із відтворюваністю процесу.
Paperclip вирішує це через підтримку планів як об’єктів першого класу. Коли агент отримує завдання, він спочатку генерує план — структурований опис кроків, які потрібно виконати, — і лише після затвердження переходить до виконання.
У випадку з Remotion‑відео це виглядало так: людина задала короткий промпт на кшталт «подивися на дашборд зі статистикою, сплануй відео для святкування 40 000 зірок». Агент не почав одразу генерувати код чи сторіборд, а спершу створив план. Людина швидко переглянула його, внесла корекції — наприклад, скоротити тривалість кадрів до 2 секунд, змінити акценти анімації — і лише після цього агент перейшов до реалізації.
Такий поділ «планування» і «виконання» дає кілька важливих ефектів.
По‑перше, з’являється прозорість. План — це артефакт, який можна прочитати, обговорити, зберегти, порівняти з іншими. Він фіксує наміри агента до того, як будуть витрачені ресурси на виконання.
По‑друге, зростає контрольованість. Людина може втрутитися на рівні плану, не чекаючи, поки агент зробить велику кількість роботи «не в той бік». Це особливо важливо в бізнес‑процесах, де помилка на ранньому етапі може дорого коштувати.
По‑третє, підвищується відтворюваність. Якщо певний тип завдання виконується успішно, план можна повторно використати як шаблон, адаптувати під інші проєкти або винести в окремий скіл чи рутину.
У традиційних «чатових» сценаріях користувачеві доводиться вручну змушувати модель «спочатку скласти план». У Paperclip це вбудовано в саму модель роботи: план — це не побічний текст у чаті, а формальний об’єкт, з яким працює вся система.
Друга лінія оборони: QA‑агенти, браузерний скіл і ланцюжки «виконавець–рев’юер–апрувер»
Ще одна слабка ланка у звичайній роботі з агентами — відсутність системної перевірки результатів. Навіть якщо користувач просить модель «перевірити в браузері», це часто ігнорується або виконується непослідовно.
Paperclip вводить окрему роль QA‑агента, який може автоматично підключатися до завдань як рев’юер. Цей агент зазвичай оснащений спеціальним браузерним скілом — agent browser skill. Він дозволяє відкривати сайти, заповнювати форми, натискати кнопки та виконувати інші дії у веб‑інтерфейсі.
Це критично для end‑to‑end QA. Наприклад, якщо кодер‑агент вніс зміни в веб‑додаток, QA‑агент може самостійно відкрити потрібну сторінку, пройти сценарій користувача, перевірити, чи працюють форми, чи коректно відображаються дані. Це вже не просто «прочитати код і сказати, що все виглядає нормально», а фактичне програвання сценарію в браузері.
У Paperclip завдання можуть бути сконфігуровані так, що їх не можна завершити без рев’ю з боку QA‑агента. Система дозволяє задавати вимогу «потрібен рев’юер» і, за потреби, ще й окремий «апрувер».
Ця трирівнева модель — виконавець, рев’юер, апрувер — добре відображає реальні процеси в компаніях. Кодер‑агент виконує роботу, QA‑агент перевіряє її якість, а менеджер або старший агент (наприклад, CTO чи продакт‑менеджер) виступає як апрувер, який приймає остаточне рішення, чи відповідає результат стандартам бренду й бізнес‑цілям.
Важливий момент: Paperclip задуманий як вендорно‑нейтральний оркестратор. У реальних сценаріях команди часто працюють із різними моделями — Codex, Claude, Gemini, Hermes, Pi, OpenAI‑моделями через OpenRouter тощо. Кожна з них має свої «звички» й обмеження, а інтеграції на кшталт веб‑хуків реалізуються по‑різному. Paperclip пропонує єдиний «каркас» для побудови таких ланцюжків незалежно від того, яка саме модель стоїть за конкретним агентом.
Результат — підвищена надійність: завдання не просто «віддаються в модель», а проходять через формалізований процес із QA й апрувалом, де кожен крок можна відстежити й налаштувати.
Рутини як «операційний автопілот»: від changelog’ів до PR‑оглядів
Окрім разових завдань, у будь‑якій організації є величезний пласт повторюваних процесів: щоденні дайджести, оновлення changelog’ів, підготовка підсумків по pull request’ах, формування повідомлень у Discord чи Slack.
Paperclip пропонує для цього механізм рутин — заздалегідь налаштованих робочих процесів, які можна запускати вручну або за розкладом. Рутини описують послідовність дій, які мають виконати агенти, і можуть бути прив’язані до конкретних проєктів або ролей.
Наприклад, можна створити рутину, яка щодня формує повідомлення в Discord про все, що було вмерджено в master‑гілку, і паралельно генерує текст релізного changelog’а. Або рутину, яка обробляє конкретний GitHub‑pull request: аналізує зміни, формує резюме, перевіряє відповідність стилю коду.
Важливо, що рутини підтримують шаблонні змінні. Це означає, що при запуску рутин, пов’язаних із PR, можна вказати, наприклад, назву гілки як параметр. Замість того, щоб щоразу переписувати промпт «зроби огляд PR у гілці X», користувач просто обирає рутину «огляд PR» і підставляє потрібну гілку в поле змінної.
Це суттєво знижує когнітивне навантаження: замість папок із промптами, копіювання текстів і ручного налаштування кожного запуску, користувач працює з формалізованими сценаріями, які легко повторити й делегувати іншим.
Рутини не існують у вакуумі — вони можуть використовувати скіли. Якщо в організації вже є скіл для роботи з PR, його можна підключити до рутини, щоб не дублювати логіку. У випадку Paperclip як open‑source проєкту в рутинах використовується, зокрема, інтеграція з Greptile — зовнішнім інструментом для першого проходу код‑рев’ю GitHub‑pull request’ів.
Сценарій виглядає так: після створення PR запускається рутина, яка, серед іншого, викликає Greptile‑скіл. Той звертається до GitHub, аналізує зміни, формує відгук і повертає його в контекст Paperclip. Далі вже інші агенти або люди можуть доповнити цей огляд, але перший, базовий рівень аналізу виконано автоматично.
Таким чином, рутини в Paperclip працюють як операційний автопілот: вони перетворюють розрізнені «одноразові» промпти на стабільні, повторювані процеси, які легко масштабувати й комбінувати з іншими елементами системи — скілами, QA‑агентами, планами.
Від коду до маркетингу: як доменна експертиза вшивається в агентів
Хоча приклади з PR‑оглядами й Greptile показують силу Paperclip у розробницьких сценаріях, сам проєкт із самого початку позиціонується як загальний бізнес‑оркестратор, а не суто інструмент для коду.
Внутрішня «організація» Paperclip включає не лише CTO з командою кодерів, а й CMO з маркетинговими агентами — контент‑стратегами, відео‑райтерами тощо. Ті самі механізми, що працюють для коду, застосовні й до маркетингу, продажів, фінансових операцій.
Скіли дозволяють кодувати доменну експертизу: бренд‑гайди, tone of voice, правила роботи з конкретними інструментами (від Remotion до CRM‑систем). Плани дають змогу структурувати кампанії, контент‑серії, сценарії відео. QA‑агенти можуть перевіряти, чи відповідає контент бренду, чи коректно працюють лендинги, чи правильно налаштовані форми збору лідів.
Рутини, у свою чергу, можуть автоматизувати регулярні маркетингові активності: щотижневі дайджести, оновлення сторінок продукту, розсилки, пости в соцмережах. Завдяки шаблонним змінним ті самі рутини можна адаптувати під різні кампанії, ринки або сегменти аудиторії.
Ключовий момент у тому, що Paperclip не намагається «зробити все сам». Замість цього він виступає як шар оркестрації, який поєднує різні моделі (через OpenRouter та інші інтерфейси), зовнішні сервіси на кшталт Greptile і внутрішні скіли організації в єдину систему.
У результаті компанія отримує не просто набір розрізнених AI‑інструментів, а керовану «організацію» агентів, де кожен має роль, компетенції, процеси перевірки й місце в загальному робочому потоці.
Висновок: від «чату з моделлю» до керованої AI‑організації
Paperclip демонструє, як виглядає наступний крок еволюції роботи з AI‑агентами. Замість того, щоб відкривати десятки вкладок із Claude чи іншими моделями й намагатися тримати в голові, хто над чим працює, користувач отримує:
формалізовані скіли як носії компетенцій, які можна перевикористовувати й поширювати між агентами;
плани як об’єкти першого класу, що відділяють етап «подумати» від «зробити» й підвищують контрольованість;
QA‑агентів із браузерними скілами та ланцюжками «виконавець–рев’юер–апрувер», які додають другу й третю лінію захисту якості;
рутини з шаблонними змінними, що перетворюють повторювані задачі на стабільні, керовані процеси;
інтеграції зі спеціалізованими зовнішніми інструментами на кшталт Greptile, які підсилюють окремі етапи робочих потоків.
У сумі це наближає до ідеї «zero‑human company» не за рахунок магії однієї моделі, а завдяки продуманій інфраструктурі оркестрації. Людина залишається в ролі того самого «human control plane» — задає цілі, коригує плани, формує скіли й рутини, а агенти виконують левову частку операційної роботи в передбачуваний і відтворюваний спосіб.
Джерело
Paperclip: Open Source Human Control Plane for AI Labor — Dotta Bippa