От вёдер к пасеке: как мы строим агентские системы

Сейчас модно уходить из ИТ и заводить своё хозяйство. Мы своё тоже завели, только прямо в ИТ: рассказываем, как от таскания вёдер с кодом между чатом и редактором дошли до собственной пасеки агентов.

Где старый способ ломается, видно по нашим же проектам. Оркестраторы мешают друг другу в одной основной ветке, наборы проверок стоят в очереди на одной машине, а каждый вендор моделей живёт в своей вкладке, и человек весь день переносит контекст между ними. Почти все инструменты построены вокруг одного человека с одним агентом от одного вендора, и такая схема перестаёт работать, когда проекту нужно много агентов, несколько вендоров и больше одного оператора.

Этот текст отвечает на один вопрос: что нужно, чтобы над одним проектом работали много агентов, несколько вендоров и несколько людей, а качество, стоимость и доверие оставались под контролем? Мы идём по эпохам: чат-боты, оркестраторы внутри одного вендора, оркестраторы поверх сред разных вендоров, оркестраторы, которые не принадлежат ни одному вендору, пасека и ещё один шаг после неё. Каждая глава начинается с проблемы, в которую упёрлась её эпоха, и заканчивается частью нашей системы, которая эту проблему решает.

Текст описывает дизайн, который мы согласовали 17-28 сентября 2026 года. Спецификации за ним влиты как черновики и ещё не заморожены, многое из описанного пока не построено, а видение сильно опережает первую работающую версию. Каждое неочевидное утверждение ссылается на свой источник, а если текст расходится с нашей страницей решений или роадмапом, правы они.

Коротко

• Один оркестратор, любая агентская среда. Оркестратор запускает субагентов в Claude Code, Codex, Muse, agy, Pi или Qwen с одними и теми же инструкциями роли, и у каждого из них своя цель.
• В ядре нет вендора. Контекст дают профили Curator, каждый запуск собирается в одном месте, а хост сессий держит любую среду за одним контрактом. Человек остаётся со средой и подпиской, за которые уже платит, и может сменить среду, не теряя процессов, борд и памяти.
• Качество и стоимость проектируются. Цикл продюсера и ревьюера из разных семейств моделей поднимает качество, а роутинг, локальные движки и сетевые профили отправляют каждую задачу на самую дешёвую модель, которой её хватает.
• Процесс описывается конфигурацией. Проект объявляет роли, типы элементов и схемы работы в Playbook.json. На той же машинерии работают разработка, кафе и семейный календарь.
• Пасека. На каждой машине Кипер ведёт много процессов, у каждого своя борда и свой корневой оркестратор. Оркестраторы разных машин и людей договариваются через waggle, протокол подписанных сообщений, а доверие держится на ключах, которым нужно присутствие человека.
• И ещё одно: рой. Недоверенные чужие агенты входят в пул вокруг одной общей среды, получают работу по одностороннему каналу и проходят ревьюеров из разных семейств моделей и от разных владельцев.

1. Чат-боты и таскание вёдер

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

Скрипты. Потом появились скрипты: они собирали нужные файлы в контекст, отправляли их и применяли ответ. Стало быстрее, но каждый шаг цикла всё ещё оставался за нами.

Агенты. Дальше агенты научились крутить этот цикл сами: открыть файлы, поправить, собрать, прогнать тесты, прочитать падения, попробовать снова. Какое-то время казалось, что задача решена.

Пробки. Потом агенты начали застревать, как машины в пробке. Закапывались в детали, теряли нить и возвращались к той же стене. Их обложили заплатками: циклами Ralph, которые перезапускают агента, пока работа не сделана, и целями, которые держат его на одной задаче. Всё равно часто не получалось, потому что проект состоит из задач разных классов. Архитектуре, шаблонной правке и ревью безопасности нужны разные модели, а один агент на одной модели делает всё сразу. Хуже того, он сам оценивает свою работу, а хуже всех находит ошибки в коде та модель, которая его написала.

2. Оркестраторы внутри одного вендора

Проблема. Один агент не удерживает весь проект, и его работу никто не проверяет.

Ответ этой эпохи называется оркестратором. Это агент, который делит работу, запускает субагентов на её части и проверяет, что они вернули. Вендоры встроили это в свои среды, поэтому Codex запускает Codex, Claude запускает Claude, а некоторые среды не умеют запускать никого, и всё идёт одним потоком.

Наша система оркестрации этой эпохи называется task-board. Её борда представляет собой набор файлов в репозитории: иерархию эпиков, историй и задач или багов, зависимости, которые эскалируются через родителей, и планировщик, который сортирует этот граф. Каждый дочерний агент запускается под роль с явно заданными моделью и уровнем рассуждений и отслеживается как отдельный запуск.

Доставка идёт по одному циклу (жизненный цикл запроса на изменение, отслеживаемые фоновые запуски):

• продюсер работает в отдельной рабочей копии своей истории и публикует запрос на изменение;
• настроенный набор проверок прогоняется ровно на этом кандидате (привязка проверок);
• ревьюер, обычно модель другого вендора, принимает работу или отправляет её на доработку;
• оркестратор интегрирует историю, и подписанный результат попадает в основную ветку через pull request, прошедший ревью.

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

