В Hermes уже есть нормальный встроенный Kanban: можно создать карточку, назначить исполнителя, запустить worker-а и получить результат. Для простых задач такого уровня хватает.

Но когда я начал гонять через Kanban серьёзные процессы, стало видно, чего мне не хватает.

Стоковый Kanban отвечает на вопрос:

«Какая задача у кого сейчас лежит?»

А мне нужно было, чтобы система отвечала ещё на другие вопросы:

- кто владеет всей задачей целиком;
- какой агент делает конкретный кусок;
- что агенту можно читать и трогать;
- куда ему нельзя лезть;
- что считается готовым результатом;
- кто проверяет, что за словами есть реальный результат;
- кто доставляет файл или отчёт человеку;
- что потом сохраняется в wiki, skill, report или memory.

Потому что в реальной работе проблема обычно не в самой карточке.

Проблема в другом.

Один агент что-то сделал, второй не понял контекст. Файл появился локально, но человек его не получил. Worker написал «готово», но никто не проверил файл. Зависимость между задачами написали словами, а не связали карточки между собой. Опыт после задачи случайно утащили в память, хотя это был просто временный progress.

Я собрал для себя дополнительный слой поверх обычного Kanban.

В файле есть простая логика:

- у каждой серьёзной задачи должен быть владелец потока;
- карточка должна быть не просьбой, а контрактом;
- в карточке должны быть границы: что можно, что нельзя, какие источники разрешены;
- зависимости между карточками должны быть настоящими, а не текстом в описании;
- worker должен выполнить задачу и проверить результат;
- файл на диске не считается завершением, пока он не доставлен человеку;
- для долгих задач нужен monitor, heartbeat или понятный способ проверить прогресс;
- после завершения нужно решить, куда идёт опыт: в Kanban, report, wiki, skill или memory.

Отдельно я прописал роли.

Есть orchestrator - он держит общий поток.
Есть dispatcher - запускает нужных исполнителей.
Есть worker - делает конкретный кусок.
Есть reviewer - проверяет результат.
Есть delivery owner - доставляет финальный файл или отчёт человеку.
Есть monitor - следит, чтобы длинная работа не зависла молча.

Это звучит чуть формально, но на практике очень сильно разгружает голову.

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

Для меня главное правило такое:

модельный ответ - это ещё не работа;
чат - это ещё не доставка;
локальный файл - это ещё не завершение;
отчёт worker-а - это ещё не proof.

Работа начинается там, где у задачи есть владелец, границы, зависимости, проверка, доставка и receipt.

Такой слой я и оформил в отдельный MD-файл.

Его можно забрать как основу и переделать под свою систему: положить в AGENT.md, превратить в skill или использовать как чеклист для настройки своей agent board.

Файл ➡️ КАНБАН