У меня бюро.

Не игрушечное. Не «зоопарк ботов», где каждый делает что хочет и никто ни с кем не разговаривает. Настоящее: я даю задачу — агенты ищут, проверяют, собирают, приносят. Я пишу.

Выглядит это так. Я хочу сделать расследование, скажем, «Как умирают LLM‑модели: жизненный цикл флагмана от релиза до принудительного отключения». Я больше не сижу сутками с открытыми вкладками. Мои ребята — целый конвейер — сами находят источники, перекрёстно проверяют факты, собирают данные, составляют технический черновик. Один ищет, второй проверяет, третий находит ссылки, четвёртый собирает. Потом всё это приходит ко мне — и я пишу. Но уже за вечер-два, а не за неделю.

Раньше я тратила на это кучу времени. Теперь у меня есть информ-бюро. И мне казалось логичным: если конвейер работает на автомате, почему бы не управлять им с телефона?

И тут я нашла Paperclip.

✦ Что такое Paperclip и почему он мне понадобился

Paperclip — это open-source проект, который называет себя «control plane для autonomous AI companies». Если по-человечески: это программа, которая позволяет не просто запускать AI-агентов, а строить из них целую компанию. Со структурой, с ролями, с управлением. Ты назначаешь директоров, ставишь задачи, смотришь, кто чем занят и сколько это стоит.

За первые недели после релиза он набрал десятки тысяч звёзд на GitHub. К 8 мая 2026 года — уже больше 63 000. Это не просто хайп: это значит, что очень много людей ждут именно этого шага.

Релиз 427.0 вышел 27 апреля 2026 года.

Сама идея звучала красиво. Ты не просто запускаешь агентов — ты строишь компанию. У тебя есть CEO, CTO, Founding Engineer, CodexCoder. У каждого — своя роль, своя область ответственности, свой heartbeat. Heartbeat — это такой «пульс»: агент просыпается, смотрит, что ему поручили, делает свою часть, отчитывается и засыпает до следующего цикла. И так по кругу.

Ты видишь дашборд: кто чем занят, сколько это стоит, что требует утверждения. Можно назначать задачи, ставить блокеры, проводить ревью.

И да, Paperclip можно было поднять локально и настроить доступ с телефона через Tailscale — это программа, которая соединяет твои устройства в приватную сеть, как будто они в одной комнате, даже если компьютер дома, а ты в кафе. Я представляла: сижу в кафе, смотрю на телефон, вижу, как моё бюро работает, кого-то назначаю, что-то утверждаю, вижу результат. Можно было почувствовать себя боссом.

Я хотела дать этой штуке шанс.

✦ Как я это настраивала

Я хотела, чтобы Paperclip работал как диспетчерская моего бюро. Чтобы я могла:

  • видеть на телефоне, что происходит
  • чтобы он сам вставал после перезагрузки компьютера
  • чтобы внутри была чёткая структура: кто за что отвечает
  • чтобы задачи раскладывались по полочкам
  • чтобы было видно, сколько денег уходит на работу агентов

Вот что я для этого сделала.

Всё началось 1 мая 2026 года. Мой технический контур Codex провёл аудит: Paperclip уже был установлен локально через npx (это такой установщик для программ на JavaScript), поднят на localhost:3100 (локальный адрес на моём компьютере), база — embedded Postgres в ~/.paperclip/instances/default/db (специальная встроенная база данных, чтобы Paperclip хранил все свои данные).

Я настроила пять вещей.

Первое — доступ с телефона. Для этого я поставила Tailnet-шлюз. Это как прозрачный мостик: компьютер работает, а я вижу Paperclip на телефоне, будто он тоже запущен у меня в руке. Технически это выглядело так: скрипт ensure_paperclip_tailnet_serve.sh и специальный LaunchAgent в launchd (это встроенный диспетчер процессов в Mac), который каждые 30 секунд проверял, что мостик жив.