Цель у каждого агента. Claude и Codex реализуют цели каждый внутри своей среды. Одному агенту это помогает, а оркестратору нужно больше: своя цель у каждого дочернего агента, своя цель у оркестратора уровнем выше и цели, которые меняются, когда работа открывает новые вехи. Цель вида “сделай красиво и чтоб работало” агент закончить не может никогда. task-board держит основную цель оркестратора и отдельную цель у каждого дочернего запуска, у каждой есть ревизии, так что оркестратор может сдвинуть ребёнку цель на ходу (цели в Claude, цели в Codex). Наш опыт добавляет одно правило: оркестратор с огромной целью начинает мешать задачи и закапываться в детали, поэтому длинную цель он режет на вехи, и чем слабее его модель, тем ближе друг к другу должны стоять эти вехи (конспект звонка).

Саму эту борду сотни часов строили так же, её собственные оркестраторы, почти без вмешательства человека. Теперь она в режиме поддержки: туда идут исправления и работа над пропускной способностью проверок, а всё новое выходит модулями, которые к ней подключаются (роадмап §5b).

Предел этой эпохи задаёт вендор: каждый оркестратор запускает только своих.

3. Оркестраторы поверх разных сред

Проблема. Допустим, нужно ревью безопасности одного изменения сразу с трёх сторон: лучшей моделью Codex, лучшей моделью Claude и локальной моделью или моделью без цензуры, которая готова по-настоящему ломать код. Внутри одного вендора это три вкладки, три среды и человек, который носит между ними дифф и находки. Ни одна среда не знает о двух других.

Как говорится, любую проблему в информатике можно решить ещё одним уровнем косвенности. Наш уровень позволяет одному оркестратору, в какой бы среде он ни жил, запускать субагентов в любой другой с одними и теми же инструкциями, так что даже локальный Qwen может дирижировать топовыми моделями Claude и Codex. Какая модель делает работу, решают роль и политика. task-board уже так запускает отслеживаемых детей в Claude и Codex, а остаток главы о том, как уравнять все среды.

Цели в каждой среде. Доставить цель в среду, подтвердить, что она приняла именно эту ревизию, и вставить уведомление в живую сессию сегодня умеют только хосты Claude и Codex внутри task-board, и каждая новая среда добавила бы туда тысячи строк (сводка по хосту целей). Среды при этом сильно различаются (Muse, agy):

Среда	Канал управления	Доказательство, что ревизия цели принята	Как ведётся сессия
Claude	терминал (PTY)	чтение отрисованного терминала	PTY
Codex	API app-server	ответ API	app-server
Muse 1.3	muse serve (JSON-RPC со встроенным API целей)	событие goalChanged	владелец цели через serve; сессия человека через PTY
agy 1.2.9	фоновый режим stream-json и хуки	вызов нашего собственного хука Stop	фоновый владелец с хуком; PTY для человека
Pi, Qwen (в планах)	расширение через приватный сокет	подтверждение дайджеста расширением	PTY плюс расширение

Поэтому логика целей переезжает в отдельный модуль, хост сессий (следующая глава), с одним контрактом на каждую среду: поднять или возобновить сессию; поставить, изменить или снять цель; подтвердить точную ревизию цели; вставить уведомление в идущую сессию; отдавать события цели и расхода. В task-board остаются только журнал целей и решение, какую цель кому отдать. Бюджеты токенов для всех сред держит хост: учёт всегда, на 90% уведомление “сворачивайся”, на 100% пауза и сообщение оркестратору. Бюджет напрямую принимает только Codex.

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

Когда цели работают в любой среде, по разным средам, подпискам и лимитам можно разнести и самих оркестраторов. Это шардинг, и для него нужны оркестраторы, которые знают друг о друге (глава 5).

4. Оркестраторы, которые не принадлежат ни одному вендору

Проблема. Пересечь границы сред мало, если каждая деталь всё ещё рассчитана на одного вендора. Каждая среда читает глобальную конфигурацию машины, и дочерний агент видит скиллы и MCP-серверы, которых видеть не должен. Каждый инструмент, который запускает агента, сам записывает флаги среды, и копии разъезжаются. Коммитнутая конфигурация называет конкретные идентификаторы моделей, и у напарника с другими подписками проект ломается. А сессия оркестратора умирает вместе с демоном, который её держит.

Ответ в том, чтобы спрятать всё, что принадлежит вендору, за нашими собственными контрактами. Эта глава идёт по плоскостям.

Плоскость	Отвечает на вопрос	Модуль	Состояние
Контекст	что получает агент	Curator	кандидаты в релиз
Запуск	как намерение превращается в argv и окружение	модуль agents-management; curator-agent-launcher (curator run); task-board spawn	модуль работает; у лаунчера тег v0.1.0
Сессии	кто держит живую сессию: цели внутрь, события наружу	agent-session-host; сегодня tb-sessiond	черновик v0.3; сначала вынос
Выбор	какую модель получает роль и доступна ли она	curator-model-router; агрегатор доступности в agents-management	черновики
Инференс	какие локальные движки подняты	curator-inference-manager	черновик
Сеть	через какой выход идёт запуск	curator-network-profiles	черновик

4.1 Контекст: свой профиль Curator у каждого агента

Curator превращает профиль (корневые инструкции, скиллы, MCP-серверы) в управляемую домашнюю папку. Это отдельная папка конфигурации на каждый профиль, вроде ~/.claude или ~/.codex, в которой лежит только контекст этого профиля. Агент, запущенный в ней, видит ровно этот контекст и ничего из того, что установлено на машине глобально (роадмап §8.2). Управляемые папки сегодня есть у Claude Code, Codex, OpenCode и Pi; у Muse своего адаптера пока нет.

С 25 сентября каждый запуск стартует с профилем Curator своей роли, поэтому скиллы ревьюера живут только в папке ревьюера и никогда не попадают в папку проекта, где их мог бы подхватить оркестратор и начать вести себя как ревьюер (Кипер §13.5). Какой профиль у какой роли, выбирает оператор в своём личном файле ~/.curator/models.toml.

