Зачем агентам задачи, если им можно просто написать словами

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

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

9 сентября 2026 года команда, о которой идёт речь, перестала вести работу в карточках GitHub: задачи и доска проекта поставлены на паузу, работа и переписка ролей переехали в отдельный слой рядом с папкой. Причина простая: API GitHub не выдерживает нагрузку многоагентной команды. Многоагентной команде нужен свой слой задач. Чисел этой нагрузки я нигде не записывал, поэтому здесь их нет.

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

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

Задачи расползаются по папкам, и целое не держит никто

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

Ломается она потому, что цель редко живёт внутри одного репозитория. «Запустить продажи» это правки в боте, страница на сайте, текст рассылки и отчёт по числам. Четыре разных места на диске, одна цель. Если список задач привязан к папке, цель распадается на четыре куска, и ни один из них не знает про остальные. Хуже того, часть работы не попадает никуда: отчёт продаж и сообщение клиентам не имеют своего репозитория вовсе.

Работающее правило звучит так: задачи заводятся под цель. Для них берётся отдельная папка, которая кодом не занимается и держит всю работу цели целиком, и разработку, и бизнес. Папки с кодом и контентом при этом остаются местами, куда сдают результат.

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

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

Из этого кадра нужны две вещи. Первая: исполнитель выбирается по линзе роли, поэтому задачи одной цели расходятся по разным агентам, и ни один из них не видит цель целиком. Целое держит список, и голова исполнителя для этого не нужна. Вторая: работа приземляется в папки, у которых своего списка задач нет, поэтому вопрос «что осталось до цели» к ним не задаётся вовсе. Роль, которая только читает, в такие папки ничего не сдаёт, и на кадре это отдельная линия.

Как устроено внутри

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

1. Цель получает своё место на диске. Одна папка, в ней задачи цели и файлы состояния команды. Кода продукта там нет, поэтому папка никуда не выкладывается и уронить продукт не может.
2. Задачи цели лежат в одном списке. Правка в боте и текст рассылки стоят в нём соседними строками, потому что обе двигают одну цель.
3. Папки с кодом задач не держат. Задача про бот живёт в списке штаба и всё время остаётся там. В папке бота появляется только ветка и заявка на слияние.
4. Штабов столько, сколько целей. Вторая долгая цель со своей командой получает вторую папку со своим списком задач. Общими остаются папки с кодом.
5. Человек смотрит в одно место. Доска для владельца собирается из тех же задач одной командой, поэтому его картина и картина агентов совпадают по построению. Задачи лежат структурой, которую читает машина, и на этом сборка держится; инструмент разобранной раскладки называется beads.

Штаб держит задачи, поверхность принимает работу

Отсюда на диске появляются два вида папки, и путать их дорого.

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

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

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

На 14 сентября 2026 года в моей рабочей папке 516 репозиториев. Свой список задач есть в пяти из них, и четыре из этих пяти это живые штабы со своей целью: учебный, редакция контента, комьюнити и исследования. Пятый заведён под пробу. Репозитории бота, кабинета студента, рассылок и сайта своих задач не держат ни одной: они поверхности. Штабов единицы, поверхностей столько, сколько у вас продуктов.

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

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

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

Типичная ошибка

Было: список задач заведён прямо в репозитории бота, потому что первая срочная работа была про оплату.

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

Почему ломает: к третьей неделе половина задач цели оказывается про сайт и про тексты, и они физически не помещаются в трекер бота. Начинается второй список, и с этого момента ни один из двух не отвечает на вопрос «что осталось до цели». Отдельная беда с деплоем: папка бота уезжает на прод, и служебные файлы команды едут вместе с ней.

Путь одной задачи от вашей фразы до кнопки слияния

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

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

Вы говорите фразу в этот чат. Дальше она проходит восемь шагов, и ни на одном из них не хранится в чьей-то голове.