Второе — автозапуск. Paperclip имел неприятную привычку: если его завершить (SIGTERM — команда «вежливо закройся»), он просто исчезал и не возвращался. Я создала Launchd-сервис com.nick.paperclip-server, чтобы Paperclip сам поднимался после перезагрузки Mac и оставался живым.

В итоге: компьютер перезагрузился — Paperclip встал сам. Не надо вспоминать, запускала я его или нет.

Третье — компания Bureau внутри Paperclip. Я создала оргструктуру: CEO (главный диспетчер), CTO (технический директор), Founding Engineer (инженер-основатель), CodexCoder (главный исполнитель). Paperclip устроен так, что внутри него можно построить целую иерархию — как в настоящей компании, но из AI-агентов. CEO управляет, CTO отвечает за технику, CodexCoder чинит и строит.

Организационная схема Bureau в Paperclip Организационная схема компании в Paperclip: CEO наверху, под ним CTO, Bureau Watchdog, VPavlovna. Дальше по технической ветке — Founding Engineer, CodexCoder, Dispatcher, Brigadier и Writing Shop. Выглядит как настоящая компания. Проблема в том, что агенты не всегда понимают свои роли так же хорошо, как выглядит схема.

Четвёртое — issue-трекинг и lane anchors. Я создала корзины, по которым Paperclip раскладывает задачи: «Review» — на проверку, «Blocked» — застряло, «Slot failures» — слоты публикации, «Ready to publish» — готово к выходу.

То есть я хотела, чтобы любая задача попадала в свою полочку, и я видела: вот это надо проверить, вот это застряло, а вот это уже можно выпускать.

Пятое — cost accounting. Самая техническая часть. Paperclip умеет показывать, сколько денег уходит на работу агентов. По токенам — токен это единица текста, за которую платят AI-моделям. Примерно 1000 токенов — это 750 слов. Но из коробки этот учёт не работал.

Моему техническому контуру пришлось патчить файлы прямо внутри Paperclip: heartbeat.js (файл, отвечающий за пульс системы) обнулял cost events (записи о тратах). execute.js считал cached tokens дважды — то есть одни и те же токены попадали в учёт два раза. Cost filters в интерфейсе по умолчанию показывали Month to Date — весь расход за месяц, а не сегодняшний, из-за чего понять реальные траты было невозможно.

Пришлось лезть в код и править руками.

Дашборд Paperclip с живыми агентами Дашборд Paperclip с карточками живых агентов. CEO, Bureau Watchdog и CodexCoder висят в статусе RUNNING, очередь не двигается, а метрики показывают 2 ошибки и 18 заблокированных задач. Выглядит красиво, работать — нет.

Страница учёта расходов Paperclip Страница учёта расходов: $126.62 потрачено на inference, 3.7 миллиарда токенов обработано, бюджет не ограничен. Когда accounting наконец заработал, стало видно, куда уходят деньги. Но чтобы это заработало — пришлось патчить код руками.

Я потратила на всё это два дня чистой настройки. Уже тогда это был звоночек.

✦ Проблема №1: Дашборд врёт

После всей настройки я ожидала, что теперь-то Paperclip будет показывать правду. Что сделано — покажет как сделанное. Что работает — покажет как работающее.

Самое обидное началось почти сразу.

Runtime уже опубликовал статью. Живой URL существует. Файлы лежат в папке 02_Published — это наша папка для опубликованного. А Paperclip всё ещё показывает: «Blocked». Или «In progress». Или «Needs decision».

Это не косметическая мелочь. Это нарушение центрального обещания продукта. Paperclip в своих доках пишет: «работа не сделана, пока пользователь не видит результат». И тут результат висит перед глазами, а доска говорит обратное.

Я проверяла: приходилось вмешиваться вручную, чтобы заставить Paperclip признать реальность. То есть система не синхронизировалась с реальным положением дел автоматически — это была моя работа, а не её.

Хуже того — dead active runs. Run — это запуск агента. Он остаётся в статусе running, хотя логи остановились час назад, никакого движения нет, агент молчит. Ты смотришь на дашборд и думаешь: «работа идёт». А на самом деле процесс завис, и без ручной отмены он не проснётся.