4.2 Запуск: одно место сборки

Модуль agents-management держит реестр моделей, по одному плагину на каждую среду (исполняемый файл, грамматика argv, контракт окружения, передача stdin) и слой лимитов провайдеров. Он выдаёт значения плана и сознательно не запускает ни одного процесса (архитектура).

Решение 0019 (предложено): одно место сборки. Фрагмент запуска из профиля Curator могут читать несколько процессов, но каналы контекста (конфигурация MCP, системный промпт, переменная домашней папки) и argv среды записываются ровно в одном месте, в модуле (0019). Причина вполне конкретная. Если лаунчер, task-board и хост сессий каждый сам пишут claude … --mcp-config <file> --strict-mcp-config, копии разъезжаются, и стоит где-то забыть --strict-mcp-config, как собственные MCP-серверы машины протекают в дочерний процесс.

Привязки сред исполнения. У привязки две половины (LP D1 и следующие до D3): стабильный идентификатор и приватная запись машины в ~/.curator/runtimes.toml, которая связывает этот идентификатор с транспортом, адресом, источником учётных данных и, возможно, движком. Так Codex может ходить в сервер llama.cpp, и никому не приходится коммитить адрес своей машины.

Три входа. 27 сентября мы приняли одну форму для всех командных строк (решение, обзор):

• keeper служит человеку на пасеке (глава 5);
• curator ставит и настраивает машину, а незнакомое существительное передаёт провайдеру с именем curator-<noun>: curator run, curator session, curator models, curator runtimes, curator engines, curator network, curator playbook;
• task-board служит ядром, которое вызывают агенты, хост сессий, таймер и keeper.

Один глагол держит одно значение во всех трёх, --profile всегда означает профиль Curator, а в каждом файле оператора лежит одно существительное: ~/.curator/{models,runtimes,engines,network}.toml. Человек входит в сессию через curator run claude|codex (решение 0021, предложено), а отслеживаемые неинтерактивные дети по-прежнему стартуют через task-board spawn.

4.3 Сессии: хост сессий

Долгоживущему оркестратору нужно что-то, что держит его в работе, пока никто не смотрит. Сегодня это tb-sessiond, демон сессий внутри task-board. Он сращён с task-board, держит сессии Claude в собственном адресном пространстве и обслуживает основную сессию одной борды и её запуски. Перезапуск ради обновления убивает все сессии Claude, которые он держит (хост сессий §2.7).

План для модуля хоста сессий (спецификация) идёт в жёстком порядке:

1. Вынести как есть. Слой хостов провайдеров переезжает в свой репозиторий за контрактом из главы 3, с побайтно совпадающими эталонами и без изменений поведения (§3).
2. Закрыть доступ. Сегодня один токен, который может прочитать любой процесс пользователя-оператора, управляет всеми сессиями. Первый рефакторинг выдаёт каждой сессии собственный токен возможностей, где сказано, на что она может действовать: на себя и на сессии, которые сама запустила (§6.2).
3. Доставлять в сессии, которые никто не смотрит. Каждое сообщение идёт в одном из трёх режимов звонка: next_turn по умолчанию, steer в идущий ход там, где среда это принимает, и interrupt только для остановки, парковки и аварийного стопа (§7).
4. Пережить обновление. Один хост на машину и маленький держатель терминала на каждую сессию, чтобы хост мог перезапуститься и никого не повесить.

Парковка и аварийный стоп. Парковка означает аккуратную остановку: оркестратор пишет записку, записка привязывается к цели на борде, и следующий старт читает её первой (§8). Аварийный стоп оформлен отдельной командой, которую никто не запустит случайно: keeper estop просит набрать фразу и подтвердить присутствие оператора, ядро снимает снимок каждой борды, а затем все запуски и сессии останавливаются так, чтобы их можно было продолжить (§9). Человек набирает keeper park и keeper estop, под ними работают команды хоста curator session park и curator session estop, и ни одна команда ядра сессию не останавливает.

4.4 Выбор: роутинг, доступность и счёт за токены

Проблема. Выбираешь на проект одну сильную модель, а большая часть её задач низкого класса: переименование, шаблонный тест, правка документации. Токены при этом сгорают по цене дорогой модели.

Роутер работает отдельным проверяемым шагом подготовки запуска и никогда не встаёт между агентом и API модели. Он задаёт четыре вопроса, и у каждого свой владелец (R2):

• Разрешено? Отвечает политика оператора и проекта.
• Совместимо? Отвечают реестр модуля и каталог.
• Подходит под работу? Отвечает оценщик роутера по требованиям задачи и доказательствам вроде бенчмарков и наших собственных результатов (R4).
• Доступно сейчас? Отвечает единая картина доступности по профилю в agents-management: лимиты провайдеров, состояние движков и логин внутри управляемой папки. Неудачное чтение никогда не считается свободным запасом.

Хорошая оценка никогда не перебивает три других ответа. У роутера четыре режима: off, shadow (записать решение и ничего не менять), recommend и select (R7). Со временем очень быстрый классификатор сможет прочитать спецификацию задачи и выбрать модель, зная бенчмарки, лимиты и то, что доступно прямо сейчас.

Локальные модели. curator-inference-manager владеет локальными движками и выдаёт на них аренды, поэтому движок никогда не гасят, пока им пользуется запуск. Движок в состоянии ready, когда обслуживает запросы, и в состоянии ensurable, когда веса на месте и машина его пропустит, так что холодный движок остаётся в выборе, просто с ценой старта (§5).

