Как вести доску результатов Codex, когда задач и агентов становится больше одного

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

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

Почему чат перестает работать

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

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

Минимальная структура

Для начала достаточно семи полей:

Эта таблица выглядит банально, но именно она отделяет агентную работу от хаоса. Если Codex написал статью, но нет визуала, статус не "готово", а blockedforvisualmedia. Если визуал есть, но не пройден review, статус не "можно публиковать", а waitingreview. Если статья опубликована, но соцсети только поставлены в очередь, статус не "отправлено", а factory_scheduled.

Как просить Codex обновлять доску

После каждой значимой работы можно добавить правило:

В конце обнови result board: задача, созданные файлы, статус, блокеры, что должен решить человек. Не называй работу завершенной, если не пройдены проверки или нет нужного артефакта.

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

Что это дает владельцу проекта

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

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

Где человек остается главным

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

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

Вывод

Когда задач много, Codex должен работать не только в чате, но и в видимой операционной системе. Минимальная доска результатов — первый шаг. Она не требует сложной платформы: можно начать с YAML, таблицы, Markdown-файла или простого Agent-Ops каталога. Важно не где она лежит, а чтобы Codex обязан был её обновлять.

Если коротко: много агентов ломаются не потому, что модель слабая. Они ломаются потому, что никто не видит состояние работы. Доска результатов возвращает видимость. А видимость — это уже половина управления.