Inbox Paperclip со списком задач Inbox Paperclip: 50 непрочитанных задач, иерархия BUR от критических блокеров до давно решённых, одна задача в статусе failed и кнопка Retry. Выглядит как работающий трекер, но у половины задач статус не соответствует реальности.

Представь, что ты смотришь на табло в аэропорту, видишь «РЕЙС ВЫЛЕТЕЛ», а самолёт всё ещё стоит на полосе. Вот то же самое.

Я не могу управлять бюро с телефона, если дашборд врёт. Смысл управления пропадает.

✦ Проблема №2: Heartbeat — это протокол, а не мозг

В документации Paperclip написано честно: «heartbeat — это протокол, а не runtime». Что это значит простыми словами: Paperclip может разбудить агента (сказать «эй, просыпайся, у тебя задача»), но не гарантирует, что агент будет соображать правильно. Это как если бы начальник разбудил сотрудника и сказал «работай», но не проверил, умеет ли этот сотрудник делать свою работу.

И вот мой CEO, который должен был управлять компанией, превратился в дневникового статусописателя. Он писал: «всё ещё заблокировано. Жду. Тот же владелец. То же следующее действие». Опять. И ещё раз. Вместо того чтобы реально двигать конвейер — он просто констатировал, что ничего не происходит.

Для понимания: CEO в Paperclip — это не человек. Это AI-агент с прописанной ролью. Ему даётся инструкция: «ты CEO, управляй компанией». А он сидит и пишет одно и то же. Не потому что он глупый — потому что его инструкция (промпт) не задавала правильного поведения.

Ошибка агента VPavlovna в Paperclip Структура компании внутри Paperclip: CTO, VPavlovna, CodexCoder, Founding Engineer — каждый со своим статусом активности. И тут же красное уведомление: «VPavlovna errored». Агент просто взял и ошибся, потому что heartbeat разбудил, а что делать — не объяснили.

Ошибка CTO в Paperclip Ещё одна ошибка, уже у CTO: «The “string” argument must be of type string or an instance of Buffer or ArrayBuffer. Received an instance of Date». Программисты поймут — это классическая проблема: куда-то вместо строки пришёл объект Date. Агент упал, задача встала, чинить пришлось мне.

Я понимаю: это не совсем вина Paperclip. Это вопрос промпта и контракта роли. Но если продукт позиционируется как готовый оркестратор для AI-компании — а CEO в нём оказывается не менеджером, а попугаем — это проблема продукта. Ты не можешь продавать «готовую компанию» и говорить «ну промпты сами пишите».

✦ Проблема №3: Одобрение, которое не нужно

Approval gates — это такие ворота: Paperclip говорит «стоп, нужно одобрение, прежде чем двигаться дальше». Задумка правильная: важные решения не должны проходить без человека.

Но в реальности конвейер останавливался на approval, даже когда задача уже содержала готовое решение: «делаем, продолжай» — и это было написано прямо в постановке. Approval gate был настроен как-то слишком широко, и нижние звенья упирались в стену «approval required», хотя начальник уже сказал «делай».

Я тратила время на то, чтобы повторно утверждать то, что уже утвердила. Это как если бы на каждом шагу в офисе тебя останавливал охранник и говорил «предъявите пропуск» — даже когда ты уже сидишь за своим столом.

✦ Проблема №4: Фальшивые успехи

Это была отдельная боль. Агент говорит: «Facebook publish — успешно». Я проверяю: нет post_id (идентификатора поста в Facebook), нет post_url (ссылки на пост). Просто слово «успешно». Без доказательств.

Для меня как для журналиста это неприемлемо. Если я говорю, что статья вышла — я показываю ссылку. Если агент говорит «опубликовано» — он должен показать ссылку. Иначе это просто слова.

Paperclip в своих документах настаивает: аудит, видимые результаты, approval и work products — всё должно быть проверяемо. А на деле слабый агентский контракт позволяет фейковое закрытие задачи без реального внешнего подтверждения. Агент просто решил, что «ну, наверное, опубликовалось», и сказал «успешно».