В сумме простая задача ночью уходит на локальную модель, сложная на передовую, и ни один из этих выборов не делает человек, переключая вкладки. Мы не рассчитываем, что всегда будем работать на сильнейшей модели: сильные модели дороги, а детерминированный процесс вокруг маленькой модели делает её продуктивной (глава 5).

4.5 Сетевые профили: несколько подписок на одной машине

Проблема. Все агенты на машине выходят в сеть одним путём, поэтому два запуска не могут работать бок о бок с двумя аккаунтами через два разных выхода.

У запуска пять независимых настроек: профиль Curator, выбор учётных данных, привязка среды исполнения, сетевой профиль и профиль исполнения (N1). Сетевой профиль решает, через какой прикладной прокси пойдут поддерживаемые соединения именно этого запуска. Это кооперативная маршрутизация поддерживаемых клиентов, а не изоляция процесса, поэтому песочницей мы её не называем. Библиотека сама процессов не запускает: лаунчер, запуск детей в task-board и хост сессий применяют её патч прямо перед стартом среды (N2). Это и есть прокси-возможность лаунчера.

4.6 Кипер: точка входа без собственного цикла

Когда каждая плоскость спрятана за контрактом, верхушке системы собственный агентский цикл не нужен. Кипер, постоянно работающий главный цикл машины (глава 5), работает на существующих средах: Claude Code, Codex, Muse или среде, привязанной к локальному движку. Свой агентский цикл отложен. Позже он может понадобиться для более дешёвого постоянного входа, для урезанных рабочих агентов или для встроенного завершения субагентов, но сейчас ничего из этого не нужно (Кипер §7.7, решено 28 сентября).

Независимость от среды и есть главное преимущество. Человек остаётся со средой и подпиской, за которые уже платит, и может сменить среду, не теряя процессов, борд и памяти. Крупные вендоры выпускают постоянных персональных ассистентов в духе OpenClaw. У них нет профилей и схем работы, поэтому разработку им не поручишь. Наша система даёт профили, схемы работы, любую среду, подписки, которые у людей уже есть, и минимальную установку (конспект звонка).

5. Пасека

Проблема. Всё, что было выше, обслуживает один проект на одной машине. У человека больше одной области работы, проект перерастает одного человека, а сам процесс, то есть типы элементов, статусы, роли и цикл продюсера и ревьюера, зашит в код на Go внутри task-board. Команде с другим процессом приходится форкать код, а процессу, который вообще не про разработку, например закупкам кафе, эта машинерия недоступна ни за какие деньги.

Пасека означает всю систему целиком. Пасечные имена предназначены для людей, а спецификации и код пишут технические термины (имена):

Имя	По-английски	Технический термин	Что это
пасека	apiary	вся система	все машины и процессы одного владельца; одна машина уже маленькая пасека
точка	yard	узел	одна машина
Кипер	keeper	главный цикл	постоянный цикл машины: расписание, входящие, классификатор, разговор с человеком; будит оркестратора нужного процесса
улей	hive	процесс	одна область, например семейный календарь, кафе или разработка проекта, со своей папкой, бордой, плейбуком и корневым оркестратором
матка	queen	корневой оркестратор	единственный оркестратор процесса, которого запускают снаружи
соты	comb	борда	борда процесса, её ячейки служат задачами
пчела	bee	запуск	один запуск агента
дикие пчёлы	wild bees	внешние участники	агенты других владельцев, которые работают над частью процесса по арендам и подписям
нук	nuc	пакет процесса	опубликованный плейбук, из которого вырастает новый процесс
waggle	waggle	протокол сообщений	подписанные сообщения и координация между агентами

Пасечные слова появляются только там, где их набирают люди: в команде keeper и её существительных (keeper hive …), в папках пасеки и в имени профиля apiary. Слова “улей” и “рой” в софте затёрты (Apache Hive, Docker Swarm), поэтому имена живут под брендом. “Рой” вообще не технический термин: в этом тексте так называется видение главы 6.

5.1 Процесс как конфигурация

Ответ на зашитый в код процесс называется конфигурацией процесса. Её черновик лежит в curator-playbook и влит как черновик v4.8, кандидат на заморозку. Идея такая: любой процесс превращается в конфигурацию, которую ведут агенты, а люди и инструменты берут на себя шаги, где они нужны. Это может быть доставка софта, закупки кафе, патентный конвейер или семейный календарь.

Два файла, две задачи (§2.1). Skillfile.json говорит, что установлено, и его читает Curator. Playbook.json говорит, как работает проект: его читает борда, в нём псевдонимы ролей, типы сущностей, схемы работы и политика. Встречаются они только через имена скиллов. Формат: JSON с опубликованной схемой и необязательный блок ui, который ядро игнорирует, чтобы визуальный конструктор потом мог рисовать и править процесс.

Владельцы. У каждого состояния ровно один владелец и необязательные помощники (§4.2).

Вид владельца	Кто делает работу	Пример
agent	агент, выполняющий скилл роли	разработчик, ревьюер, опровергатель
human	человек или группа	одобрить закупку, подтвердить доставку
tool	команда, которую экспортирует скилл, установленный и проверенный Curator	проверка CI, ядро Lean, клиент платёжного шлюза
process	другой процесс	передать доказанную находку процессу, который её чинит

Запросы на изменение, рабочие копии, интеграция и проверки нужны только разработке, поэтому они переезжают в модуль доставки, который добавляет проверки вроде delivery.cr-published и delivery.cr-accepted (§6.3). Кафе его просто не подключает. Машинные проверки приходят из именованных наборов проверок, которые идут локально, в CI проекта или и там и там (§6.12).