1. Оркестратор заводит задачу вашими словами. Смысл не улучшается и детали не дописываются: улучшенная фраза перестаёт быть проверяемой против того, что вы имели в виду. Больше он руками не делает ничего.
2. Продюсер берёт её на ближайшем такте. Такт это один его цикл: принять сданное, обойти слепые зоны, разобрать входящее, завести новое.
3. Продюсер дописывает задачу до целого результата. Что должно получиться и зачем, где границы, из каких источников брать факты, в какой форме сдавать, чем работа заканчивается и когда спрашивать владельца.
4. Продюсер назначает роль. Оплата это инженер. Текст сообщения клиентам об этой же поломке это роль коммуникаций. Одна цель, разные линзы.
5. Оркестратор нанимает воплощение роли. Агент приходит с брифом роли, забирает свои задачи и входящие из списка и начинает работать.
6. Роль работает в поверхности. Ветка в репозитории бота, правка, заявка на слияние. Ничего наружу роль не отправляет и ничего не деплоит.
7. Роль возвращает работу в ту же задачу. Ссылка на заявку, комментарии по ходу, метка на приёмку. Комментарии пишутся после каждого проверенного куска. Один общий комментарий в конце этой работы не делает: агент, который только читает, теряет всё при остановке.
8. Продюсер принимает или возвращает кругом правок. Принял, закрывает задачу с причиной. Вернул, ставит круг правок и пишет, что именно переделать и почему.

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

Отдельная деталь про шаг 1. У оркестратора руками только два действия: положить ваше слово в список задач и нанять исполнителя по заявке продюсера. Соблазн сделать работу самому там, где она на пять минут, ломает схему быстрее всего: появляется вторая точка входа задач, и целое опять никто не держит.

Продюсер это одна дверь, в которую входят все задачи

Ролей в команде может быть десять. Заводит задачи и расставляет приоритеты одна. Два источника новых задач и два арбитра приоритетов дают дубли и пропуски, и виноватого в них нет: каждый из двоих действовал по своей картине и в ней был прав.

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

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

Как устроено внутри

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

1. Всё входящее становится задачей. Ваша просьба, вопрос роли, сигнал ревью, заявка от соседнего штаба. Ничего не остаётся репликой в чате, поэтому ничего не теряется при перезапуске.
2. Продюсер начинает такт с обхода слепых зон. Что лежит на диске против указателя источников, проходится ли путь пользователя по шагам, как выглядит доска вашими глазами, сходятся ли деньги с реестром, что обещано и что из этого без владельца. Приёмка задач по их описаниям не ловит задачи, которых никто не завёл.
3. Приёмку закрывает тоже он. Исполнитель свою задачу не закрывает: он ставит метку и пишет, что сделал и где лежит результат. Тот, кто делал работу, плохо видит её дыры, поэтому смотрит свежий контекст, и отдельная роль редактора для этого не нужна.
4. Возвратов на доработку три. Первый, второй, третий. После третьего продюсер не заводит четвёртый круг: он выносит владельцу вопрос на одну строку с двумя вариантами ответа.

Типичная ошибка

Было: срочная просьба отдана исполнителю напрямую, мимо продюсера, потому что дело на пять минут.

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

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

Оркестратор нанимает и держит бюджет

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

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

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

Модель у оркестратора и у ролей разная. В разобранной раскладке оркестратор работает на старшей модели Fable, роли на Opus по настройке команды. Разница взята из того, какая работа кому достаётся: оркестратору приходит живая фраза владельца со всеми недомолвками, и ошибка понимания здесь стоит целого цикла работы команды; исполнителю приходит задача, уже доведённая продюсером до пяти частей, и на ней достаточно рабочей модели. Исполнителей при этом много, а оркестратор всегда один.

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

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

Когда штабов становится два

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

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

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

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

Типичная ошибка

Было: второй штаб заведён под каждую новую папку с кодом, потому что так казалось аккуратнее.

Стало: штаб заведён под цель, а папки с кодом остались общими поверхностями.

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

Во что эта схема обходится и когда её не поднимать

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

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

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

Девять слов, которыми меряется эта работа

Штаб

Папка, с которой начинается работа с командой. Держит задачи цели, брифы ролей, реестр воплощений, архив переписки и доску для человека. Кода продукта в ней нет.

Поверхность

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

Слой задач

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

Роль

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

Воплощение

Один запуск агента по брифу роли, с чистым контекстом и своим бюджетом. Умирает, упершись в бюджет или закончив пакет. Следующее приходит с тем же брифом и поднимает ход работы из комментариев в задачах.

Оркестратор

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

Продюсер

Роль, которая держит цель: полнота списка задач, приоритеты, приёмка работы и поверхность для владельца. Единственная, которая заводит задачи и закрывает их.

Такт

Один цикл продюсера: принять сданное, обойти слепые зоны, разобрать входящее, завести новое, попросить найм. Задержка любого нового запроса равна одному такту.

Тик

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

Итог

Обещание в конце то же, что в начале. Схема не делает работу быстрее сама по себе. Она делает её видимой: вопрос «что осталось до цели» получает письменный ответ, а закрытый чат и умершая сессия перестают быть потерей.