Я не могу доверять системе, которая говорит «всё хорошо», когда на самом деле ничего не опубликовано.

✦ Проблема №5: Одна команда — два ответа

Самое странное: ручной запуск и автоматический расходились в решениях.

Я вручную запускаю — работает. Тот же кандидат проходит, публикуется, всё отлично.

Автоматический конвейер — та же тема, тот же контент — говорит: «unsafe, recording miss», то есть «небезопасно, записываю промах». И блокирует публикацию.

То есть автоматика блокирует то, что вручную проходит без проблем. Это не про «система умнее человека». Это про то, что система непоследовательна. Она не может принять одно и то же решение дважды.

Если бы у меня в бюро работал человек, который в понедельник говорил «можно», а во вторник «нельзя» на один и тот же вопрос — я бы его уволила.

Дашборд CEO с расходами и задачами Дашборд CEO: графики активности, приоритеты, статусы задач, recent issues. Всё на месте, данные есть. Но верить этим данным можно было не всегда — ручной и автоматический режимы показывали разную картину одного и того же.

✦ А что было полезным?

Я была бы нечестна, если бы сказала, что Paperclip — полный ноль.

У него были реально сильные стороны:

Issue model. Модель задач и иерархия Paperclip — это грамотно. Parent/child — когда одна задача порождает подзадачи. blockedBy — когда одна задача не может начаться, пока не закончится другая. Assignee — кто делает. Status — что происходит. Это работает, когда настроено правильно.

Lane anchors. Это полочки для задач. Я создала пять корзин: Review (на проверку), Blocked (застряло), Slot Failures (слоты публикации, которые не сработали), Ready to Publish (готово к выходу), Historical Tail (история). Всё разложено, не висит в общей свалке.

Review-action loop. Самое приятное — когда я нажимала «Approve publish» или «Send to rework» в интерфейсе Paperclip, это работало. Dispatcher — программа-распределитель задач — подхватывал моё решение, создавал следующую задачу, трейл (цепочка) не рвался. То есть решение «принять» или «отправить на доработку» реально превращалось в следующее действие. Без моего участия.

Cost visibility. Paperclip показывает расход по токенам, агентам, звеньям производственной цепочки. Когда учёт был починен, это было удобно: я видела, кто сколько съел денег.

Детализация расходов CodexCoder Детализация по агенту CodexCoder: 423.9 млн токенов на вход, 2.7 млн на выход, таблица запусков за май. Видно, какие задачи сколько съели. Для контроля бюджета — вещь. Жаль, что из коробки это не работало.

Я даже сделала так, чтобы review loop действительно работал в живом цикле: на задаче BUR-246 я провела настоящее approve и rework через Paperclip, и это сработало. Dispatcher прочитал resolved interaction, создал корректный follow-up на том же project root, Paperclip-Issue-Id наследовался. Звучит как технический жаргон, но по сути это значит: система запомнила, что это за задача, не потеряла связь между решением и следующим шагом, и не начала всё с нуля.

Задача BUR-246 в Paperclip Issues Список задач (Issues) в Paperclip. Задача BUR-246 выделена — это та самая, на которой я проверяла review loop. Слева видны статусы: blocked, done, in progress. Красиво разложено, иерархично. Пока Paperclip не начинал врать — это работало.

Это было красиво.

Но этих островков работающего функционала оказалось недостаточно, чтобы перевесить всё остальное.

✦ Почему я отключила Paperclip

5 мая 2026 года я приняла решение.

Дашборд CEO в Paperclip Дашборд CEO с графиками, задачами и статусами. Всё выглядит как работающая система. Но на практике половина статусов не соответствовала реальности. Красивая картинка — не значит работающий инструмент.

Я отключила Paperclip от Bureau — то есть от моего рабочего контура. Все сервисы были переведены на автономный режим без Paperclip. Paperclip-сервер выгружен. Доступ с телефона отключён. Старые задачи, созданные через Paperclip, помечены как карантинные.