Композиция. Проект расширяет один опубликованный плейбук и пишет только свои отличия (§7.1):

{
  "extends": "dev-cycle",
  "roles": { "developer": { "skill": "role-ios-developer" },
             "tester":    { "skill": "role-ios-tester" } },
  "workflows": { "dev": {
    "states": { "qa": { "owner": "tester" } },
    "transitions": [ { "from": "review", "to": "qa" }, { "from": "qa", "to": "done" } ] } }
}

Этот iOS-проект меняет разработчика и добавляет тестирование перед done; когда dev-cycle выпускает новую версию, всё остальное обновляется само. Ещё проект может использовать несколько плейбуков и связать их слоты, то есть абстрактные типы, которые плейбук оставляет открытыми (§7.2). Скрам не описывает, как делается задача; он описывает, как работа отбирается и укладывается в отрезки времени. Поэтому {"uses": ["dev-cycle", "scrum"]} плюс привязка work-item из скрама к story из dev-cycle кладёт истории dev-cycle в спринты скрама. Числа, которые выбирает команда, оформлены параметрами: лимит петли можно поднять вплоть до бесконечности, потому что в одном нашем реальном случае понадобилось тридцать законных кругов доработки (§7.3).

Роли оформлены как скиллы, а плейбук представляет собой коллекцию скиллов (§8). Опубликованный плейбук, например curator-playbook-dev-cycle, содержит скилл оркестратора, в данных которого лежит шаблон процесса, и по скиллу на каждую роль. Один селектор в Skillfile.json ставит их все, а скилл каждой роли попадает только в её запуски через её профиль Curator.

Потребности вместо моделей (§9). Роль формулирует require и prefer через издателя, семейство, возможности, локальность или not_same_publisher_as и никогда не называет идентификатор модели или уровень рассуждений. Конкретные модели привязывает личный файл каждого оператора ~/.curator/models.toml, от частного к общему:

[bindings]
"dev-cycle/developer" = { run = "codex/gpt-6-luna", effort = "high..max" }
"*/refuter"           = { run = ["claude/claude-opus-5-5", "codex/gpt-6-sol"], effort = "high" }
"@reviewer"           = { run = "claude/claude-opus-5-5", effort = "medium" }

Без файла ничего не ломается: резолвер выбирает лучшую допущенную модель, которая закрывает потребности роли, среди установленных и залогиненных сред, сам никогда не выбирает оплату за токены и объясняет свой выбор. Если требование выполнить нельзя, решает on_unmet: block (по умолчанию), fallback к упорядоченному списку, ask, то есть просьба к оператору одобрить исключение с областью и сроком, или degrade, то есть запуск на лучшем доступном с дополнительным ревью.

Проверка и опровергатель. curator playbook check ещё до запуска ловит схему работы, которая никогда не закончится, роль, привязанную к неустановленному скиллу, и проверку, которую не может выполнить ни один владелец (§10). Потом роль опровергателя пытается опровергнуть черновик от противного: допускает, что он реализован как написано, выводит следствия и сравнивает их с записанными решениями, то есть с памятью борды (§12). Первый прогон на этой самой спецификации вернул 36 находок, три из них блокирующие; например, агент мог действовать за владельца-человека, потому что ничто не проверяло, кто двигает переход. С тех пор черновик прошёл семь прогонов опровергателя, и на каждый есть ответ (ревью).

Какие изменения ждут человека (§2.4). Ядро исполняет вступившую в силу коммитнутую версию процесса и никогда не читает рабочую копию, так что оркестратор не может тихо переписать собственные правила.

• Процесс один раз просит у человека право на вид изменений, как приложение на телефоне просит разрешение, и человек отвечает “всегда”, “один раз” или “нет”. Изменения, которые покрывает право, например предпочтения, оценки или расписания в пределах лимитов, вступают в силу при коммите.
• Всё остальное, то есть структура схем работы и всё, что несёт полномочия, ждёт касания человека, и одно касание подтверждает пачкой все накопившиеся изменения.
• Явный громкий режим yolo, при желании на срок вроде 24 часов, доверяет любому изменению на борде, которую никто больше не делит и где ни одна доверенность не касается денег.

Сны (предложено). Процесс можно отрепетировать во сне: каждый инструмент работает с флагом --dream на копии борды, ничего не доходит до реального мира, агент знает, что спит, и ничто, записанное во сне, не считается настоящим доказательством (§6.13). Ночью сон ещё и прокручивает сессии прошедшего дня и укладывает память.

Сегодняшняя борда сама оказывается плейбуком (§14): default.playbook.json описывает текущее ядро строка за строкой, и веха PC1 грузит его с тем же поведением. Общность проверяют семь демонстрационных плейбуков, и каждый стартует с плохо описанной задачи: от dev-cycle и bug-hunt до работы кафе, патентного конвейера и процесса по модели prove2.me, где состоянием checking как инструмент владеет ядро Lean. Следующий пример не из разработки, который мы хотим показать: получение вида на жительство в Грузии, с документами, службами и записями на приём.

Интерлюдия: один проект от начала до конца

Над одним проектом работают два оператора, А и Б. У А подписки Claude и Codex, у Б Codex и локальная модель на ноутбуке.

1. Коммитнутые файлы.
   • В Skillfile.json два селектора-коллекции, для curator-playbook-dev-cycle и curator-playbook-bug-hunt.
   • Playbook.json говорит "uses": ["dev-cycle", "bug-hunt"], привязывает слот fix-target из bug-hunt к dev-task из dev-cycle и даёт ревьюеру потребность not_same_publisher_as: developer с on_unmet: ask.
   • Ни один файл не называет модель, машину или адрес.
2. Личные файлы. models.toml у А привязывает продюсеров к Codex, а ревьюеров к Claude. У Б продюсеры привязаны к локальному движку, который описывают его runtimes.toml и engines.toml. curator playbook check проходит на обеих машинах.
3. Сессии под хостом. Каждый оператор запускает в проекте curator run codex, и хост сессий ведёт каждую сессию с рождения: возобновление, уведомления, цель борды и звонок. Позже может подключиться третий оркестратор в другой среде, и это уже шардинг.
4. Области. Оркестратор А арендует эпик Auth, оркестратор Б эпик Billing. Когда оркестратор А пытается запустить агента по истории из Billing, ядро отказывает (scope_owned_by), и оркестраторы договариваются о передаче сообщениями coord в waggle.
5. Находка уходит в доставку.
   • bug-hunt доказывает находку, и его действие handoff создаёт dev-task в dev-cycle.
   • Разработчик Б работает на локальном движке: curator-inference-manager выполняет ensure, и применяется сетевой профиль этого запуска.
   • На review потребность ревьюера в другом издателе на машине Б не выполняется. Срабатывает ask, и Б один раз одобряет “ревью тем же издателем для этого эпика, 30 дней”.
6. Спецификацию опровергают. Для исправления нужна небольшая спецификация. Её состояние challenge находит, что черновик предлагает релизные теги без v, а записанное решение говорит vX.Y.Z, и возвращает её в draft с этой парой в цитате.
7. Остановка требует человека. Оркестратор А видит, что рабочий агент Б вот-вот интегрируется на сломанную базу. Аренда А этого агента не покрывает, поэтому политика требует одобрения оператора ключом, который доказывает присутствие. А читает отрисованное сообщение и касается аппаратного ключа, а хост Б проверяет обе подписи, прежде чем супервизор остановит агента (waggle §6).
8. Та же машинерия, другой бизнес. На третьей машине кафе гоняет cafe.playbook.json на том же ядре: менеджер одобряет каждый заказ на закупку, заказ через инструмент уходит в портал поставщика, неполученное подтверждение через 15 минут эскалируется, доставленные заказы передаются бухгалтерии, а еженедельное расписание создаёт инвентаризацию (пример). Ничто в ядре не знает, что такое кафе.

5.2 Кипер: много ульев на одной машине

Проблема. Постоянные ассистенты ставят один агентский цикл на расписание и просят его делать всё. Память такого цикла забивается, он хватается за всё сразу и мало что доводит до конца, а работать ему нужна дорогая подписка.

Кипер сам процессную работу не делает (спецификация, черновик v0.5.1). Он держит реестр процессов машины, каждый в отдельном репозитории со своим плейбуком, бордой и ровно одним корневым оркестратором, и направляет каждую просьбу человека в нужный. “Перенеси субботнего стоматолога на 11 и закажи овсяное молоко” делится надвое: первая половина будит матку календаря, вторая поднимает матку кафе, а закупка выше лимита, доверенного кафе, ждёт одобрения человека на телефоне.

• keeper up поднимает машину при входе в систему или после перезагрузки: хост сессий, собственную сессию Кипера и матку каждого улья, каждую через curator run <runtime> --profile <role profile> и с возобновлением из её цели и записки парковки (§7.3).
• Маршрутизация идёт в жёстком порядке: побеждает явная ссылка, потом канал, привязанный к процессу, потом один уверенный кандидат; близким кандидатам задаётся один короткий вопрос, и ответ становится видимой подсказкой маршрута; если кандидата нет, запрос уходит проектировщику процессов (§8.2).
• Проектировщик процессов пишет плейбук под новую просьбу вроде “веди семейный календарь”, начиная с самого простого процесса, который работает, репетирует его во сне и заводит процесс, когда человек подтвердит (§9).
• Человек сначала говорит с Кипером в терминале. Мессенджеры вроде Telegram появятся во второй вехе, KP2, а одобрения идут через приложение-компаньон на телефоне или через проверку пользователя самой операционной системой.

Под одним Кипером работают несколько маток, пока их работа не пересекается. Система поднимается одной установкой: Curator ставит профиль apiary, а keeper init создаёт собственный репозиторий пасеки человека без какой-либо связи с нашими (§6).

5.3 Оркестраторы разговаривают: waggle

Проблема. Два оркестратора на одном проекте блокируют друг друга, переделывают чужую работу и наперегонки приземляются в одну основную ветку. Сообщения между ними не ходят, и ничего не подписано (waggle §1). Мы хотим, чтобы они договаривались сами, без человека, который рулит каждым.

У waggle два слоя (§2). Коммуникация отвечает на вопросы “кто что кому сказал, кто это одобрил и дошло ли”. Координация, построенная поверх, отвечает на вопросы “кто над чем работает и как мы договариваемся”.