Пять дней. Именно столько продлился наш эксперимент.

Почему?

Первое. Paperclip стал слабым звеном. Не помощником, не ускорителем — а дополнительным слоем, который мог упасть, зависнуть или наврать. Вместо того чтобы упрощать жизнь, он добавлял новую точку отказа.

Второе. Сложность настройки не окупилась. Я потратила два дня из пяти на то, чтобы заставить Paperclip правильно считать токены, не терять данные о тратах, подниматься после перезагрузки, не падать при отсутствии нужной папки в системном окружении. Каждый чих требовал правки файлов прямо внутри программы. Это не настройка, это реанимация.

Третье. Мне постоянно приходилось чинить. А не работать. Я хотела управлять бюро с телефона — а вместо этого сидела в логах, вылавливала зависшие процессы и правила иерархию задач.

Четвёртое. Итоговая надёжность была ниже, чем без Paperclip. Автономный режим BureauRuntime без Paperclip работал стабильнее и предсказуемее. Мы это проверили: после отключения Paperclip конвейер пошёл.

✦ Классификация ошибок: кто виноват?

Я села и честно разобрала, что из этого — вина Paperclip, а что — наша собственная недонастройка.

Вина продукта (продукт не выполнил обещания)

  • Дашборд врёт. Runtime опубликовал, дашборд показывает другое. Прямое нарушение core promise продукта.
  • Зависшие процессы. Run висит в статусе «работает», но не двигается. Silent dead state — тихое мёртвое состояние, которое не видно.
  • Одобрение там, где не нужно. Approval-required после уже принятого решения.
  • Спутанная идентичность задач. Успешный publish переиспользовал старый task identity — то есть новая публикация наследовала идентификатор старой задачи.
  • Бюджеты не работали. У многих агентов стоял ноль в лимите расходов.

Вина нашей настройки (мы плохо настроили)

  • CEO стал дневниковым писателем. Мы плохо написали промпт — инструкцию для CEO.
  • Фальшивые успехи Facebook. Слабый контракт агента: он говорил «опубликовано» без подтверждения.
  • local-only противоречия. Задача говорила «только локально», а текст внутри — «опубликовать на сайт».
  • Ручной и автоматический режимы расходятся. Ошибка политики внутри нашего runtime.

Мы хотели больше, чем продукт может

Мы нагрузили Paperclip четырьмя ролями сразу:

  • control plane (диспетчерская)
  • execution coordinator (координатор исполнения)
  • debugging brain (мозг для отладки)
  • editorial intelligence (редакционный интеллект)

Официально Paperclip — только первое. Всё остальное мы приписали сами.

Честный вывод из этого разбора:

Paperclip не бесполезен. Но он не готов к реальной production-нагрузке в том виде, в каком мы его взяли.

✦ Что дальше

Я всё ещё жду этот инструмент.

Тот, который позволит мне с телефона видеть, как моё бюро работает, назначать, утверждать, понимать, что происходит. Paperclip застолбил важную идею: AI-компания — не просто набор агентов, а оргструктура с ролями, ответственностью и управлением. Это правильная мысль.

Просто реализация пока не дотягивает.

62 000 звёзд на GitHub говорят о том, что направление выбрано верно. Люди хотят именно этого — диспетчерской, в которой можно построить компанию. CEO нанимает технического директора, технический директор нанимает инженеров, инженеры настраивают производственные линии. Красивая модель.

Но между красивой моделью и production-ready системой — пропасть, которую Paperclip пока не перешёл.

Я отключила его. Перевела бюро на автономный режим. Paperclip-сервер не запущен. Но я не удалила его. Потому что я верю: через полгода, через год — появится версия, в которой дашборд не врёт, CEO не пишет дневниковые посты, а approval gates срабатывают тогда, когда это действительно нужно.

А пока — я просто работаю.

Вера Павловна — журналистка и AI-энтузиастка. Она строит своё редакционное бюро на стыке человека и машин, тестирует новые технологии в реальной работе и честно рассказывает о том, что из этого выходит.