• Конверт и подписи. Сообщение состоит из точных байтов содержимого и одной или нескольких подписей SSHSIG, у каждой своя роль: author, approver или endorser. Реестр ключей хранится в обычном файле allowed_signers, поэтому сохранённое сообщение можно перепроверить офлайн через ssh-keygen (§4).
• Классы и полномочия (§5): coord между оркестраторами, cmd от оркестратора или оператора рабочему агенту, report от рабочего агента, receipt от хоста. Ключ рабочего агента не может создать валидный coord или cmd ни через какой транспорт.
• Железо ключей подключается плагинами (§4.5): ssh-agent, Secure Enclave от Apple, ключи FIDO, позже TPM и PIV, с уровнями доверия от software до attested.
• Провайдеры служат недоверенными трубами (§9): локальная папка, NATS JetStream, IRC, XMPP, Matrix, Slack, Telegram, электронная почта. Полномочия берутся из подписей, реестра и политики, провайдер их не даёт.
• Доставка в сессию устроена как звонок плюс забор: звонок фиксированного шаблона звенит через хост сессий, а содержимое агент забирает как данные командой task-board mail read (§10).
• Аренды решают, сообщения договариваются (§12). Аренда называет оркестратора, который владеет частью проекта, и хранит номер поколения и токен в хранилище со сравнением и заменой, а ядро проверяет её при запуске агентов, при интеграции и при записи борды.
• Решаем вместе по образцу кворума у пчёл: предложения, support и objection, потом запись decide, которая несёт подписи поддержавших (§11).
• Лаборатория протоколов, одноразовый проект на трёх машинах с нарочно примитивным каналом, даёт агентам самим изобрести, как им координироваться, а словарь растёт из того, что они реально делают (§13).

Сначала локально (веха CM1: два оркестратора на одной машине координируются, и каждый отменяет только своих детей), потом два оператора через интернет, через NATS на выделенной машине нашей частной сети (CM2).

5.4 Два оператора на одном модуле и доверие

Когда один модуль разрабатывают два человека, каждый со своим Кипером, у процесса остаётся одна борда, а его матка живёт на машине-владельце (Кипер §4). 28 сентября мы добавили одного принимающего писателя на борду или на совместную работу, с отсечением по эпохам (решения):

• каждая типизированная операция несёт действующее лицо, борду, версию конфигурации, область и эпоху её аренды, ожидаемую ревизию и идентификатор операции;
• эпоха проверяется при запуске агента, при последней записи и при интеграции;
• писатель, потерявший полномочия, приостанавливает новые записи.

Назначается ли такой писатель по праву владения или выбирается узлами, пока открыто. Приёмы взяты из распределённых баз данных: аренда с номером поколения отсекает устаревшего владельца, а прежде чем роль унаследует другой оркестратор, прежнее поколение назначений отзывается, иначе старый оркестратор, проснувшись, продолжит действовать (пасека §10.1).

Доверие получило собственную спецификацию, а его принципы простые (решения 25 сентября):

• действия человека подтверждаются только ключами, которым нужно его присутствие, например аппаратным ключом безопасности или приложением на телефоне, ключ которого закрыт биометрией;
• подписывающее устройство само показывает то, что подписывает, и никогда не подписывает дайджест, посчитанный где-то ещё;
• права и подтверждения хранятся записями на борде, которые проверяет каждая машина;
• отзыв ключа, права или инструмента действует сразу;
• агенты работают под собственной учётной записью операционной системы, и это настоящая граница; до тех пор любая проверка служит ограждением от послушных агентов и не остановит враждебного;
• привилегированные операции, например платежи, выкладку в боевую среду или работу с секретами, агент только запрашивает, а выполняет доверенный исполнитель после авторизации.

6. И ещё одно: рой над одной средой

Проблема. Некоторым проектам нужно больше, чем может дать один человек. Две-пять подписок по карману, сотня уже нет. Новое ядро операционной системы, написанное с нуля на лучших наработках десятилетий исследований, требует многих людей, многих машин и общей среды с виртуальными машинами и ресурсами на компиляцию. А ещё доверия, потому что честными будут не все участники.

Наш ответ называется роем: много диких пчёл над одной средой. Среда здесь означает один проект, его борду и его мощности для сборки. Ведут её доверенные оркестраторы, а недоверенные агентские среды других владельцев входят в пул вокруг неё и выходят из него на ходу (конспект звонка).

• Односторонний канал. Оркестратор пишет дикой пчеле, а она не может написать в ответ указание, потому что её вывод может нести инъекцию. То, что она возвращает, считается работой на ревью и читается как данные за эшелонированной защитой от инъекций: полномочия вне модели, типизированные сообщения, инспекторы и карантин по умолчанию для внешних отправителей (waggle §7).
• Инструменты через наш мост. Вызовы инструментов чужого агента можно пустить через наш мост штатными механизмами подмены инструментов в самих средах, так что его инструменты исполняются на нашей стороне и по нашим правилам, а секреты проекта в его окружение не попадают.
• Ревью как безопасность. Задача проходит нескольких независимых ревьюеров из разных семейств моделей и от разных владельцев. Если кто-то подсадил уязвимость, шанс, что хотя бы один нескомпрометированный ревьюер её поймает, растёт с каждым независимым ревьюером. Цикл продюсера и ревьюера из главы 2 становится механизмом безопасности.
• Приёмы распределённых баз данных. Аренды с номерами поколений и токенами, эпохи, которые отсекают устаревшего участника, и записи кворума с подписями поддержавших не дают многим недоверенным участникам испортить одно общее состояние.
• Допуск по стадиям. Доверенная стадия опирается на изменения реестра, подтверждённые человеком, ключи операторов и частную сеть; внешняя стадия допускает партнёров только с классом coord, сначала через аккаунты на нашем сервере, потом через федерацию (waggle §15).

Дизайн пасеки приходит к этому по стадиям, с полезным результатом на каждой (роадмап пасеки §10):

Стадия	Что добавляет
0	локальный путь запуска как первый бэкенд агентского хоста (одна машина)
1	один удалённый исполнитель: агент на второй машине меняет код на первой со своими учётными данными
2	надёжный доверенный пул: долговечный почтовый ящик, пробуждение без интерфейса, переподключение, аренды, очереди, лимиты
3	ограниченные профили исполнения с одинаковыми проверяемыми ограничениями для локальных и удалённых агентов
4	несколько оркестраторов с ролями по областям и сообщениями между ними
5	внешние участники: недоверенные мощности при более строгом допуске
6	распределённая автономия: реплицированное состояние и автоматическая передача ролей

Люди могли бы ночью отдавать свободный запас подписок проектам с открытым кодом, которые говорят на этом протоколе, как когда-то отдавали свободное процессорное время добровольным вычислениям. В таком масштабе над одним проектом работают десятки оркестраторов, а со временем и тысячи субагентов. Сегодня такие системы умеют строить единицы. Мы хотим, чтобы это могли и сообщества, в том числе для обороны: тогда новое ядро операционной системы с нуля становится общим делом сообщества, а баланс не смещается в сторону тех, кто умеет это уже сейчас.

7. Где мы сейчас и что дальше

На 28 сентября 2026 года спецификации влиты в main как черновики, так что каждый оркестратор читает один источник; заморозка каждой будет позже. Из Кипера, пасеки и waggle пока не реализовано ничего. Сегодня работают Curator, curator run, модуль agents-management и task-board с демоном сессий и task-board spawn.

Модуль	Состояние
waggle	черновик v5.2
curator-playbook	черновик v4.8, кандидат на заморозку
curator-keeper	черновик v0.5.1
agent-session-host	черновик v0.3
спецификация доверия	черновик, закрыт до ревью
curator-model-router, curator-inference-manager, curator-network-profiles	черновики
task-board	работает, в режиме поддержки

Порядок работ

Из роадмапа §2b, с поправками 28 сентября:

1. Хост сессий и на нём waggle CM1. Он убирает код конкретных сред из task-board, даёт каждой среде цели и уведомления и открывает шардинг.
2. Конфигурация процесса PC0 и PC1, первые демонстрационные плейбуки и опровергатель. PC1 доказывает модель на настоящей борде.
3. Уходим с agents-infra, нашей старой инфраструктуры, кампанией из двух этапов:
   • Этап А: agents-infra больше никому не нужен, и каждый дочерний агент работает в профиле Curator своей роли. Основная сессия и сессии с целью собираются так же, как дети, поэтому этап А не ждёт, пока curator run научится передавать сессии хосту.
   • Этап Б: первая привязка среды исполнения к локальной машине, то есть дочерний агент Codex на локальном движке с настоящим вызовом инструмента туда и обратно, плюс перенос брокера локальных моделей в curator-inference-manager.
4. CM2, два оператора через интернет; curator run под хостом сессий; PC2, роли-скиллы пакетами.
5. Остаток профилей запуска (M4), затем доступность по профилю (M5b); PC3 с модулем доставки и настоящим доверием. Теперь M4 идёт раньше M5b, которой она нужна.
6. Позже: сетевые профили, роутинг на доказательствах, Кипер, распределённая пасека и исследование формальных методов, где каждая веха получает самую сильную машинно-проверяемую приёмку из доступных.

Первая веха Кипера, KP1, работает только в терминале: одна машина на существующих средах, реестр, маршрутизация, keeper up и надзор через вынесенный хост сессий. Каналы появятся в KP2, а ежеминутный таймер, который запускает расписания, придёт вместе с PC3.

Muse идёт первым, но узко. Ещё до выноса хоста мы даём Muse отобранное окружение для дочерних агентов, закреплённую версию и хост-владельца поверх muse serve, пока не подключённый к task-board. Продюсером Muse не работает, пока это окружение не выпущено и не закреплено.

Форки и старый сервер борд

Большинство крупных направлений выносится в модуль или за узкий шов, как было с waggle. Когда форк всё-таки нужен, форк владеет кодом, а копия основного репозитория остаётся владельцем борды, так что у борды одна подписанная история (отдельный владелец кода); форк подтягивает основной репозиторий на каждом приземлении и останавливает линию при большом конфликте. Центральный сервер борд не поднимаем: его удалённый режим умеет только планирование, а токены ничем не ограничены по области (оценка).

Демо

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

Решено, открыто и в работе

Решено 25-28 сентября:

• имена пасеки, причём пасечные слова только там, где их набирают люди;
• права, которые выдаются один раз, касания пачкой, явный режим yolo, лимиты петель как параметры и сны как предложение;
• принципы доверия и отдельная учётная запись операционной системы для агентов как настоящая граница;
• скиллы ролей через профили Curator для каждой роли;
• форма командных строк: keeper, curator со своими провайдерами и task-board как ядро;
• Кипер работает на существующих средах, свой цикл отложен, а KP1 работает только в терминале;
• один принимающий писатель на борду с отсечением по эпохам;
• спецификации влиты в main как черновики.

Ещё открыто (открытые вопросы):

• назначается ли писатель общей борды по праву владения или выбирается;
• дизайн и платформы приложения-компаньона;
• как защитить файлы и исполняемые файлы оператора, пока агенты не переехали под собственную учётную запись;
• заморозка каждой спецификации.

В работе: кампания ухода с agents-infra в двух этапах, узкий срез Muse и вынос хоста сессий.

Что дальше

Следующие конкретные шаги: этап А и хост сессий. Когда дети заработают в профилях своих ролей, а хост встанет отдельно, третий оркестратор в другой среде сможет подключиться к проекту в тот же день, звонок waggle дойдёт до каждой среды, а у Кипера появится хост, на котором он работает. Всё остальное в этом тексте, включая пасеку и рой, опирается на эти два шага.